xwiki-devs October 2013

xwiki-devs@xwiki.org

23 participants
62 discussions

[xwiki-devs] Regarding highlighting the text

by Prachi Maheshwari

Hey everyone, I have created various spaces/apps and their different forms within. Now when users fill in the forms, I want the respective titles to be in different text format as compared to text. May be highlighted, Different font, etc. I need to change it in the class or template or sheet files of that space. Can anyone please help and tell me where can I do such things. Or if there is any help related to it online. Thank you, Prachi

11 years, 2 months

Re: [xwiki-devs] [Proposal] Wiki API

by Guillaume "Louis-Marie" Delhumeau

Hi 2013/10/17 Eduard Moraru <enygma2002(a)gmail.com> > Hi, > > On Wed, Oct 16, 2013 at 12:18 PM, Guillaume "Louis-Marie" Delhumeau < > gdelhumeau(a)xwiki.com> wrote: > > > Hi Edy > > > > > > 2013/10/11 Eduard Moraru <enygma2002(a)gmail.com> > > > > > Hi, > > > > > > On Thu, Oct 10, 2013 at 11:46 AM, Guillaume "Louis-Marie" Delhumeau < > > > gdelhumeau(a)xwiki.com> wrote: > > > > > > > Hi Eduard, > > > > > > > > > > > > 2013/10/9 Eduard Moraru <enygma2002(a)gmail.com> > > > > > > > > > Hi, > > > > > > > > > > On Tue, Oct 8, 2013 at 4:41 PM, Guillaume "Louis-Marie" Delhumeau < > > > > > gdelhumeau(a)xwiki.com> wrote: > > > > > > > > > > > Thanks for all your answers. > > > > > > > > > > > > I continue to iterate until we reach something nice. You can see > > the > > > > work > > > > > > there: > > > > > > > > > > > > > > > > > > > > > > > > > > > https://github.com/gdelhumeau/xwiki-platform/tree/feature-wiki-properties-g… > > > > > > > > > > Side note: I`ve noticed that you have 2 branches where you work, both > > > feature-wiki-properties-group that you`ve linked to now and > new-wiki-api > > > that you`ve linked to in the initial post. Please use only one since > it`s > > > already quite confusing and hard to follow. > > > > > > > > > > > > > > > > > > I think my mistakes until now was the fact that I didn't want to > > > > deviate > > > > > > too much from the wiki-descriptor module of Vincent. But now, I > > > > > understand > > > > > > it is better to make something new. > > > > > > > > > > > > Now, the API has a complete javadoc. > > > > > > > > > > > > = Modularity = > > > > > > == Reduce responsibility == > > > > > > > > > > > > The first advantage of creating several modules is to reduce the > > > > > > responsibility of each module. I want one API to handle the wiki > > > > creation > > > > > > and basic management, one API for the template feature (which > could > > > be > > > > > > optional as soon as we have flavors), > > > > > > > > > > > > > > > This transition will most certainly require some considerable > > > refactoring > > > > > and possibly some method deprecating, for which we already have a > > > > strategy, > > > > > at least for the workspaces UI. > > > > > > > > > > > > > Currently, the workspaces UI is a kind of a hack. > > > WorkspaceManager.Install > > > > create a new template where we install a standard XAR UI + Workspace > > > > Template Feature (that overwrites some standard pages) + delete some > > > pages > > > > that we don't need, etc... It forces us to ask the user to create > > > > workspacetemplate first, it does not work out of the box. > > > > > > > > > Neither does wiki manager work out of the box. The current technical > > > limitations require that the user first creates a template wiki that is > > > used in the creation of new wikis/workspaces. > > > > > > > Yes, and it is bad, IMO. Today, we have the Distribution Wizard which is > > launched the first time we go to the wiki. There is no reason to force > > having a template anymore. > > > > > > > > > > > > > > And we need to > > > > have 2 distinct XARs to handle the 2 use-cases: farm and workspaces. > It > > > is > > > > definitively not clean. > > > > > > > > When talking with Vincent about this, we decided that it would be > > better > > > to > > > > create a unique XAR that handle the 2 use-cases. > > > > > > > > > But again, this does not fix the "out-of-the-box" issue. > > > > > > > > > > It will just look at the > > > > wiki configuration to know if we have local users or not, what is the > > > > membership type of the wiki, etc... > > > > > > > > > > The idea was that an admin could come with his own customized XAR that > > > would then be "adapted" to be used as a workspace template, if the > admin > > > did not already do that. It was not desired that the user be limited to > > the > > > standard XE xar, since that would have been rather easy to implement > and > > > automatically "install". > > > > > > > > About the ability to create a template that is automatically "adapted" to > > be a workspace template, I have the feeling that there are more drawbacks > > than benefits: > > - it's too complex > > - it is useless for the majority of users > > - the wiki creation does not work out of the box > > - we have to write documentation about this... > > - If a user wants to create his own customized XAR, he can start from the > > default we provide > > > > You also need to be aware that when this application (workspaces) was > developed, it was to be developed as an addon. Even the minor and almost > necessary "hacks" (read "IFs") that were added into platform for the top > menus were frowned upon even to this date. Stating that the current > implementation is not optimal when viewing this no longer as an added > feature, but a basic and integrated feature is, basically, comparing apples > to oranges. > > My only concern is that, whatever approach we chose, we preserve the > ability of an admin to provide his own, customized, workspace template, > either through a xar, a flavour or whatever, just as long as he still has > the means to build it and deploy it (without having to publish it to a > public extension repository, since it can be private stuff). > I understand. That is why I still have the notion of "wiki templates". An admin can create a new template, customize it, and propose it at the wiki creation. > > > > > > > > > So, I apologize to not having talk here about that. I think that we > > > should, > > > > indeed, refactor a lot of things to have a very clean multiwiki > feature > > > in > > > > 5.3. > > > > > > > > > > > > > > > > > > Basically, you`d right now be using a > > > > $services.wiki.createWiki('newWiki') > > > > > to create the wiki followed by a > > > > > $services.wikiTemplate.apply('someWikiTemplateName', 'newWiki') to > > > > > initialize the wiki with content. > > > > > When we`d have flavours, you`d probably follow the creation step > > with a > > > > > $services.extension.install('someFlavourExtensionID', 'newWiki') > to > > > > > initialize the wiki with the content of a flavour extension. > > > > > We`d probably also want to keep the option of importing the content > > > from > > > > a > > > > > XAR, so that might be a option too. > > > > > > > > > > So this wikiTemplate service would probably contain some methods > > like: > > > > > - create/convert (since the argument would probably be a wikiID to > > mark > > > > as > > > > > template. The content of that wiki would have previously be > > initialized > > > > > from an extension of from a XAR) > > > > > > > > > > > > > I have proposed setTemplate(boolean template); > > > > > > > > > > Maybe setTemplate(String wikiID) as in, > > > $services.wikiTemplate.setTemplate('someWiki') > > > > > > ...or even setTemplate(String wikiID, boolean isTemplate) to avoid > > having a > > > second removeTemplate(String wikiID) method. > > > > > > > Yes, I like this one. > > > > > > > > > > > > > > > > > > > > > > > - list/getAll (wikis marked as templates) > > > > > - delete/revert (remove the template mark, resulting in a regular > > wiki > > > > once > > > > > again) > > > > > - isTemplate (wikiID) > > > > > - apply (as seen above, copy the content to an empty wiki) > > > > > > > > > > > > > I was thinking about createWikiFromTemplate() instead, but maybe it > > does > > > > not provide enough flexibility. > > > > > > > > > > Didn`t you mention something earlier about separation of concerns? :) > > > > > > > > I see the template feature as an helper for the creation of a wiki. We > > don't need template for anything else than the creation of a wiki. So it > > does not disturb me to have createWikiFromTemplate() (which internally > call > > createWiki). > > > > > > > > > > > > > > > > > > > > > Side Note1: It could get a bit ugly fast when having to list wikis. > > > What > > > > do > > > > > you do with templates? What do users see, what do admins see if you > > > plan > > > > to > > > > > have a single view(UI) for everything? Probably 2 UIs would fit > best > > > > > (similar to what we have not with WikiManagerUI and WorkspacesUI). > > The > > > > > WikiManager part would probably go in the main wiki's > administration > > > (for > > > > > admins) and the WorkspacesUI part would be in the main wiki's > > WikiIndex > > > > > (for users). > > > > > > > > > > > > > That is an interesting question. I did not think that much about the > UI > > > > until now. I wanted to have a clean API first. > > > > > > > > > > > I propose, with Caty: > > * 1 UI which is the "Wiki Directory" that display only wikis that users > can > > use > > > * 1 UI, in the administration, to manage templates only. > > > > > > > > > > > > > > > > > > > Side Note2: While thinking about templates, I thought that we might > > > need > > > > > some "copy" and "rename" methods for the WikiManager API, since > they > > > > might > > > > > operations that the user might want to perform without having to > use > > > > > templates or some other weird operations. > > > > > > > > > > > > > - Rename would be hard to implement (copy the wiki and delete it?) > > > > > > > > > > No, just rename the database and the descriptor. Is there any > limitation > > to > > > that? > > > > > > > > There is nothing in the XWikiStoreInterface to rename a database. > > > > - DB2 does not support the database renaming: > > http://bytes.com/topic/db2/answers/185194-i-want-rename-table-schema > > - Derby neither: > > http://apache-database.10148.n7.nabble.com/Rename-Schema-td95708.html > > - Neither oracle: > > > > > http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:3002019… > > > > But it's OK for PostGreSQL, MySQL and HSQLDB. > > > > So, if we want to rename the database from A to B, we can: > > - create the database B > > - import all the data from A into B > > - delete the database A. > > > > > We had the same problem with renaming documents. We did not take it into > account in the initial API/model and then we had to fake it with a > delete+remove. If we have to do the same for wikis, fine, but IMO we have > to include these common sense operations or we will hit them in the future > and we will be forced to do even dirtier things, or worse, leave the user > to have to do them. > > Also, implementation would not be hard (we already do wiki copy and > delete). We`d just need to be careful :) > OK. > > > > > > > > - What "copy a wiki" means? Should we copy the history of every pages > > > too? > > > > Should we copy the recycle bin? I did not want to provide a copy > > feature > > > > because of these questions. The template feature actually does a copy > > > > operation but with its own opinion concerning this aspects : no > history > > > > copied, no recycle bin. > > > > > > > > > > 1-to-1 copy of the source wiki. This means everything. > > > > > > Sure, there might be some applications that use custom mapping and add > > some > > > tables to the source database that might not be copied in the process. > > But, > > > if we have no way of detecting and copying this data, I think it's not > a > > > bit problem. History and recycle bin are core notions of which we have > > full > > > control so they should not be an issue. > > > > > > > Then we need an option to not copy history and recycle bin, because when > > you create a wiki from a template, you don't care about deleted documents > > and the history. Only the template creator needs them. > > > > > > > > > > Anyway, since we`re reviewing these processes and thinking about them > > now, > > > maybe we should do it right. Copy and Rename are basic operations that > > > should not miss from any data model. > > > > > > I agree. > > > > > > > We should *at least* include them in > > > the API and implement them when time allows (and expose them in the UI > > when > > > implemented). It would be a shame to have yet another half baked API. > > > > > > > Can we create an implementation with missing features? > > > > We do things iteratively. I don`t see why we can`t apply that to > implementations of an API, as long as we don`t have any UI using it, thus > risking to crash. > OK. Thanks, Louis-Marie.

11 years, 2 months

Re: [xwiki-devs] [Reminder] BFD#40 (RESULT)

by Thomas Mortagne

Forgot to send that mail, see http://www.xwiki.org/xwiki/bin/view/Blog/Bug+Fixing+Day+40 for the result. On Thu, Oct 17, 2013 at 8:19 AM, Thomas Mortagne <thomas.mortagne(a)xwiki.com> wrote: > Hi devs, > > Today is Bug Fixing Day 40. > > We're currently at 3404 bugs created over 1500 days vs 3376 closed, ie > 28 bugs behind: > http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352 > > 28 is doable so lets see what we got ;) > > Here's the BFD#40 dashboard to follow the progress during the day: > http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=11790 > > -- > Thomas Mortagne -- Thomas Mortagne

11 years, 2 months

[xwiki-devs] Get rid of xwiki-trunks

by Thomas Mortagne

Hi devs, Just seen that https://github.com/xwiki/xwiki-trunks is broken since we moved XEM. I don't use it and I'm pretty sure most of you don't use it either so I propose to get rid of it. I never found it really useful so I propose to stop maintaining it. WDYT ? -- Thomas Mortagne

11 years, 2 months

[xwiki-devs] [Idea] Comparison feature for Extension Manager UI

by Vincent Massol

Use case: Be able to compare an existing wiki with an extension. For example compare my wiki with xwiki-enterprise-common-ui to see the differences I have in my wiki. Implementation idea: We could imagine an extra action in the EM UI: when listing an Extension, you can now Install/Remove/Upgrade. We could imagine a secondary option to "Compare". Clicking it would compare the extension with the current pages in the wiki, showing diffs for all pages contained in the extension vs pages on the wiki. For example if you pick the Blog UI, the "Compare" button would compare the blog app in the listed version with the current blog pages in the wiki. And if you select the xwiki-enterprise-common-ui extension it'll do the same but comparing a lot more pages. We could also imagine listing pages available in the wiki but not listed in the extension selected. WDYT? Real use case: I'd like to verify on xwiki.org wikis their state and what differences they have with the default "distribution". It would also be interesting and useful for us to verify the DW works well and doesn't do anything strange. And it would allow building trust with users. Subsidiary question: how hard would it be to implement this? Thanks -Vincent

11 years, 2 months

[xwiki-devs] Query for self-defined objects

by Matthias Wegner

Hello, i programmed a class /Node/ which is here used as /n/ and a class /NodeType/ which is reference by Node. In the ClassBuilder from Node i use this method to get the NodeType try { List<XWikiDocument> docs = getXWikiContext().getWiki().getStore().searchDocuments(" ", getXWikiContext()); for (XWikiDocument xWikiDocument : docs) { List<BaseObject> objects = xWikiDocument.getXObjects(xWikiDocument.getDocumentReference()); if (objects != null) { for (BaseObject bo : objects) { if (bo.getName().contains("QuarXs.NodeTypeClass")) { DefaultNodeType nt = new DefaultNodeType(); nt.setName(bo.getStringValue("name")); nt.setGuid(bo.getGuid()); n.setType(nt); } } } } } catch (Exception ee) { System.out.println("Error: " + ee); } To test this i defined a class from a wiki-page named "NodeTypeClass" in Space "QuarXs". But now i used /AbstractMandatoryDocumentInitializer/ to initialize everything. The Initialization works fine and looks great, but now my upper method is not working. I can define objects and reference to NodeType, but can't find objects of type "NodeType" with the upper method. Can you give me a hint? I checked it with {{groovy}} import org.rogatio.quarxs.Node; for (Node node : services.component.getComponentManager().getInstanceList(Node.class)) { println("* "+node.getPrettyId() ) println("** "+node.getType()) // gives back null. Reason: No BaseObject of class "QuarXs.NodeTypeClass" found with upper method // println("** "+node.getType().getName()) // worked fine when i made the classes by hand } {{/groovy}} If you like i post my code. Regards, Matthias -- View this message in context: http://xwiki.475771.n2.nabble.com/Query-for-self-defined-objects-tp7587586.… Sent from the XWiki- Dev mailing list archive at Nabble.com.

11 years, 2 months

[xwiki-devs] [Proposal] Add a wiki filling event

by Guillaume "Louis-Marie" Delhumeau

Hi devs! When we create a subwiki from a template, we import a lot of documents that are then displayed in the Activity Stream, and it should not (cf: http://jira.xwiki.org/browse/XWIKI-9489 ). Following the Sergui's advice, I have created a Pull Request that create a new interface called TransientEvent. A transient event means an event that should not be seen by users but that the system can care about it. Moreover, coupled with begin/end events, it means that every events related to a transient event should not be shown to users neither. I don't really like this name because, in my opinion, all events are ephemerals. But at least this interface can solve this problem. But we don't want to hide the fact that a new wiki has been created. Displaying a message concerning the creation of a wiki is a valid use-case. What we want to hide is the import of a lot of documents during the "initialization" phase of that wiki. That is why I propose to create a new event: WikiFillingEvent, which will be transient. It will be associated to a begin/end events so every document creation during this filling process will be hidden in the AS. I'm not sure about the name, but I think we need it. WDYT? LM

11 years, 2 months

[xwiki-devs] [QA] Feedback for 5.3M1

by Manuel Smeria

Hi devs, XWiki 5.3M1 is scheduled to be released the next Monday. I'll go through the list of bugs fixed for it and also take a look at the new features. Besides these, do you want something else tested as well ? Thank you, Manuel

11 years, 2 months

[xwiki-devs] [Reminder] BFD#40

by Thomas Mortagne

Hi devs, Today is Bug Fixing Day 40. We're currently at 3404 bugs created over 1500 days vs 3376 closed, ie 28 bugs behind: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352 28 is doable so lets see what we got ;) Here's the BFD#40 dashboard to follow the progress during the day: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=11790 -- Thomas Mortagne

11 years, 2 months

[xwiki-devs] [Proposal] Roadmap for XWiki 5.3

by Vincent Massol

Hi devs, Here's some proposal based on discussions with various committers (those from XWiki SAS) and based on our past roadmap leftovers: Content ======= * We need to ensure the SOLR Search is working perfectly well so that it can replace our Lucene search. We've recently found a big limitation (http://jira.xwiki.org/browse/XWIKI-9508) which prevents it from being used in the same way the Lucene search was used before. In addition there are some improvements to make to it (the list of jira issues need to be reviewed). I've discussed with Marius and he's ok to work on this for 5.3. * Continue working on the workspaces integration by default in XWiki Enterprise - Guillaume Delhumeau - integrate creation of "farm mode wiki" (i.e. local users allowed) - internal refactoring to move all wiki-related code to new xwiki-platform-wiki modules - and more… * Finish scalable import/export (and make it the default) - Thomas Mortagne * Implement Confluence import using wikistream - Thomas Mortagne * Improvements on EM/DW - Thomas Mortagne and Marius as time permits (secondary priority compared to SOLR search and import/export+confluence import) * Security: Continue work started by Thomas Delafosse on Script signing - Denis Gervalle * If time permits: AWM improvements (export and publish of applications + others) - Marius Here are also some JIRA issues that were raised as important (in this order of importance): * XWIKI-9117: When upgrading a wiki, do not display what happened (files edited, etc.) in the Activity Stream * XWIKI-9046: Improve document save performance by not loading the full history * XWIKI-6700: Copying a page over an existing one does not warn user * XWIKI-7377: AWM Add the ability to publish an application as an extension * XWIKI-5146: Support LiveTable text filtering on DBListclass columns * XWIKI-9156: The Wiki UIExtensions should check the rights before executing extension points * XWIKI-8763: Improve AWM for it to deal with error messages directly in the edit mode * XWIKI-9227: Extend the link creation feature for XEM * XWIKI-8757: Support 2 roles for users for app within minutes: application creator and data creator * XWIKI-9233: Cannot save a wiki page containing a link towards a page with a full name >255 For committers for whom I've suggested a name next to items above, is it ok for you to work on this in 5.3? Please make sure you create ASAP the full list of JIRAs that you're committing to work on for XWiki 5.3 and that you put them on the roadmap page at http://www.xwiki.org/xwiki/bin/view/Roadmaps/WebHome For committers not listed, anything special you wish to work on for 5.3? Dates ===== 5.3M1: 21st of October (2-3 weeks depending on when we release 5.2 final) 5.3M2: 4th of November (2 weeks) 5.3RC1: 18th of November (2 weeks) 5.3Final: 25th of December (1 week) This allows to keep the November period for 5.3 final as planned initially so that we can have 5.4 in December and 5.5 in January. WDYT? Thanks everyone! -Vincent

11 years, 2 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs October 2013