On Apr 26, 2013, at 10:27 AM, "Ecaterina Moraru (Valica)" <[email protected]> 
wrote:

> 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.

It's not a special one. Right now it already means that if you need to refer to 
a wiki named "mailto" you need to use: "doc:mailto:…";

Thanks
-Vincent

> 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

Reply via email to