- xwiki-devs@xwiki.org - lists.xwiki.org

[xwiki-devs] [Notice] Going to merge changes related to URL parsing - Need opinion on API removal
by Vincent Massol 03 May '13

03 May '13

Hi devs, I've worked a bit on the xwiki-platform-url module again and I've refactored more of the XWiki class to use it. I would like to commit this: * Changes for platform: https://github.com/xwiki/xwiki-platform/commit/1505a9030084 * Changes for enterprise: https://github.com/xwiki/xwiki-enterprise/commit/f3b14e42c5a8 In doing so I've removed several public methods from com.xpn.xwiki.XWiki (the internal XWiki class): * public XWikiDocument getDocumentFromPath(String path, XWikiContext context) throws XWikiException * public DocumentReference getDocumentReferenceFromPath(String path, XWikiContext context) * public String getDocumentNameFromPath(String path, XWikiContext context) * public String getDocumentName(XWikiRequest request, XWikiContext context) These are no longer needed since the xwiki-platform-url module provides better replacements. Now even if the removal of these methods don't break CLIRR (since com.xpn.xwiki.XWiki is internal) we need to decide if it's ok to just remove them or if I should move them to the legacy module. I'm asking because it's quite some work (as the previous code relied on classes from the xwiki-platform-url module that don't exist anymore and I would need to also move the code from these removed classes to the legacy module to ensure the same behavior as before). All in all I probably need 1 to 2 days to put all that in the legacy modules. WDYT? Should I do it or is it acceptable that I don't? Note that this is for 5.1M1. Thanks -Vincent

2 3

[xwiki-devs] [VOTE] Move XWiki Office to Contrib
by Ecaterina Moraru (Valica) 03 May '13

03 May '13

Hi devs, There is not much activity for XWiki Office since there are no current active developers working on improving the project. Since XWiki Office is something interesting and useful, we might not want to Retire it, but instead we could mark it as Contrib. This means: * Move JIRA's XWiki Office 'XOFFICE' project from 'Top Level Projects' in 'XWiki Contributed Projects'. This would also help us better manage the number of open issues that are relevant and that we can work on. Right now there are 63+1 issues open for this project. http://jira.xwiki.org/browse/XOFFICE * Move https://github.com/xwiki/xwiki-office to https://github.com/xwiki-contrib/ * Move documentation found on http://xoffice.xwiki.org/ on a page on extensions.xwiki.org (Installation, User Guide, Design, Development, Roadmap, Release Notes) * Remove xoffice.xwiki.org * Update xwiki.org to mark this move (menu, footer, download page, All Projects page in order to still make the project accessible) Tell me what you think, Caty

7 9

[xwiki-devs] [VOTE] Move XWiki Eclipse to Contrib
by Ecaterina Moraru (Valica) 03 May '13

03 May '13

Hi devs, There is not much activity for XWiki Eclipse since there are no current active developers working on improving the project. Since XWiki Eclipse is something interesting and useful, we might not want to retire it, but instead we could mark it as Contrib. This means: * Move JIRA's XWiki Eclipse 'XECLIPSE' project from 'Top Level Projects' in 'XWiki Contributed Projects'. This would also help us better manage the number of open issues that are relevant and that we can work on. Right now there are 51 issues open for this project. http://jira.xwiki.org/browse/XECLIPSE * Move https://github.com/xwiki/xwiki-eclipse to https://github.com/xwiki-contrib/ * Move documentation found on http://xeclipse.xwiki.org/ on a page on extensions.xwiki.org (Installation, User Guide, Release Notes) * Remove xeclipse.xwiki.org * Update xwiki.org to mark this move (menu, footer, download page, All Projects page in order to still make the project accessible) Tell me what you think, Caty

7 11

[xwiki-devs] [Reminder] BFD #19 today
by Vincent Massol 03 May '13

03 May '13

Hi everyone, Today is BFD19. Our new goal is now to have more bugs closed than created for the past 1000 days! We're behind by 53 bugs, see: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352 Let's try to close the gap during this BFD. Would be great to do between 10 to 30. Here's the BFD#19 dashboard: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=11514 Thanks -Vincent

1 2

[xwiki-devs] [Contrib] Repo request for manual test cases
by Sorin Burjan 02 May '13

02 May '13

Hello, I have almost finished converting the manual test cases we have on http://www.xwiki.org/xwiki/bin/view/TestReports/ManualTestReportTemplate to a format which will be used by the Test Reporting Application. Since everyone can contribute/modify existing tests, I'd like to commit them somewhere to be accessible for everyone. So in consequence, I'd like to have a repository. Please note, these are the test cases that we use for manually testing XWiki. They are specific to XWiki. My idea of the name for the repository is: xwikiorg-manualtestcases. If you have a better name, please go ahead and create the repo. Regards, Sorin

2 1

[xwiki-devs] A new idea for GSoC 2013
by Buddhiprabha Erabadda 02 May '13

02 May '13

Hi all, I am Buddhiprabha Erabadda, a final year undergraduate from the Department of Computer Science and Engineering, University of Moratuwa. I have been studying about XWiki from few days now and I have downloaded the xwiki-enterprise-jetty-hsqldb-4.5.3.zip [1] and run it on my Windows machine to understand the client side of XWiki. Now I am getting familiar with the code base, referring to various documentation. [2] After going through XWiki site and particularly News and Blog [3], I decided to come up with a new idea for GSoC 2013 for XWiki. My idea is to develop a mobile news application for XWiki. This will enable users to view news about posts, new releases, fixes, etc through the application. In particular, my proposed application will contain the following. - News will be shown as a thumbnail list: it will contain an image of the author of the news item or an image related to the news item, a title for the news item, and a brief description about the news item. - When a user clicks on the news item, user will be directed to a page with full information regarding that particular news. This application can have following features. - The user can filter news: for example Latest news, news by a specific author, news from a particular period, etc. - Add favourite news: this will enable the user to mark his/her favorite items and there by access them at a later point of time. - Enable adding comments from the application This is the basic outline of my proposed mobile application. I expect to implement this as a PhoneGap application. Using PhoneGap to develop the application will enable it to be run on multiple platforms, including Android, iOS, etc. The application will be beneficial for everyone including users and developers of XWiki because it will enable them to be updated on the go using a mobile application. I would like to know your opinion on the idea of having the proposed mobile news application. Please add to list of features if you have better or new ideas for them. I participated for GSoC 2012 under DocBook organization for the project “DocBook to Word XML roundtripping XSLs” and successfully completed my project. [4] [5] I would like to contribute to XWiki in GSoC 2013 and I hope to know your idea about my proposed mobile application. Thank you in advance. [1] http://enterprise.xwiki.org/xwiki/bin/view/Main/Download [2] http://dev.xwiki.org/xwiki/bin/view/Main/WebHome [3] http://www.xwiki.org/xwiki/bin/view/Main/News [4] http://www.google-melange.com/gsoc/project/google/gsoc2012/buddhiprabha/150… [5] https://docbook.svn.sourceforge.net/svnroot/docbook/branches/gsoc-2012/roun… -- *Buddhiprabha Erabadda* *Department of Computer Science and Engineering* *University of Moratuwa*

4 12

[xwiki-devs] [Reminder] BFD #17 + branch
by Vincent Massol 02 May '13

02 May '13

Hi, Tomorrow starts BFD#17. Since I'll be travelling I won't be able to participate so I wish you a good BFD! :) One important remark: We're currently stabilizing 5.0RC1 and I think it would be a bad idea to commit BFD bug fixes for RC1 tomorrow. I'm proposing instead that we create a stable-5.0.x branch right now from master and that master becomes 5.1M1 and that tomorrow we commit on master (and backport on the stable-5.0.x branch if we are really sure of the fix and we think it's needed for 5.0). WDYT? If agreed, who could do this? Thanks -Vincent

3 7

[xwiki-devs] 5.0 final release
by Marius Dumitru Florea 30 Apr '13

30 Apr '13

Hi devs, The release is planned for today. I'd like to start the release before noon (EET). Let me know if there are any issues that may block the release. Thanks, Marius

3 5

[xwiki-devs] Fwd: [xwiki-users] Fwd: [VOTE] New Link and Image syntax for XWiki Syntax 2.2
by Thomas Mortagne 30 Apr '13

30 Apr '13

On Tue, Apr 30, 2013 at 11:09 AM, Vincent Massol <vincent(a)massol.net> wrote: > Forwarding to users list since it's interesting to know what users think about this for the new XWiki Syntax 2.2 too. > > Please give your opinion. > > Thanks > -Vincent > > Begin forwarded message: > >> From: Vincent Massol <vincent(a)massol.net> >> Subject: [VOTE] New Link and Image syntax for XWiki Syntax 2.2 >> Date: April 30, 2013 11:02:43 AM GMT+02:00 >> To: XWiki Developers <devs(a)xwiki.org> >> >> Hi devs, >> >> Following this thread http://markmail.org/thread/vw3derowozijqalr it seems clear that we need to introduce a better syntax for links and images in XWiki Syntax 2.2 (in order to cope with use cases such as http://jira.xwiki.org/jira/browse/XRENDERING-290) >> >> The need is to be able to plug new reference type handlers without breaking backward compatibility in XWiki Syntax 2.2 (since right now with XWiki Syntax 2.0 and 2.1 adding a new type reference handler would break backward compatibility). >> >> So here are various proposals to that effect for XWiki Syntax 2.2 (I've only kept the interesting proposals from the previous thread). Please vote for the one you prefer or add new solutions if you have other better ideas. >> >> Proposal 1 >> ========= >> >> Force XWiki Syntax 2.2 to *ALWAYS* use the full form when creating a link or image, i.e. all links would need to be written: [[label>>type:reference]] >> >> Examples: >> * [[label>>doc:space.page]] >> * [[label>>doc:wiki:space.page]] >> * [[label>>path:/some/path]] >> * [[label>>url:http://xwiki.org]] >> * [[label>>user:evalica]] >> * [[image:doc:wiki:space.page@image.png]] >> * [[image:icon:someicon.png]] >> >> CONS: >> * Harder to write links to documents which is the main use case >> >> Proposal 2 >> ========= >> >> Same as with XWiki Syntax 2.1 but for links or images to subwikis force the user to use the "doc:" notation >> >> Examples: >> * [[label>>space.page]] or [[label>>doc:space.page]] >> * [[label>>doc:wiki:space.page]] >> * [[label>>>path:/some/path]] >> * [[label>>http://xwiki.org]] or [[label>>>url:http://xwiki.org]] >> * [[label>>user:evalica]] >> * [[image:doc:wiki:space.page@image.png]] >> * [[image:icon:someicon.png]] >> >> PRO: >> * Still easy to reference docs and images in the current wiki >> * Close to current XWiki Syntax 2.1 >> >> CONS: >> * Harder to write links to documents in subwikis (for workspaces users for example, see example of xwiki.org) >> >> Proposal 3 >> ========= >> >> Always define the type as a link or image parameter, i.e. separate subwiki notation from type. >> >> Examples: >> * [[label>>space.page]] or [[label>>space.page||type="doc"]] >> * [[label>>wiki:space.page]] or [[label>>wiki:space.page||type="doc"]] >> * [[label>>>/some/path||type="path"]] >> * [[label>>http://xwiki.org]] or [[label>>>http://xwiki.org||type="url"]] >> * [[label>>evalica||type="user"]] >> * [[image:wiki:space.page@image.png]] or [[image:wiki:space.page@image.png||type="doc"]] >> * [[image:someicon.png||type="icon"]] >> >> PRO: >> * Still easy to reference docs >> * Clear separation between subwiki and types Funny thing is that this proposal is compatible with xwiki/2.0 syntax. >> >> CONS: >> * Harder to write typed links >> * Harder to write references in non xwiki/2.x syntax that would not support link parameters >> >> Thanks >> -Vincent >> >> > > _______________________________________________ > users mailing list > users(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/users I'm more for proposals 1 and 3 for their clarity but I'm pretty sure most people will hate have to put doc: everywhere so here is my +1 for 3 for now. But don't rush I would like to take some more time to think about it. -- Thomas Mortagne

1 0

[xwiki-devs] [Rendering] Questions raised by XRENDERING-290: "Add support for linking to a user profile page in XWiki Syntax"
by Vincent Massol 30 Apr '13

30 Apr '13

Hi devs, I've started implementing XRENDERING-290 (I've spent already 1 day on it and have most of it done) but as I progressed I've realized we need to decide on something. It's an interesting problem! :) So the issues asks for support a "user" prefix in links to link to user profiles such as in: [[label>>user:evalica]] Explanation of Problem ================== I started with implementing a new Reference Type Parser to add support for the "user" prefix. I soon realized that we cannot implement this in XWiki Syntax 2.1 since it means if a user currently has [[label>>user:evalica]] it means pointing to the "user" wiki and to the page named "evalica". Thus we need to add this in a new syntax only (i.e. XWiki Syntax 2.2). Now the problem is that currently Reference Type Parsers are components and implementing a new component means it's going to be available to XWiki Syntax 2.1. So I spent a substantial amount of time to allow syntaxes to specifically specify the list of prefixes that they support. This is done, I just need to push it. Now this all looked good till I started implementing the UserXHTMLLinkTypeRenderer… I realized that I would need to be able to transform a String (supposed to represent a username) into a User reference and even though we don't have an API for this ATM this would normally mean to depend on the Platform User module… which is a big no go since Rendering cannot depend on Platform. Side Note:I also realized that XRENDERING-290 could also be extended to support displaying the user's avatar with image:user:evalica. This is currently done with the {{useravatar}} macro (which is also wrongly located in Rendering and should be in platform for the reason explained!!). So I thought I could just have the UserResourceReferenceTypeParser and UserXHTMLLinkTypeRenderer classes implemented in the Platform User module but that still meant that the XWiki Syntax 2.2 needs to reserve the "user" prefix. Then I realized that any time we will want to add support for a new prefix we would need to introduce a new Syntax version which is a huge PITA and a pity. I thought about several solutions. Solution 1 ======== * Consider that each syntax can reserve prefix type namespaces and this just means that if the user wants to write a link to a document a wiki named after one of these prefixes then he needs to use the full format: [[label>>doc:<wikiname>:….]] * Thus XWiki Syntax 2.2 would just add the "user" prefix to the reserved list of prefix type namespaces. PRO: * I have this code ready to be pushed on my computer * Doesn't change the current XWiki Syntax notation CONS: * Requires a new syntax whenever a new type parser is added (after a syntax has been released as final) * Creates a relationship between the syntax and implementations (the User module will provide an impl. for supporting the reserved "user" namespace). Solution 2 ======== * Don't implement support for linking to users using resource types and add a {{userlink}} macro and move both macros in platform. PRO: * Simple, no need for a new XWiki Syntax CONS: * Not integrated in the syntax * Not very logical since as a user you would want to write: [[label>>user:evalica]] Solution 3 ======== Force XWiki Syntax 2.2 to *ALWAYS* use the full form when creating a link, i.e. all links to doc would need to be written: [[label>>doc:reference]] PRO: * Solves all future needs for new reference types and makes the syntax extensible for this. CONS: * Harder to write links to documents and users will need to get used to it Solution 4 ======== Invent a new syntax when you wish to write links using a type prefix and keep the current link syntax for references to documents: * Ref to a doc: [[label>>docref]] (e.g. [[label>>xwiki:Main.WebHome]]) * Ref to anything but using the type prefix: [[label>>>prefix:reference]] (e.g. [[label>>>doc:doc:Main.WebHome]]: link to a wiki named "doc") PRO: * Still easy to make refs to documents * Makes the syntax extensible by allowing new types to be added CONS: * Changes the syntaxes since it means introducing a new link notation [[label>>>ref]]. Also means that references to docs cannot start with ">" anymore (but that's not a real issue IMO) * A bit more complex to implement obviously since it needs a change to the javacc parser Conclusion ========== My POV: * The more correct solution is solution 3 but it makes harder to write links to documents so I believe that's going to be a problem since it's the main use case. * Solution 1 is already implemented on my computer and I just need to make a push to have it so the simplest for me. I think it could be acceptable since we don't introduce new type parsers all the time. But it's not perfect obviously. * Solution 4 is the most tempting for me even though it's more work. I've suggested ">>>" but we could imagine a different notation. Other ideas include using [[label>>doc:doc:Main.WebHome||typed="true"]] (ie setting a "type" param to mention that it's referring to a typed reference). It has the advantage of not requiring changes to the javacc parser but it has more chars to type for the user and is thus more complex for the user. Do you have an opinion? WDYT? Should I push what I have for now and make changes later? Thanks -Vincent

5 17