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

On Mon, Apr 29, 2013 at 12:27 AM, Thomas Mortagne &lt;thomas.mortagne(a)xwiki.com&gt; wrote: > On Sun, Apr 28, 2013 at 8:27 PM, Vincent Massol &lt;vincent(a)massol.net&gt; wrote: >> >> On Apr 28, 2013, at 6:43 PM, Thomas Mortagne &lt;thomas.mortagne(a)xwiki.com&gt; wrote: >> >>> On Fri, Apr 26, 2013 at 10:11 AM, Vincent Massol &lt;vincent(a)massol.net&gt; 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". >>> >>> No this is not what this reference mean, this reference mean current >>> wiki, current space and page names "user:evalica". >> >> Indeed, good remark :) >> >> Now I don't think it changes the rest of the email. For example you could imagine a user named "vincent.massol" and the reference would be: "user:vincent.massol"… :) > > Right now a user with a dot would not work well but nothing prevent > having a document named "user:evalica" so yes it does not change the > issue. > >> >> Thanks >> -Vincent >> >>>> 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). -1, does not make any sense to me. Link type is supposed to be expendable and is not supposed to be finite list of types. >>>> >>>> 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]] This "solution" is the same as not doing anything. I don't really care about having user reference but we will need to introduce new link types that's for sure so we will have to find a solution to make link type syntax stronger at some point. >>>> >>>> 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 Solution 5 ======== Separate the type from the first level type and keep the same fallack we have now when the type is not explicitely provide. Here are some example: * [[label>>docref]] * [[label>>http://someexternalurl]] * [[label>>docref||type="doc"]] * [[label>>/bin/view/Space/Page||type="path"]]

PROS: * does not break all the current document ref without explicit type * makes clear what is the type of the reference and what is the actual type CONS: * change the syntax of explicitly typed links (but not really bigger than 4) * harder to type reference in non xwiki/2.x syntax that would not support link parameters