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

[xwiki-devs] Tools/approaches to manage Xwiki custom project publicly

by Valdis Vītoliņš

I'm working on a project, which potentially could be useful for more than one customer. Therefore I'm thinking how to manage automated updates for Xwiki content (xar file for partial export) and ../webapps/xwiki (additional jar files and differences/replacements for existing files) folder. On the one hand it should provide easy steps for Linux/web admins, which are not very familiar with Xwiki for upgrading their, on the other hand, it shouldn't be too hard to manage for me also. I assume, it could be some (xwiki?) github project though I wonder, what structure should I have there. To not reinvent the wheel, can you describe what tools/approaches you see as the best? E.g. how you manage content for: https://github.com/xwiki/xwiki-enterprise/tree/master/xwiki-enterprise-ui/s… Thanks! Valdis

12 years, 4 months

2
1
0 0

[xwiki-devs] [Reminder] BFD #20 today

by Marius Dumitru Florea

Hi everyone, Today is BFD20. Our new goal is now to have more bugs closed than created for the past 1000 days! We're behind by 36 bugs, see: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352 Let's try to close the gap during this BFD. Here's the BFD#20 dashboard: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=11517 Thanks Marius

12 years, 4 months

1
0
0 0

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

by Vincent Massol

Hi devs, Content Proposal ============== Here are some ideas for the XWiki 5.1 roadmap which I have already discussed offline with Thomas D, Thomas M, Marius, Caty, Sorin and Manuel! * Thomas D continues to work on security fixes (especially on reviewing Andreas' branch) * First usable version of SOLR implementation - Thomas M for the back end, Caty for the UI design, Marius for the UI implementation and Sorin/Manuel for ensuring the quality of the new SOLR is at least as good as our current Lucene search so that we could switch to the SOLR version ASAP (would be great to be able to do that at the end of 5.1) * Continue weekly BFDs - All * Then, by order of priority and time permitting: ** Horizontal menu - Marius ** Home Page Improvements - Marius + Caty - Needs to be defined precisely by Caty/Marius and jiras created ** AWM Add the ability to publish an application as an extension - Marius ** XWIKI-8495: Unable to edit a page using the WYGIWYG editor after adding a dashboard macro to it ** XWIKI-7905: Cannot change document title from "inline" mode Let me know if this is ok for everyone, especially for those for whom I've put names next to tasks! :) If other devs want to work on other stuff please mention your itch here. I'll then prepare the roadmap page on xwiki.org and ask all devs to create JIRA issues related to their tasks and reference them from the roadmap page. Date Proposal ============ * 5.1M1: 27 May * 5.1M2: 10 June (one week shorter than usual because we've been late by more than 2 weeks on 5.0 so trying to catch up a bit since we'd like to finish the 5.x cycle at year end if possible) * 5.1RC1: 24 June * 5.1 final: 1st of July This would mean: * 5.2 final: around September (counting holidays) * 5.3 final: November (will need to make it a small release) * 5.4 final: December * 5.5 final: January 2014 WDYT? Thanks -Vincent

12 years, 4 months

5
5
0 0

[xwiki-devs] [VOTE] New Link and Image syntax for XWiki Syntax 2.2

by Vincent Massol

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 CONS: * Harder to write typed links * Harder to write references in non xwiki/2.x syntax that would not support link parameters Thanks -Vincent

12 years, 4 months

7
22
0 0

[xwiki-devs] [ANN] XWiki 5.0.1 released

by Thomas Mortagne

The XWiki development team is proud to announce the availability of XWiki 5.0.1. This is a bugfix release triggered by an important bug (the merge was not taking into account syntax and hidden document fields). You can download it here: http://www.xwiki.org/xwiki/bin/view/Main/Download Make sure to review the release notes: http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWiki501 Thanks -The XWiki dev team

12 years, 4 months

1
0
0 0

[xwiki-devs] Need help to upgrade myxwiki.org to 5.0 ASAP

by Vincent Massol

Hi devs, I think we should upgrade myxwiki.org to XWiki 5.0 ASAP. We're supposed to use myxwiki.org as our test bed for latest versions but we're not using it enough. Anyone who some free time/will to help upgrade myxwiki.org to 5.0? Latest upgrades: http://myxwiki.org/xwiki/bin/view/XWiki/UpgradesLog From what I see Marius did an EM/DW upgrade last time so new upgrades should be pretty simple. Thanks -Vincent

12 years, 4 months

2
8
0 0

[xwiki-devs] [xmorpho] XWiki Mobile client: repository updated

by Ludovic Dubost

Hi, The mobile client repository has been renamed https://github.com/xwiki-contrib/xwiki-mobile-morpho and now the code of the latest mobile application is in the trunk. The "v2" branch should not be used anymore and will be deleted soon. Ludovic -- Ludovic Dubost Founder and CEO Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost

12 years, 4 months

1
0
0 0

[xwiki-devs] [Proposal] New URL configuration parameters - Naming choice

by Vincent Massol

Hi devs, I've implemented "XWIKI-3951: Replace oldcore Entity URL parsing by the new URL module" and this means using more the xwiki-platform-url module. It also means replacing the 2 xwiki.cfg properties by new ones located in xwiki.properties. To be replaced: xwiki.virtual.usepath xwiki.virtual.usepath.servletpath New properties: #------------------------------------------------------------------------------------- # URL #------------------------------------------------------------------------------------- #-# IMPORTANT: The URL module is a feature still in development and as such should be considered experimental at the #-# moment. The configuration parameters below are used only in some part of the code at the moment. The idea is to #-# progressively refactor more and more till only the new properties are used. For the moment you should continue to #-# use the following old properties located in xwiki.cfg: #-# xwiki.virtual.usepath #-# xwiki.virtual.usepath.servletpath #-# [Since 5.1M1] #-# The id of the URL format to use. This allows to plug in different implementations and thus allows to completely #-# control the format of XWiki URLs. #-# #-# The default is: # url.format=standard #-# [Since 5.1M1] #-# Defines where the wiki part is defined in a URL pointing to a subwiki #-# If true then the wiki part is located in the URL path (a.k.a path-based), for example: #-# http://server/xwiki/wiki/mywiki/view/Space/Page #-# If false then the wiki part is located in the URL host domain (a.k.a domain-based), for example: #-# http://mywiki.domain/xwiki/bin/view/Space/Page #-# #-# The default is: # url.standard.multiwiki.isPathBased=true #-# [Since 5.1M1] #-# For path-based setups, this property defines the path segment before the one identifying the subwiki in the URL. #-# For example if set to "thewiki", then the following URL will point to a subwiki named "mywiki": #-# http://server/xwiki/thewiki/mywiki/view/Space/Page #-# Note that the mapping in web.xml has to be modified accordingly if you don't use the default value: #-# <servlet-mapping> #-# <servlet-name>action</servlet-name> #-# <url-pattern>/wiki/*</url-pattern> #-# </servlet-mapping> #-# #-# The default is: # url.standard.multiwiki.wikiPathPrefix=wiki We need to decide if we're ok with these new names or if we want something else. Since these are properties used quite often it's important that we agree on the naming. BTW note that I've implemented LegacyStandardURLConfiguration (in xwiki-platform-legacy-url) to fall back to the old xwiki.cfg properties if they are defined. Thomas proposed the following properties instead: url.standard.multiwiki.path.enabled=true|false url.standard.multiwiki.path.prefix=wiki url.standard.multiwiki.domain.enabled=true|false WDYT? Thanks -Vincent

12 years, 4 months

3
3
0 0

[xwiki-devs] [ANN] XWiki 5.0 released

by Thomas Mortagne

The XWiki development team is proud to announce the availability of XWiki 5.0. This is the first version of the new development cycle 5. This release comes with virtual mode enabled and uses the new security authorization module for rights checking. It also brings improvements to the Extension Manager, Distribution Wizard and the WYSIWYG editor. You can download it here: http://www.xwiki.org/xwiki/bin/view/Main/Download Make sure to review the release notes: http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWiki50 Thanks -The XWiki dev team

12 years, 4 months

1
0
0 0

[xwiki-devs] [Contrib] Encryption Application

by Thomas Delafosse

Hi all, I would like to have a repo on xwiki-contrib on github for a little application I've made that enables admins to directly encrypt passwords in the wiki and to choose who should be able to decrypt them. It can be called encryption-application or something like that. Thanks, Thomas

12 years, 4 months

2
4
0 0

[xwiki-devs] [Notice] Going to merge changes related to URL parsing - Need opinion on API removal

by Vincent Massol

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

12 years, 4 months

2
3
0 0

[xwiki-devs] [VOTE] Move XWiki Office to Contrib

by Ecaterina Moraru (Valica)

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

12 years, 4 months

7
9
0 0

[xwiki-devs] [VOTE] Move XWiki Eclipse to Contrib

by Ecaterina Moraru (Valica)

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

12 years, 4 months

7
11
0 0

[xwiki-devs] [Reminder] BFD #19 today

by Vincent Massol

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

12 years, 4 months

1
2
0 0

[xwiki-devs] [Contrib] Repo request for manual test cases

by Sorin Burjan

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

12 years, 4 months

2
1
0 0

[xwiki-devs] A new idea for GSoC 2013

by Buddhiprabha Erabadda

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*

12 years, 4 months

4
12
0 0

[xwiki-devs] [Reminder] BFD #17 + branch

by Vincent Massol

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

12 years, 4 months

3
7
0 0

[xwiki-devs] 5.0 final release

by Marius Dumitru Florea

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

12 years, 4 months

3
5
0 0

[xwiki-devs] Fwd: [xwiki-users] Fwd: [VOTE] New Link and Image syntax for XWiki Syntax 2.2

by Thomas Mortagne

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

12 years, 4 months

1
0
0 0

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

by Vincent Massol

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

12 years, 4 months

5
17
0 0

[xwiki-devs] [Reminder] BFD #18

by Marius Dumitru Florea

We're only 10 bugs away from succeeding in catching up on 2 years! We can make it during this BFD! See http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352 Dashboard for BFD#18: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=11512 Let's do it! Thanks, Marius

12 years, 4 months

4
11
0 0

[xwiki-devs] Maven Central stats for org.xwiki

by Vincent Massol

FYI we can see download stats through https://oss.sonatype.org/index.html#central-stat for XWiki Commons & Rendering Here's a screenshot: https://www.evernote.com/shard/s119/sh/ecca1079-fa72-4a00-b39f-010fd9c2280c… Thanks -Vincent

12 years, 4 months

1
0
0 0

[xwiki-devs] SMTP configuration problem

by O_Sarah

Hi, I have installed XE 4.2-MILESTONE-2 in localhost. I have now to configure the smtp server for users to receive notifications by mails. i tried with gmail (port 587) it works fine but when i try with yahoo or zimbra (port 465) it does not work. Please can someone help me.. i have to do it with zimbra through that port 465. Thanks. -- View this message in context: http://xwiki.475771.n2.nabble.com/SMTP-configuration-problem-tp7584870.html Sent from the XWiki- Dev mailing list archive at Nabble.com.

12 years, 4 months

1
0
0 0

[xwiki-devs] Devs mailing list

by Sarah Princess

Email: oysarah06(a)gmail.com

12 years, 4 months

1
0
0 0

[xwiki-devs] Unknown macro: spaceindex

by vsirota

Hi, We use XWiki for our company's development team and all was working fine until recently... Now, whenever we click on any of the spaces we have created, we get: Unknown macro: spaceindex We used to have this macro/extension working fine and it used to list all the documents in a specific space. Now it throws this error and nothing as far as I am aware has changed in the XWiki's config... Is this a version clash and it cannot download/retrieve that version of that extension? We are using version 4.3-milestone-1 Any advice/help would be much appreciated... Thanks a lot, Vlad -- View this message in context: http://xwiki.475771.n2.nabble.com/Unknown-macro-spaceindex-tp7584802.html Sent from the XWiki- Dev mailing list archive at Nabble.com.

12 years, 4 months

2
2
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs