[xwiki-devs] [Rendering] Questions raised by XRENDERING-290: "Add support for linking to a user profile page in XWiki Syntax"
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
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
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
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 ? 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
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO
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). 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
On Apr 26, 2013, at 12: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).
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?
BTW we also need to do the same for images. * image:type:reference * image:xwiki:[email protected] becomes "invalid" (ie it looks for a "xwiki" type parser) and you need to use the image:doc:xwiki:Main.WebHome syntax Thanks -Vincent
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
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? 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
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
FTR here' s the work I did to implement solution 1: https://github.com/xwiki/xwiki-rendering/compare/82958ceb6d78%5E...fcdc93e75... I did several things: * Add ability to restrict with type parsers to use for a syntax (did some refactorings at the same time and rewrote/improved unit tests level) * Added new XWiki Syntax 2.2 Thanks -Vincent On Apr 26, 2013, at 10: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
On Fri, Apr 26, 2013 at 10: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".
No this is not what this reference mean, this reference mean current wiki, current space and page names "user: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
-- Thomas Mortagne
On Apr 28, 2013, at 6:43 PM, Thomas Mortagne <[email protected]> wrote:
On Fri, Apr 26, 2013 at 10: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".
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"… :) 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).
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
On Sun, Apr 28, 2013 at 8:27 PM, Vincent Massol <[email protected]> wrote:
On Apr 28, 2013, at 6:43 PM, Thomas Mortagne <[email protected]> wrote:
On Fri, Apr 26, 2013 at 10: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".
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).
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
-- Thomas Mortagne
On Mon, Apr 29, 2013 at 12:27 AM, Thomas Mortagne <[email protected]> wrote:
On Sun, Apr 28, 2013 at 8:27 PM, Vincent Massol <[email protected]> wrote:
On Apr 28, 2013, at 6:43 PM, Thomas Mortagne <[email protected]> wrote:
On Fri, Apr 26, 2013 at 10: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".
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
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
-- Thomas Mortagne
I'm still not sure what's best (listed 5 because it's not worst that other possibilities in my mind right now). -- Thomas Mortagne
On Apr 29, 2013, at 6:13 PM, Thomas Mortagne <[email protected]> wrote:
On Mon, Apr 29, 2013 at 12:27 AM, Thomas Mortagne <[email protected]> wrote:
On Sun, Apr 28, 2013 at 8:27 PM, Vincent Massol <[email protected]> wrote:
On Apr 28, 2013, at 6:43 PM, Thomas Mortagne <[email protected]> wrote:
On Fri, Apr 26, 2013 at 10: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".
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"]]
Just to be sure we understand fully, you're proposing to remove the support for prefixes as part of the reference, right? The fallback would only be for URL and if no URL is found then it would be considered as a doc reference. So for example the following: [[label>>wiki:space.page]] would become a link to a document named "wiki:space.page" and not a link to a document in the wiki wiki, space space and page page, right?
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
Other CONs: * Makes it longer/harder to create a link. Compare: [[label>>evalica||type="user"]] to [[label>>user:evalica]] * Makes it harder to read (see example from previous line) Thanks -Vincent PS: You still didn't say which one you prefer. Since you added Solution 5, should we assume that it's your preference so far? :)
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
On Mon, Apr 29, 2013 at 6:56 PM, Vincent Massol <[email protected]> wrote:
On Apr 29, 2013, at 6:13 PM, Thomas Mortagne <[email protected]> wrote:
On Mon, Apr 29, 2013 at 12:27 AM, Thomas Mortagne <[email protected]> wrote:
On Sun, Apr 28, 2013 at 8:27 PM, Vincent Massol <[email protected]> wrote:
On Apr 28, 2013, at 6:43 PM, Thomas Mortagne <[email protected]> wrote:
On Fri, Apr 26, 2013 at 10: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".
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"]]
Just to be sure we understand fully, you're proposing to remove the support for prefixes as part of the reference, right?
The fallback would only be for URL and if no URL is found then it would be considered as a doc reference.
So for example the following: [[label>>wiki:space.page]] would become a link to a document named "wiki:space.page" and not a link to a document in the wiki wiki, space space and page page, right?
I tough "does not break all the current document ref without explicit type" was clear. Again all I propose is to not have the type in the reference anymore but in the link parameter, [[label>>wiki:space.page]] will stay a link to wiki wiki, space space and page page before you did not provided a type and it's not a URL. The behaviour of not typed reference won't change a bit from the current behaviour, just think about xwiki/2.0.
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
Other CONs: * Makes it longer/harder to create a link. Compare: [[label>>evalica||type="user"]] to [[label>>user:evalica]] * Makes it harder to read (see example from previous line)
Thanks -Vincent
PS: You still didn't say which one you prefer. Since you added Solution 5, should we assume that it's your preference so far? :)
You did not read my mail fully.
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
-- Thomas Mortagne
On Tue, Apr 30, 2013 at 9:50 AM, Thomas Mortagne <[email protected]> wrote:
On Mon, Apr 29, 2013 at 6:56 PM, Vincent Massol <[email protected]> wrote:
On Apr 29, 2013, at 6:13 PM, Thomas Mortagne <[email protected]> wrote:
On Mon, Apr 29, 2013 at 12:27 AM, Thomas Mortagne <[email protected]> wrote:
On Sun, Apr 28, 2013 at 8:27 PM, Vincent Massol <[email protected]> wrote:
On Apr 28, 2013, at 6:43 PM, Thomas Mortagne <[email protected]> wrote:
On Fri, Apr 26, 2013 at 10: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".
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"]]
Just to be sure we understand fully, you're proposing to remove the support for prefixes as part of the reference, right?
The fallback would only be for URL and if no URL is found then it would be considered as a doc reference.
So for example the following: [[label>>wiki:space.page]] would become a link to a document named "wiki:space.page" and not a link to a document in the wiki wiki, space space and page page, right?
I tough "does not break all the current document ref without explicit type" was clear. Again all I propose is to not have the type in the reference anymore but in the link parameter, [[label>>wiki:space.page]] will stay a link to wiki wiki, space space and page page before you did not provided a type and it's not a URL.
s/before/because/
The behaviour of not typed reference won't change a bit from the current behaviour, just think about xwiki/2.0.
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
Other CONs: * Makes it longer/harder to create a link. Compare: [[label>>evalica||type="user"]] to [[label>>user:evalica]] * Makes it harder to read (see example from previous line)
Thanks -Vincent
PS: You still didn't say which one you prefer. Since you added Solution 5, should we assume that it's your preference so far? :)
You did not read my mail fully.
> > 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
-- Thomas Mortagne
-- Thomas Mortagne
Hi Thomas, On Apr 30, 2013, at 9:50 AM, Thomas Mortagne <[email protected]> wrote:
On Mon, Apr 29, 2013 at 6:56 PM, Vincent Massol <[email protected]> wrote:
On Apr 29, 2013, at 6:13 PM, Thomas Mortagne <[email protected]> wrote:
On Mon, Apr 29, 2013 at 12:27 AM, Thomas Mortagne <[email protected]> wrote:
On Sun, Apr 28, 2013 at 8:27 PM, Vincent Massol <[email protected]> wrote:
On Apr 28, 2013, at 6:43 PM, Thomas Mortagne <[email protected]> wrote:
On Fri, Apr 26, 2013 at 10: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".
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"]]
Just to be sure we understand fully, you're proposing to remove the support for prefixes as part of the reference, right?
The fallback would only be for URL and if no URL is found then it would be considered as a doc reference.
So for example the following: [[label>>wiki:space.page]] would become a link to a document named "wiki:space.page" and not a link to a document in the wiki wiki, space space and page page, right?
I tough "does not break all the current document ref without explicit type" was clear.
Thomas, be sure that if I ask it's because I didn't understand something, that's all… Since I'm proposing to do the implementation myself I need to be sure I understand what everyone is proposing. And I'm glad I asked here because I didn't get it the first time.
Again all I propose is to not have the type in the reference anymore but in the link parameter, [[label>>wiki:space.page]] will stay a link to wiki wiki, space space and page page before you did not provided a type and it's not a URL. The behaviour of not typed reference won't change a bit from the current behaviour, just think about xwiki/2.0.
ok, got it now, thanks!
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
Other CONs: * Makes it longer/harder to create a link. Compare: [[label>>evalica||type="user"]] to [[label>>user:evalica]] * Makes it harder to read (see example from previous line)
Thanks -Vincent
PS: You still didn't say which one you prefer. Since you added Solution 5, should we assume that it's your preference so far? :)
You did not read my mail fully.
For some reason you seem to be thinking I'm having some fun not reading your email. Well just so that you know: I'm not… :) I try my best reading everything and if I ask stuff it's because I couldn't find the answer or it wasn't clear to me… In any case, no need to answer now since I'm going to send a new mail with a VOTE with all options since I believe a new syntax is really important and I'd like to make sure we all agree. Thanks -Vincent
> > 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
New thread started, please consider this one closed and use the new thread entitled "[VOTE] New Link and Image syntax for XWiki Syntax 2.2" Thanks -Vincent On Apr 30, 2013, at 10:22 AM, Vincent Massol <[email protected]> wrote:
Hi Thomas,
On Apr 30, 2013, at 9:50 AM, Thomas Mortagne <[email protected]> wrote:
On Mon, Apr 29, 2013 at 6:56 PM, Vincent Massol <[email protected]> wrote:
On Apr 29, 2013, at 6:13 PM, Thomas Mortagne <[email protected]> wrote:
On Mon, Apr 29, 2013 at 12:27 AM, Thomas Mortagne <[email protected]> wrote:
On Sun, Apr 28, 2013 at 8:27 PM, Vincent Massol <[email protected]> wrote:
On Apr 28, 2013, at 6:43 PM, Thomas Mortagne <[email protected]> wrote:
> On Fri, Apr 26, 2013 at 10: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". > > 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"]]
Just to be sure we understand fully, you're proposing to remove the support for prefixes as part of the reference, right?
The fallback would only be for URL and if no URL is found then it would be considered as a doc reference.
So for example the following: [[label>>wiki:space.page]] would become a link to a document named "wiki:space.page" and not a link to a document in the wiki wiki, space space and page page, right?
I tough "does not break all the current document ref without explicit type" was clear.
Thomas, be sure that if I ask it's because I didn't understand something, that's all…
Since I'm proposing to do the implementation myself I need to be sure I understand what everyone is proposing. And I'm glad I asked here because I didn't get it the first time.
Again all I propose is to not have the type in the reference anymore but in the link parameter, [[label>>wiki:space.page]] will stay a link to wiki wiki, space space and page page before you did not provided a type and it's not a URL. The behaviour of not typed reference won't change a bit from the current behaviour, just think about xwiki/2.0.
ok, got it now, thanks!
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
Other CONs: * Makes it longer/harder to create a link. Compare: [[label>>evalica||type="user"]] to [[label>>user:evalica]] * Makes it harder to read (see example from previous line)
Thanks -Vincent
PS: You still didn't say which one you prefer. Since you added Solution 5, should we assume that it's your preference so far? :)
You did not read my mail fully.
For some reason you seem to be thinking I'm having some fun not reading your email. Well just so that you know: I'm not… :) I try my best reading everything and if I ask stuff it's because I couldn't find the answer or it wasn't clear to me…
In any case, no need to answer now since I'm going to send a new mail with a VOTE with all options since I believe a new syntax is really important and I'd like to make sure we all agree.
Thanks -Vincent
>> >> 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
participants (5)
-
Denis Gervalle -
Ecaterina Moraru (Valica) -
Marius Dumitru Florea -
Thomas Mortagne -
Vincent Massol