November 2010 - xwiki-devs@xwiki.org

[xwiki-devs] Office document converter configuration
by Marius Dumitru Florea 26 Nov '10

26 Nov '10

Hi devs, Currently, the office importer module doesn't expose any configuration options for the office document conversion. Most of the available parameters are used to control the connection to the open office server. Office importer module uses jodconverter ( http://code.google.com/p/jodconverter/ ) to convert from different office document formats to HTML. The conversion is controlled by a "document format registry". jodconverter provides two DocumentFormatRegistry implementations: * a default implementation, that can be configured only programmatically; this is the one we're currently using * an implementation that reads the configuration from a JSON file; this is easy to overwrite by putting a document-formats.js file (with the JSON configuration) in /WEB-INF/classes/ I'd like to change the office import module to use the JSON document format registry if possible (i.e. document-formats.js is present and can be parsed) otherwise the default document format registry. This will allow us to control, for instance, the size of the images generated when importing/viewing a presentation (the default size is 640x480 which is not enough if you have slides with a lot of information). Do you think this is worth introducing in 2.7 or should I wait for 3.0? Thanks, Marius

5 6

[xwiki-devs] [Investigation] User Statuses
by Ecaterina Moraru (Valica) 26 Nov '10

26 Nov '10

Hi, There are some features that need to be investigated during the XE 2.7 timeframe in order to be able to integrate them in XE 3.0. One of them is **User Statuses** and a main definition for it is: "On top of activity stream <http://code.xwiki.org/xwiki/bin/view/Macros/ActivityMacro>, create a User status & twitter integration feature" The question is what should we integrate and cover if we want to have user statuses in XE. In order to deploy mockups I need to have some clear requirements and uses cases. I create some pages on incubator that will gather this mail discussions at: Requirements: http://incubator.myxwiki.org/xwiki/bin/view/Improvements/UserStatusRequirem… Use Cases: http://incubator.myxwiki.org/xwiki/bin/view/Improvements/UserStatusUseCases While discussing Activity Stream design we had some design scraps for the status casting part http://incubator.myxwiki.org/xwiki/bin/view/Improvements/UserStatusScrap Please share your vision. Thanks, Caty

7 9

Re: [xwiki-devs] [xwiki-notifications] r33131 - in platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki: . api
by Vincent Massol 25 Nov '10

25 Nov '10

wold be good to move it to the existing aspect. Thanks -Vincent On Nov 25, 2010, at 9:28 AM, tmortagne (SVN) wrote: > Author: tmortagne > Date: 2010-11-25 09:28:29 +0100 (Thu, 25 Nov 2010) > New Revision: 33131 > > Modified: > platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/XWiki.java > platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/api/XWiki.java > Log: > XWIKI-5725: Deprecate XWiki#parseMessage > > Modified: platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/XWiki.java > =================================================================== > --- platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/XWiki.java 2010-11-24 15:04:26 UTC (rev 33130) > +++ platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/XWiki.java 2010-11-25 08:28:29 UTC (rev 33131) > @@ -7001,6 +7001,11 @@ > return doc.validate(context); > } > > + /** > + * @deprecated use {@link XWikiMessageTool#get(String, List)} instead. You can access message tool using > + * {@link XWikiContext#getMessageTool()}. > + */ > + @Deprecated > public String getMessage(String item, XWikiContext context) > { > XWikiMessageTool msg = context.getMessageTool(); > @@ -7011,6 +7016,11 @@ > } > } > > + /** > + * @deprecated use {@link XWikiMessageTool#get(String, List)} instead. You can access message tool using > + * {@link XWikiContext#getMessageTool()}. > + */ > + @Deprecated > public String parseMessage(String id, XWikiContext context) > { > XWikiMessageTool msg = context.getMessageTool(); > @@ -7018,6 +7028,11 @@ > return parseContent(msg.get(id), context); > } > > + /** > + * @deprecated use {@link XWikiMessageTool#get(String, List)} instead. You can access message tool using > + * {@link XWikiContext#getMessageTool()}. > + */ > + @Deprecated > public String parseMessage(XWikiContext context) > { > String message = (String) context.get("message"); > > Modified: platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/api/XWiki.java > =================================================================== > --- platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/api/XWiki.java 2010-11-24 15:04:26 UTC (rev 33130) > +++ platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/api/XWiki.java 2010-11-25 08:28:29 UTC (rev 33131) > @@ -844,37 +844,46 @@ > } > > /** > - * API to parse the message being stored in the Context A message can be an error message or an information message > - * either as text or as a message ID pointing to ApplicationResources The message is also parse for velocity scripts > + * API to parse the message being stored in the Context. A message can be an error message or an information message > + * either as text or as a message ID pointing to ApplicationResources. The message is also parse for velocity scripts > * > * @return Final message > + * @deprecated use {@link XWikiMessageTool#get(String, List)} instead. From velocity you can access XWikiMessageTool > + * with $msg binding. > */ > + @Deprecated > public String parseMessage() > { > return this.xwiki.parseMessage(getXWikiContext()); > } > > /** > - * API to parse a message A message can be an error message or an information message either as text or as a message > - * ID pointing to ApplicationResources The message is also parse for velocity scripts > + * API to parse a message. A message can be an error message or an information message either as text or as a message > + * ID pointing to ApplicationResources. The message is also parse for velocity scripts > * > * @return Final message > * @param id > * @return the result of the parsed message > + * @deprecated use {@link XWikiMessageTool#get(String, List)} instead. From velocity you can access XWikiMessageTool > + * with $msg binding. > */ > + @Deprecated > public String parseMessage(String id) > { > return this.xwiki.parseMessage(id, getXWikiContext()); > } > > /** > - * API to get a message A message can be an error message or an information message either as text or as a message > - * ID pointing to ApplicationResources The message is also parsed for velocity scripts > + * API to get a message. A message can be an error message or an information message either as text or as a message > + * ID pointing to ApplicationResources. The message is also parsed for velocity scripts > * > * @return Final message > * @param id > * @return the result of the parsed message > + * @deprecated use {@link XWikiMessageTool#get(String, List)} instead. From velocity you can access XWikiMessageTool > + * with $msg binding. > */ > + @Deprecated > public String getMessage(String id) > { > return this.xwiki.getMessage(id, getXWikiContext());

2 1

[xwiki-devs] [Proposal] Deprecate $xwiki.parseMessage
by Thomas Mortagne 25 Nov '10

25 Nov '10

Hi devs, $xwiki.parseMessage is used to parse velocity located in a translation message. Thing it for me it's very bad (bad design and very bad for performances and most of all for security) to have velocity in translation messages which makes $xwiki.parseMessage useless and some other would say a security hole (see http://jira.xwiki.org/jira/browse/XWIKI-5684) So I propose to deprecate it in 2.7 to make sure we don't use that anymore. WDYT ? -- Thomas Mortagne

6 7

[xwiki-devs] [proposal] A different approach to filesystem attachment storage.
by Caleb James DeLisle 23 Nov '10

23 Nov '10

I would like to propose a different method for attachment storage. I have spent some time working on referencing using a UUID and have run into problems with how to garbage collect files if the corresponding database entry should go missing as well as problems with getting UUID standardization approved. I would like to try a different direction. There will be a directory for the wiki, one for the space and one for the document. Inside of the document directory will be the attachments. An attachment called myImage.png attached to the document xwiki:Main.WebHome will be placed in the following location: <filesystem store directory>/xwiki/Main/WebHome/attachments/myImage.png If there is an XWikiAttachment entry in the database, the metadata from that entry will be matched with the attachment. If there is no metadata entry but there is a file, empty metadata will be created. Users will have the option of adding attachments to documents by copying the files into the relevant directory. An escaping scheme will have to be adopted to prevent attachments named ../../../../../etc/passwd or the like. I have not started on this, I would like to see some +1 before I start writing code. WDYT? Caleb

7 8

[xwiki-devs] [discussion] Global and space dashboards implementation
by Anca Luca 23 Nov '10

23 Nov '10

Hi devs, ** short story: ** for XE-722 we'd need to implement the main and spaces dashboards separately ** long story: ** currently we're using the Main.Dashboard page to include in various contexts to create a dashboard (global or space level). Namely, it is used in Main.WebHome (to create the global dashboard) and in all the *.WebHome pages to create the space dashboards. With the implementation of the dashboard macro, now there is a simpler (and better) way to create dashboards, but with a restriction, they should not be generated by a velocity script (because something which is generated programatically cannot be wysiwyg edited). Because of this, the Main.Dashboard cannot be used anymore as is (since it needs velocity to differentiate between space or global dashboard). ** options: ** 1) have the dashboard macro directly in the Main.WebHome and not in an included document. The bad part is that when a translation is edited, it's only that translation which sees the changes, but this is an issue in general 2) for the space dashboards, there are 3 possibilities: a) leave it all in the Main.Dashboard document to be included in all space dashboards ('backwards compatible') b) leave it all in a document to be included but rename it to Main.SpaceDashboard (to be semantic) c) remove any document for this purpose, and write the dashboard macro call directly in the space webhome, since now it should be a lot easier to do that and also to customize it (7-8 lines of code but no wysiwyg, yet), potentially create a template provider for this. Note that a) and b) require a way for the recent activity and tagcloud macros to realize that it's the current space they need to use as the scope, without actually passing the space because that would mean velocity scripting, again. This is not necessarily a bad thing, though. Besides overcoming this, c) has also the advantage that the dashboard will be in the document itself, and not included (I don't have yet a straightforward solution for wysiwyg editing included dashboards). The drawback of c) is that it will be impossible to customize all the space dashboard at once, you'd need to develop a bit to provide that capability. I'd +1 for 1) and I'd choose 2c). WDYT? Thanks a lot, Anca

5 11

[xwiki-devs] [Proposal] Add a http://design.xwiki.org wiki?
by Vincent Massol 23 Nov '10

23 Nov '10

Hi devs, In the same manner that we have playground.xwiki.org, I'd like to propose to have a design.xwiki.org wiki for putting our Designs and Mockups (be them static or dynamic). Right now we have design and mockup information in 2 places: - http://dev.xwiki.org/xwiki/bin/view/Design/ - on incubator.myxwiki.org I'd like to propose that we merge them both on a new http://design.xwiki.org wiki (using latest XE 2.6 version). Note: If we had support for nested spaces I'd have proposed that we do it on the existing dev.xwiki.org wiki but we'll probably need several pages for each Design proposal. On design.xwiki.org I envision a home page listing all Design ideas with the ability to filter by state (implemented, in progress, dead). I envision one space per design idea and each home page would contain a DesignIdea object containing the metadata (status, etc). Similar to what we have on http://dev.xwiki.org/xwiki/bin/view/Design/ WDYT? Thanks -Vincent

5 7

[xwiki-devs] [UserStory] Wiki Archetypes
by coldserenity 23 Nov '10

23 Nov '10

Hi, Devs Recently one idea have crossed my mind. Thought that it might be interesting to XWiki community. It would be nice to implement something like Maven Archetypes, just for Wikis. That is a "XWiki Archetype Plug-in". Imagine a Wiki for software development project (SDP). Its structure might be more or less the same for most of the project. You would have * Place for storing development environment description and set-up * There should also be a place for developers to store some hints, code snippets etc. * A place for "User stories" and communications with customers * Meetings tracking place (where you keep meeting minutes, IRC logs) * List of deliveries and release notes. All of the above is something a modern quality-managed project cannot survive without. And with XWiki it can be gathered into a set of templates in a single *.xar archive like a Maven Archetype. At some level it can be done even with existing tools the XWiki provides. However it can be extended even more: * Archetypes can contain information about plug-ins and extensions they depend on. E.g. there may be a separate meeting minutes application which needs to be installed for our SDP Archetype example. * Parametrized archetypes (e.g. provide project name for SDP Archetype) * Special UI designed to import an archetype (e.g. choose which parts (pages and plug-ins) of the archetype you would want in your Wiki) * Special UI designed to search Wiki Archetype repository * Special UI for extracting an Archetype from existing Wiki Does it sound as a viable user-story? What kinds of other Archetypes you can think of? Does it worth the effort, to be able to quickly start-up your wikis and have them conform to the same style? Regards, Roman -- View this message in context: http://xwiki.475771.n2.nabble.com/UserStory-Wiki-Archetypes-tp5766157p57661… Sent from the XWiki- Dev mailing list archive at Nabble.com.

4 3

[xwiki-devs] [Vote] XWiki.org ColorThemes
by Ecaterina Moraru (Valica) 23 Nov '10

23 Nov '10

Hi, According to the general opinion discussed at http://xwiki.markmail.org/thread/2b3io6wv4yzr324q , proposal 7 had the most votes. Here is the final proposal for XWiki.org Color Themes in the default Colibri skin: http://incubator.myxwiki.org/xwiki/bin/view/Improvements/OrgColorThemes The xars are attached to the page and can be imported if the vote passes. My +1 Thanks, Caty

4 5

[xwiki-devs] XWikiServletURLFactory#getURL(URL, XWikiContext) behavior
by Marius Dumitru Florea 23 Nov '10

23 Nov '10

Hi devs, In revision 30548 (for XE 2.5M1, see http://jira.xwiki.org/jira/browse/XWIKI-5386 ) I changed the behaviour of the XWikiServletURLFactory#getURL(URL, XWikiContext) method. It used to make URLs relative to the current request URL and now it makes URLs relative to the current wiki (set on the xwiki context). Let's take an example: request URL: http://playground.xwiki.org/xwiki/bin/view/Sandbox/TestURL current wiki (set from velocity script): code (code.xwiki.org) URL 1: http://code.xwiki.org/xwiki/bin/view/Main/WebHome URL 2: http://playground.xwiki.org/xwiki/bin/view/Spage/Page Before: (1) http://code.xwiki.org/xwiki/bin/view/Main/WebHome (2) /xwiki/bin/view/Spage/Page Now: (1) /xwiki/bin/view/Main/WebHome (2) http://playground.xwiki.org/xwiki/bin/view/Spage/Page The javadoc of XWikiServletURLFactory#getURL(URL, XWikiContext) is not clear on this: /** * Converts a URL to a relative URL if it's a XWiki URL (keeping only the path + query string + anchor) and leave * the URL unchanged if it's an external URL. * * @param url the URL to convert * @return the converted URL as a string */ So what's the correct behaviour? Thanks, Marius

2 1