On Apr 26, 2013, at 7:56 PM, Marius Dumitru Florea <[email protected]> wrote:
> On Fri, Apr 26, 2013 at 1:00 PM, Vincent Massol <[email protected]> wrote: >> Hi Denis, >> >> On Apr 26, 2013, at 10:53 AM, Denis Gervalle <[email protected]> wrote: >> >>> Hi Vincent, >>> >>> As I said on IRC, I am afraid that all your solutions increase complexity >>> for not much, especially for user having a single wiki. >>> To keep things simple, 1) without syntax version change would be sufficient >>> in most cases, but could cause some unexpected breakage. If we want to get >>> rid of those, let's go for a simplification of 3), where only links to >>> other wikis require the doc: prefix. This would be a single new syntax >>> version, and will allow dynamic addition of new prefix for the future. >>> >>> So we would have only two possibilities for documents (parenthesis meaning >>> optional): >>> doc:(wiki:)(space.)name >>> (doc:)(space.)name >>> >>> WDYT ? >> >> So to recap what you're proposing: >> >> Solution 3bis >> =========== >> >> * For links to docs in subwikis force the user to use the "doc:" notation >> >> PRO: >> * Solves all future needs for new reference types and makes the syntax >> extensible since it allows to plug new type parsers without breaking the >> syntax >> >> CONS: >> * Harder to write links to documents in subwikis (for workspaces users for >> example) >> >> Analysis >> ======= >> >> I agree that this solution is better than solution 3 below. >> >> So from an algorithm point of view this means: >> * Looks for a prefix type >> ** If a prefix is found use the registered type parser if it exists >> ** If the prefix is found but there *NO* type parser for that prefix, DO >> SOMETHING >> * If no prefix is found then >> ** if the reference starts with "[a-zA-Z0-9+.-]*://" then do as now and >> consider it a URL >> ** otherwise consider it a reference to a document >> >> So the only change from the current code is the "DO SOMETHING" part which we >> don't have (ATM we then default to considering it a reference to a document). >> >> The only solution that really makes sense is to generate an Error block as >> we do for macros to mention to the user that the used prefix doesn't exist >> (and maybe mention that if he wanted to point to a doc in another wiki he >> should use the "doc:" notation). > > This is for XWiki 2.2 syntax right? yes Thanks -Vincent > Thanks, > Marius > >> >> Sounds not too bad but I'd have preferred a more seamless solution for the >> user with less typing when referencing a doc in another subwiki. Ideally the >> use case of adding new type parser is not that common that we should make >> the user suffer from having to prefix everything with "doc:". Now it's >> probably the best solution from all proposed so far if we want to support >> plugging in any new type parser in the future in XWiki Syntax 2.2. >> >> WDTY? >> >> Thanks >> -Vincent >> >> PS: Sniff almost all my code developed during one day will go to the trash >> if we choose this… :) >> >>> On Fri, Apr 26, 2013 at 10:42 AM, Vincent Massol <[email protected]> wrote: >>> >>>> >>>> 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
