Hi, There are a lot of things I don't understand, but I'm just curios if you had the same problems when you added 'icon:', 'path:', 'attach:', 'mailto:', etc. Are this words reserved now, a.k.a can not make wikis with these names? Or maybe this case is a special one.
Thanks, Caty On Fri, Apr 26, 2013 at 11:11 AM, Vincent Massol <[email protected]> wrote: > 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 > > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
