On Apr 26, 2013, at 7:56 PM, Marius Dumitru Florea <mariusdumitru.florea(a)xwiki.com>
wrote:
On Fri, Apr 26, 2013 at 1:00 PM, Vincent Massol
<vincent(a)massol.net> wrote:
Hi Denis,
On Apr 26, 2013, at 10:53 AM, Denis Gervalle <dgl(a)softec.lu> 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 <vincent(a)massol.net>
wrote:
>>
>>>
>>> On Apr 26, 2013, at 10:27 AM, "Ecaterina Moraru (Valica)" <
>>> valicac(a)gmail.com> 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
<vincent(a)massol.net>
>>> 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