[xwiki-devs] [Rendering] Image support & Parameters for links/images
Hi, There are 2 features I need to finish implementing for the new rendering and I have some doubts. 1) Parameters for links Problem ======= We decided to use the (% param=value %)[[link]] notation. However this is raising some issues. First the user needs to close the parameter list so that it doesn't affect other elements coming after. For example: (% rel="_blank" %)[[link]](%%) hello is different from: (% rel="_blank" %)[[link]] hello In the second case the rel="_blank" applied to both the link, the space and the word "hello". However if we consider the params to only apply the link then we cannot set params anymore that span more than the link. For example: (% style="color:red" %)[[link]] and some text(%%) Note that technically the params currently generate a <span> element with the params as attributes. Thus right now using rel="_blank" is set on the span and not on the <a> element which means it doesn't work. Solutions ======= a) Add again the notion of parameters inside the link syntax: [[label>>reference>>>param=value...]] (or using some other separator) b) Use a different syntax for link parameters, for ex: {% param=value %}[[link]] (but I really don't like it) c) Force the params in the (% %)[[link]] notation to always apply only to the link and thus force users to use a space if they want to start a styled portion of text beginning with a link: (% param=value %) [[link]] something else %) As much as I hate having to recode what I've removed, I think the best solution is a). 2) Syntax for images Problem ======= We had decided to use the following syntax: image:wiki:Space.Page^my.png (note: not sure we agreed about the use of ^ but that's a detail - I couldn't find the email where we discussed that) The question is how do we set parameters for images. For example: alt, title, width, height, etc? We have the exact same problem as for links but it's even worse since we don't have the ability to define the parameters inside the image syntax since the image syntax is too limited. Solutions ======= a) Use a different syntax such as: !!label>>image>>>param=value...!! (note that there are several wikis using the !! notation for images, including confluence) Ex: !!my.png!! !!my image>>my.png!! !!wiki:Space.Page^my.png>>>width=100 height=200!! b) Decide not to have a syntax for images and instead use an image macro. Ex: {{image name="my.png" document="wiki:Space.Page" width="100" height="200"/}} Note that there's one problem with not having a syntax for images in the grammar: it makes it harder to convert from one syntax for another. For example people using wikimodel wouldn't be able to convert from xwiki to another syntax easily and viceversa. In XWiki itself we would need to have some extra handling code to handle the fact that the image is a macro to convert it to another syntax but that's possible (not the easiest but possible). WDYT for 1) and 2)? My choice: 1) a) For 2) I'd prefer to have a syntax for images (for the conversion between syntaxes issue and for the fact that the syntax wouldn't be complete - We've added tables in the syntax so it would be a pity not to have a syntax for images IMO). There's only possibility though: that we add {{image...}} in the syntax, so it would generate an onImage() event in XWiki and we would just convert it internally to an image macro. Ideally I'd still prefer a clean syntax but that'd be my second choice. Thanks -Vincent
After discussing with Anca and Marius, here's another potential solution: * use (% param=value %) notation to set the params on the element following it * use {% param=value %}... {%%} notation to create a span and thus set the params on whatever is inside it This makes it consistent with block level params which are set on the next element. We would still need to define the syntax for images. Thanks -Vincent On Oct 27, 2008, at 10:59 AM, Vincent Massol wrote:
Hi,
There are 2 features I need to finish implementing for the new rendering and I have some doubts.
1) Parameters for links
Problem =======
We decided to use the (% param=value %)[[link]] notation. However this is raising some issues.
First the user needs to close the parameter list so that it doesn't affect other elements coming after.
For example:
(% rel="_blank" %)[[link]](%%) hello
is different from:
(% rel="_blank" %)[[link]] hello
In the second case the rel="_blank" applied to both the link, the space and the word "hello".
However if we consider the params to only apply the link then we cannot set params anymore that span more than the link.
For example: (% style="color:red" %)[[link]] and some text(%%)
Note that technically the params currently generate a <span> element with the params as attributes. Thus right now using rel="_blank" is set on the span and not on the <a> element which means it doesn't work.
Solutions =======
a) Add again the notion of parameters inside the link syntax: [[label>>reference>>>param=value...]] (or using some other separator) b) Use a different syntax for link parameters, for ex: {% param=value %}[[link]] (but I really don't like it) c) Force the params in the (% %)[[link]] notation to always apply only to the link and thus force users to use a space if they want to start a styled portion of text beginning with a link: (% param=value %) [[link]] something else %)
As much as I hate having to recode what I've removed, I think the best solution is a).
2) Syntax for images
Problem =======
We had decided to use the following syntax: image:wiki:Space.Page^my.png (note: not sure we agreed about the use of ^ but that's a detail - I couldn't find the email where we discussed that)
The question is how do we set parameters for images. For example: alt, title, width, height, etc?
We have the exact same problem as for links but it's even worse since we don't have the ability to define the parameters inside the image syntax since the image syntax is too limited.
Solutions =======
a) Use a different syntax such as:
!!label>>image>>>param=value...!!
(note that there are several wikis using the !! notation for images, including confluence)
Ex: !!my.png!! !!my image>>my.png!! !!wiki:Space.Page^my.png>>>width=100 height=200!!
b) Decide not to have a syntax for images and instead use an image macro.
Ex: {{image name="my.png" document="wiki:Space.Page" width="100" height="200"/}}
Note that there's one problem with not having a syntax for images in the grammar: it makes it harder to convert from one syntax for another. For example people using wikimodel wouldn't be able to convert from xwiki to another syntax easily and viceversa. In XWiki itself we would need to have some extra handling code to handle the fact that the image is a macro to convert it to another syntax but that's possible (not the easiest but possible).
WDYT for 1) and 2)?
My choice:
1) a)
For 2) I'd prefer to have a syntax for images (for the conversion between syntaxes issue and for the fact that the syntax wouldn't be complete - We've added tables in the syntax so it would be a pity not to have a syntax for images IMO). There's only possibility though: that we add {{image...}} in the syntax, so it would generate an onImage() event in XWiki and we would just convert it internally to an image macro. Ideally I'd still prefer a clean syntax but that'd be my second choice.
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Vincent Massol wrote:
Hi,
There are 2 features I need to finish implementing for the new rendering and I have some doubts.
1) Parameters for links
Problem =======
We decided to use the (% param=value %)[[link]] notation. However this is raising some issues.
First the user needs to close the parameter list so that it doesn't affect other elements coming after.
For example:
(% rel="_blank" %)[[link]](%%) hello
is different from:
(% rel="_blank" %)[[link]] hello
In the second case the rel="_blank" applied to both the link, the space and the word "hello".
However if we consider the params to only apply the link then we cannot set params anymore that span more than the link.
For example: (% style="color:red" %)[[link]] and some text(%%)
Note that technically the params currently generate a <span> element with the params as attributes. Thus right now using rel="_blank" is set on the span and not on the <a> element which means it doesn't work.
Solutions =======
a) Add again the notion of parameters inside the link syntax: [[label>>reference>>>param=value...]] (or using some other separator) b) Use a different syntax for link parameters, for ex: {% param=value %}[[link]] (but I really don't like it) c) Force the params in the (% %)[[link]] notation to always apply only to the link and thus force users to use a space if they want to start a styled portion of text beginning with a link: (% param=value %) [[link]] something else %)
As much as I hate having to recode what I've removed, I think the best solution is a).
2) Syntax for images
Problem =======
We had decided to use the following syntax: image:wiki:Space.Page^my.png (note: not sure we agreed about the use of ^ but that's a detail - I couldn't find the email where we discussed that)
The question is how do we set parameters for images. For example: alt, title, width, height, etc?
We have the exact same problem as for links but it's even worse since we don't have the ability to define the parameters inside the image syntax since the image syntax is too limited.
Solutions =======
a) Use a different syntax such as:
!!label>>image>>>param=value...!!
(note that there are several wikis using the !! notation for images, including confluence)
Ex: !!my.png!! !!my image>>my.png!! !!wiki:Space.Page^my.png>>>width=100 height=200!!
b) Decide not to have a syntax for images and instead use an image macro.
Ex: {{image name="my.png" document="wiki:Space.Page" width="100" height="200"/}}
Note that there's one problem with not having a syntax for images in the grammar: it makes it harder to convert from one syntax for another. For example people using wikimodel wouldn't be able to convert from xwiki to another syntax easily and viceversa. In XWiki itself we would need to have some extra handling code to handle the fact that the image is a macro to convert it to another syntax but that's possible (not the easiest but possible).
WDYT for 1) and 2)?
My choice:
1) a)
For 2) I'd prefer to have a syntax for images (for the conversion between syntaxes issue and for the fact that the syntax wouldn't be complete - We've added tables in the syntax so it would be a pity not to have a syntax for images IMO). There's only possibility though: that we add {{image...}} in the syntax, so it would generate an onImage() event in XWiki and we would just convert it internally to an image macro. Ideally I'd still prefer a clean syntax but that'd be my second choice.
Since there is no way currently to set an attribute for an inline element (for the <a> element itself and not a wrapping span), I'd go for adding the parameters syntax, provided that we can do it for *all* inline elements and maybe also make it available, as an alternative, to block elements, where this method could be applied. so +1 for 1)a) only if we can do it for all inline elements. Which brings us to images: I find a wiki syntax quite suitable, for consistency reasons (with links, for example). ! is a pretty used character, even duplicated, so I'd go for another one: pipe (hard to find on some kbds, though), @ (semantically associated with emails, though), # (already taken), & ? so +1 for wiki syntax for 2) Happy coding, Anca
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Oct 27, 2008, at 12:44 PM, Anca Paula Luca wrote:
Vincent Massol wrote:
Hi,
There are 2 features I need to finish implementing for the new rendering and I have some doubts.
1) Parameters for links
Problem =======
We decided to use the (% param=value %)[[link]] notation. However this is raising some issues.
First the user needs to close the parameter list so that it doesn't affect other elements coming after.
For example:
(% rel="_blank" %)[[link]](%%) hello
is different from:
(% rel="_blank" %)[[link]] hello
In the second case the rel="_blank" applied to both the link, the space and the word "hello".
However if we consider the params to only apply the link then we cannot set params anymore that span more than the link.
For example: (% style="color:red" %)[[link]] and some text(%%)
Note that technically the params currently generate a <span> element with the params as attributes. Thus right now using rel="_blank" is set on the span and not on the <a> element which means it doesn't work.
Solutions =======
a) Add again the notion of parameters inside the link syntax: [[label>>reference>>>param=value...]] (or using some other separator) b) Use a different syntax for link parameters, for ex: {% param=value %}[[link]] (but I really don't like it) c) Force the params in the (% %)[[link]] notation to always apply only to the link and thus force users to use a space if they want to start a styled portion of text beginning with a link: (% param=value %) [[link]] something else %)
As much as I hate having to recode what I've removed, I think the best solution is a).
2) Syntax for images
Problem =======
We had decided to use the following syntax: image:wiki:Space.Page^my.png (note: not sure we agreed about the use of ^ but that's a detail - I couldn't find the email where we discussed that)
The question is how do we set parameters for images. For example: alt, title, width, height, etc?
We have the exact same problem as for links but it's even worse since we don't have the ability to define the parameters inside the image syntax since the image syntax is too limited.
Solutions =======
a) Use a different syntax such as:
!!label>>image>>>param=value...!!
(note that there are several wikis using the !! notation for images, including confluence)
Ex: !!my.png!! !!my image>>my.png!! !!wiki:Space.Page^my.png>>>width=100 height=200!!
b) Decide not to have a syntax for images and instead use an image macro.
Ex: {{image name="my.png" document="wiki:Space.Page" width="100" height="200"/}}
Note that there's one problem with not having a syntax for images in the grammar: it makes it harder to convert from one syntax for another. For example people using wikimodel wouldn't be able to convert from xwiki to another syntax easily and viceversa. In XWiki itself we would need to have some extra handling code to handle the fact that the image is a macro to convert it to another syntax but that's possible (not the easiest but possible).
WDYT for 1) and 2)?
My choice:
1) a)
For 2) I'd prefer to have a syntax for images (for the conversion between syntaxes issue and for the fact that the syntax wouldn't be complete - We've added tables in the syntax so it would be a pity not to have a syntax for images IMO). There's only possibility though: that we add {{image...}} in the syntax, so it would generate an onImage() event in XWiki and we would just convert it internally to an image macro. Ideally I'd still prefer a clean syntax but that'd be my second choice.
Since there is no way currently to set an attribute for an inline element (for the <a> element itself and not a wrapping span), I'd go for adding the parameters syntax, provided that we can do it for *all* inline elements and maybe also make it available, as an alternative, to block elements, where this method could be applied.
I'm not sure I understand what you mean. Basically there are now 2 possibilities: i) using a special syntax for parameters for links and images. For links that could be [[label>>reference>>>parameters]]. Note that we might also need such a special syntax for inline verbatim blocks. ii) using 2 generic syntaxes for parameters: (% ... %) for applying parameters only to the next element {% ... %} ... {%%} for applying parameters to the elements inside Which one do you prefer? I think we have an issue for i) anyway (for verbatim inline elements for example). My preference goes to i). Thanks -Vincent
so +1 for 1)a) only if we can do it for all inline elements.
Which brings us to images: I find a wiki syntax quite suitable, for consistency reasons (with links, for example). ! is a pretty used character, even duplicated, so I'd go for another one: pipe (hard to find on some kbds, though), @ (semantically associated with emails, though), # (already taken), & ?
so +1 for wiki syntax for 2)
Happy coding, Anca
Thanks -Vincent
Vincent Massol wrote:
On Oct 27, 2008, at 12:44 PM, Anca Paula Luca wrote:
Vincent Massol wrote:
Hi,
There are 2 features I need to finish implementing for the new rendering and I have some doubts.
1) Parameters for links
Problem =======
We decided to use the (% param=value %)[[link]] notation. However this is raising some issues.
First the user needs to close the parameter list so that it doesn't affect other elements coming after.
For example:
(% rel="_blank" %)[[link]](%%) hello
is different from:
(% rel="_blank" %)[[link]] hello
In the second case the rel="_blank" applied to both the link, the space and the word "hello".
However if we consider the params to only apply the link then we cannot set params anymore that span more than the link.
For example: (% style="color:red" %)[[link]] and some text(%%)
Note that technically the params currently generate a <span> element with the params as attributes. Thus right now using rel="_blank" is set on the span and not on the <a> element which means it doesn't work.
Solutions =======
a) Add again the notion of parameters inside the link syntax: [[label>>reference>>>param=value...]] (or using some other separator) b) Use a different syntax for link parameters, for ex: {% param=value %}[[link]] (but I really don't like it) c) Force the params in the (% %)[[link]] notation to always apply only to the link and thus force users to use a space if they want to start a styled portion of text beginning with a link: (% param=value %) [[link]] something else %)
As much as I hate having to recode what I've removed, I think the best solution is a).
2) Syntax for images
Problem =======
We had decided to use the following syntax: image:wiki:Space.Page^my.png (note: not sure we agreed about the use of ^ but that's a detail - I couldn't find the email where we discussed that)
The question is how do we set parameters for images. For example: alt, title, width, height, etc?
We have the exact same problem as for links but it's even worse since we don't have the ability to define the parameters inside the image syntax since the image syntax is too limited.
Solutions =======
a) Use a different syntax such as:
!!label>>image>>>param=value...!!
(note that there are several wikis using the !! notation for images, including confluence)
Ex: !!my.png!! !!my image>>my.png!! !!wiki:Space.Page^my.png>>>width=100 height=200!!
b) Decide not to have a syntax for images and instead use an image macro.
Ex: {{image name="my.png" document="wiki:Space.Page" width="100" height="200"/}}
Note that there's one problem with not having a syntax for images in the grammar: it makes it harder to convert from one syntax for another. For example people using wikimodel wouldn't be able to convert from xwiki to another syntax easily and viceversa. In XWiki itself we would need to have some extra handling code to handle the fact that the image is a macro to convert it to another syntax but that's possible (not the easiest but possible).
WDYT for 1) and 2)?
My choice:
1) a)
For 2) I'd prefer to have a syntax for images (for the conversion between syntaxes issue and for the fact that the syntax wouldn't be complete - We've added tables in the syntax so it would be a pity not to have a syntax for images IMO). There's only possibility though: that we add {{image...}} in the syntax, so it would generate an onImage() event in XWiki and we would just convert it internally to an image macro. Ideally I'd still prefer a clean syntax but that'd be my second choice. Since there is no way currently to set an attribute for an inline element (for the <a> element itself and not a wrapping span), I'd go for adding the parameters syntax, provided that we can do it for *all* inline elements and maybe also make it available, as an alternative, to block elements, where this method could be applied.
I'm not sure I understand what you mean. Basically there are now 2 possibilities:
i) using a special syntax for parameters for links and images. For links that could be [[label>>reference>>>parameters]]. Note that we might also need such a special syntax for inline verbatim blocks. ii) using 2 generic syntaxes for parameters:
(% ... %) for applying parameters only to the next element {% ... %} ... {%%} for applying parameters to the elements inside
Which one do you prefer?
I think we have an issue for i) anyway (for verbatim inline elements for example).
My preference goes to i).
Exactly my point, i) only if we can and will do it the same for all the inline elements, for syntax coherence reasons. I was saying that, envisaging users habits, we could provide this manner of setting parameters also for the block elements, where possible. But that's not a priority at all, just an idea. Happy coding, Anca
Thanks -Vincent
so +1 for 1)a) only if we can do it for all inline elements.
Which brings us to images: I find a wiki syntax quite suitable, for consistency reasons (with links, for example). ! is a pretty used character, even duplicated, so I'd go for another one: pipe (hard to find on some kbds, though), @ (semantically associated with emails, though), # (already taken), & ?
so +1 for wiki syntax for 2)
Happy coding, Anca
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Oct 27, 2008, at 2:16 PM, Anca Paula Luca wrote:
Vincent Massol wrote:
On Oct 27, 2008, at 12:44 PM, Anca Paula Luca wrote:
Vincent Massol wrote:
Hi,
There are 2 features I need to finish implementing for the new rendering and I have some doubts.
1) Parameters for links
Problem =======
We decided to use the (% param=value %)[[link]] notation. However this is raising some issues.
First the user needs to close the parameter list so that it doesn't affect other elements coming after.
For example:
(% rel="_blank" %)[[link]](%%) hello
is different from:
(% rel="_blank" %)[[link]] hello
In the second case the rel="_blank" applied to both the link, the space and the word "hello".
However if we consider the params to only apply the link then we cannot set params anymore that span more than the link.
For example: (% style="color:red" %)[[link]] and some text(%%)
Note that technically the params currently generate a <span> element with the params as attributes. Thus right now using rel="_blank" is set on the span and not on the <a> element which means it doesn't work.
Solutions =======
a) Add again the notion of parameters inside the link syntax: [[label>>reference>>>param=value...]] (or using some other separator) b) Use a different syntax for link parameters, for ex: {% param=value %}[[link]] (but I really don't like it) c) Force the params in the (% %)[[link]] notation to always apply only to the link and thus force users to use a space if they want to start a styled portion of text beginning with a link: (% param=value %) [[link]] something else %)
As much as I hate having to recode what I've removed, I think the best solution is a).
2) Syntax for images
Problem =======
We had decided to use the following syntax: image:wiki:Space.Page^my.png (note: not sure we agreed about the use of ^ but that's a detail - I couldn't find the email where we discussed that)
The question is how do we set parameters for images. For example: alt, title, width, height, etc?
We have the exact same problem as for links but it's even worse since we don't have the ability to define the parameters inside the image syntax since the image syntax is too limited.
Solutions =======
a) Use a different syntax such as:
!!label>>image>>>param=value...!!
(note that there are several wikis using the !! notation for images, including confluence)
Ex: !!my.png!! !!my image>>my.png!! !!wiki:Space.Page^my.png>>>width=100 height=200!!
b) Decide not to have a syntax for images and instead use an image macro.
Ex: {{image name="my.png" document="wiki:Space.Page" width="100" height="200"/}}
Note that there's one problem with not having a syntax for images in the grammar: it makes it harder to convert from one syntax for another. For example people using wikimodel wouldn't be able to convert from xwiki to another syntax easily and viceversa. In XWiki itself we would need to have some extra handling code to handle the fact that the image is a macro to convert it to another syntax but that's possible (not the easiest but possible).
WDYT for 1) and 2)?
My choice:
1) a)
For 2) I'd prefer to have a syntax for images (for the conversion between syntaxes issue and for the fact that the syntax wouldn't be complete - We've added tables in the syntax so it would be a pity not to have a syntax for images IMO). There's only possibility though: that we add {{image...}} in the syntax, so it would generate an onImage() event in XWiki and we would just convert it internally to an image macro. Ideally I'd still prefer a clean syntax but that'd be my second choice. Since there is no way currently to set an attribute for an inline element (for the <a> element itself and not a wrapping span), I'd go for adding the parameters syntax, provided that we can do it for *all* inline elements and maybe also make it available, as an alternative, to block elements, where this method could be applied.
I'm not sure I understand what you mean. Basically there are now 2 possibilities:
i) using a special syntax for parameters for links and images. For links that could be [[label>>reference>>>parameters]]. Note that we might also need such a special syntax for inline verbatim blocks. ii) using 2 generic syntaxes for parameters:
(% ... %) for applying parameters only to the next element {% ... %} ... {%%} for applying parameters to the elements inside
Which one do you prefer?
I think we have an issue for i) anyway (for verbatim inline elements for example).
My preference goes to i).
Exactly my point, i) only if we can and will do it the same for all the inline elements, for syntax coherence reasons.
I've reviewed elements and I think the only 2 that are causing problems are link and image. I don't see any other that would require setting attributes (verbatim translates into <tt> and there's no special attr for <tt>).
I was saying that, envisaging users habits, we could provide this manner of setting parameters also for the block elements, where possible. But that's not a priority at all, just an idea.
If you mean using {%...%} for spanning several block elements, then the answer is no, this is not possible using wikimodel. The wikimodel solution would be to use an embedded document as in: (% param=value %) ((( paragraph1 *list paragraph2 ))) Thanks -Vincent
so +1 for 1)a) only if we can do it for all inline elements.
Which brings us to images: I find a wiki syntax quite suitable, for consistency reasons (with links, for example). ! is a pretty used character, even duplicated, so I'd go for another one: pipe (hard to find on some kbds, though), @ (semantically associated with emails, though), # (already taken), & ?
so +1 for wiki syntax for 2)
Happy coding, Anca
Thanks -Vincent
On Oct 27, 2008, at 2:01 PM, Vincent Massol wrote:
On Oct 27, 2008, at 12:44 PM, Anca Paula Luca wrote:
Vincent Massol wrote:
Hi,
There are 2 features I need to finish implementing for the new rendering and I have some doubts.
1) Parameters for links
Problem =======
We decided to use the (% param=value %)[[link]] notation. However this is raising some issues.
First the user needs to close the parameter list so that it doesn't affect other elements coming after.
For example:
(% rel="_blank" %)[[link]](%%) hello
is different from:
(% rel="_blank" %)[[link]] hello
In the second case the rel="_blank" applied to both the link, the space and the word "hello".
However if we consider the params to only apply the link then we cannot set params anymore that span more than the link.
For example: (% style="color:red" %)[[link]] and some text(%%)
Note that technically the params currently generate a <span> element with the params as attributes. Thus right now using rel="_blank" is set on the span and not on the <a> element which means it doesn't work.
Solutions =======
a) Add again the notion of parameters inside the link syntax: [[label>>reference>>>param=value...]] (or using some other separator) b) Use a different syntax for link parameters, for ex: {% param=value %}[[link]] (but I really don't like it) c) Force the params in the (% %)[[link]] notation to always apply only to the link and thus force users to use a space if they want to start a styled portion of text beginning with a link: (% param=value %) [[link]] something else %)
As much as I hate having to recode what I've removed, I think the best solution is a).
2) Syntax for images
Problem =======
We had decided to use the following syntax: image:wiki:Space.Page^my.png (note: not sure we agreed about the use of ^ but that's a detail - I couldn't find the email where we discussed that)
The question is how do we set parameters for images. For example: alt, title, width, height, etc?
We have the exact same problem as for links but it's even worse since we don't have the ability to define the parameters inside the image syntax since the image syntax is too limited.
Solutions =======
a) Use a different syntax such as:
!!label>>image>>>param=value...!!
(note that there are several wikis using the !! notation for images, including confluence)
Ex: !!my.png!! !!my image>>my.png!! !!wiki:Space.Page^my.png>>>width=100 height=200!!
b) Decide not to have a syntax for images and instead use an image macro.
Ex: {{image name="my.png" document="wiki:Space.Page" width="100" height="200"/}}
Note that there's one problem with not having a syntax for images in the grammar: it makes it harder to convert from one syntax for another. For example people using wikimodel wouldn't be able to convert from xwiki to another syntax easily and viceversa. In XWiki itself we would need to have some extra handling code to handle the fact that the image is a macro to convert it to another syntax but that's possible (not the easiest but possible).
WDYT for 1) and 2)?
My choice:
1) a)
For 2) I'd prefer to have a syntax for images (for the conversion between syntaxes issue and for the fact that the syntax wouldn't be complete - We've added tables in the syntax so it would be a pity not to have a syntax for images IMO). There's only possibility though: that we add {{image...}} in the syntax, so it would generate an onImage() event in XWiki and we would just convert it internally to an image macro. Ideally I'd still prefer a clean syntax but that'd be my second choice.
Since there is no way currently to set an attribute for an inline element (for the <a> element itself and not a wrapping span), I'd go for adding the parameters syntax, provided that we can do it for *all* inline elements and maybe also make it available, as an alternative, to block elements, where this method could be applied.
I'm not sure I understand what you mean. Basically there are now 2 possibilities:
i) using a special syntax for parameters for links and images. For links that could be [[label>>reference>>>parameters]]. Note that we might also need such a special syntax for inline verbatim blocks. ii) using 2 generic syntaxes for parameters:
(% ... %) for applying parameters only to the next element {% ... %} ... {%%} for applying parameters to the elements inside
Which one do you prefer?
I think we have an issue for i) anyway (for verbatim inline elements for example).
My preference goes to i).
Sorry I mistyped. My preference goes to ii), not i) (although it's a close call but I prefer the homogeneity - my hesitation is that it's slightly more complex for users). Note that I haven't though yet on how to implement it so I might find some surprises there too ;) Thanks -Vincent
so +1 for 1)a) only if we can do it for all inline elements.
Which brings us to images: I find a wiki syntax quite suitable, for consistency reasons (with links, for example). ! is a pretty used character, even duplicated, so I'd go for another one: pipe (hard to find on some kbds, though), @ (semantically associated with emails, though), # (already taken), & ?
so +1 for wiki syntax for 2)
Happy coding, Anca
Thanks -Vincent
Vincent Massol wrote:
On Oct 27, 2008, at 2:01 PM, Vincent Massol wrote:
On Oct 27, 2008, at 12:44 PM, Anca Paula Luca wrote:
Vincent Massol wrote:
Hi,
There are 2 features I need to finish implementing for the new rendering and I have some doubts.
1) Parameters for links
Problem =======
We decided to use the (% param=value %)[[link]] notation. However this is raising some issues.
First the user needs to close the parameter list so that it doesn't affect other elements coming after.
For example:
(% rel="_blank" %)[[link]](%%) hello
is different from:
(% rel="_blank" %)[[link]] hello
In the second case the rel="_blank" applied to both the link, the space and the word "hello".
However if we consider the params to only apply the link then we cannot set params anymore that span more than the link.
For example: (% style="color:red" %)[[link]] and some text(%%)
Note that technically the params currently generate a <span> element with the params as attributes. Thus right now using rel="_blank" is set on the span and not on the <a> element which means it doesn't work.
Solutions =======
a) Add again the notion of parameters inside the link syntax: [[label>>reference>>>param=value...]] (or using some other separator) b) Use a different syntax for link parameters, for ex: {% param=value %}[[link]] (but I really don't like it) c) Force the params in the (% %)[[link]] notation to always apply only to the link and thus force users to use a space if they want to start a styled portion of text beginning with a link: (% param=value %) [[link]] something else %)
As much as I hate having to recode what I've removed, I think the best solution is a).
2) Syntax for images
Problem =======
We had decided to use the following syntax: image:wiki:Space.Page^my.png (note: not sure we agreed about the use of ^ but that's a detail - I couldn't find the email where we discussed that)
The question is how do we set parameters for images. For example: alt, title, width, height, etc?
We have the exact same problem as for links but it's even worse since we don't have the ability to define the parameters inside the image syntax since the image syntax is too limited.
Solutions =======
a) Use a different syntax such as:
!!label>>image>>>param=value...!!
(note that there are several wikis using the !! notation for images, including confluence)
Ex: !!my.png!! !!my image>>my.png!! !!wiki:Space.Page^my.png>>>width=100 height=200!!
b) Decide not to have a syntax for images and instead use an image macro.
Ex: {{image name="my.png" document="wiki:Space.Page" width="100" height="200"/}}
Note that there's one problem with not having a syntax for images in the grammar: it makes it harder to convert from one syntax for another. For example people using wikimodel wouldn't be able to convert from xwiki to another syntax easily and viceversa. In XWiki itself we would need to have some extra handling code to handle the fact that the image is a macro to convert it to another syntax but that's possible (not the easiest but possible).
WDYT for 1) and 2)?
My choice:
1) a)
For 2) I'd prefer to have a syntax for images (for the conversion between syntaxes issue and for the fact that the syntax wouldn't be complete - We've added tables in the syntax so it would be a pity not to have a syntax for images IMO). There's only possibility though: that we add {{image...}} in the syntax, so it would generate an onImage() event in XWiki and we would just convert it internally to an image macro. Ideally I'd still prefer a clean syntax but that'd be my second choice. Since there is no way currently to set an attribute for an inline element (for the <a> element itself and not a wrapping span), I'd go for adding the parameters syntax, provided that we can do it for *all* inline elements and maybe also make it available, as an alternative, to block elements, where this method could be applied. I'm not sure I understand what you mean. Basically there are now 2 possibilities:
i) using a special syntax for parameters for links and images. For links that could be [[label>>reference>>>parameters]]. Note that we might also need such a special syntax for inline verbatim blocks. ii) using 2 generic syntaxes for parameters:
(% ... %) for applying parameters only to the next element {% ... %} ... {%%} for applying parameters to the elements inside
Which one do you prefer?
I think we have an issue for i) anyway (for verbatim inline elements for example).
My preference goes to i).
Sorry I mistyped. My preference goes to ii), not i) (although it's a close call but I prefer the homogeneity - my hesitation is that it's slightly more complex for users). Note that I haven't though yet on how to implement it so I might find some surprises there too ;)
I prefer ii) as well. Jerome.
Thanks -Vincent
so +1 for 1)a) only if we can do it for all inline elements.
Which brings us to images: I find a wiki syntax quite suitable, for consistency reasons (with links, for example). ! is a pretty used character, even duplicated, so I'd go for another one: pipe (hard to find on some kbds, though), @ (semantically associated with emails, though), # (already taken), & ?
so +1 for wiki syntax for 2)
Happy coding, Anca
Thanks -Vincent
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
I'd be in favor of ii) as well for the sake of consistency & coherence. Guillaume On Mon, Oct 27, 2008 at 3:22 PM, Vincent Massol <[email protected]> wrote:
On Oct 27, 2008, at 2:01 PM, Vincent Massol wrote:
On Oct 27, 2008, at 12:44 PM, Anca Paula Luca wrote:
Vincent Massol wrote:
Hi,
There are 2 features I need to finish implementing for the new rendering and I have some doubts.
1) Parameters for links
Problem =======
We decided to use the (% param=value %)[[link]] notation. However this is raising some issues.
First the user needs to close the parameter list so that it doesn't affect other elements coming after.
For example:
(% rel="_blank" %)[[link]](%%) hello
is different from:
(% rel="_blank" %)[[link]] hello
In the second case the rel="_blank" applied to both the link, the space and the word "hello".
However if we consider the params to only apply the link then we cannot set params anymore that span more than the link.
For example: (% style="color:red" %)[[link]] and some text(%%)
Note that technically the params currently generate a <span> element with the params as attributes. Thus right now using rel="_blank" is set on the span and not on the <a> element which means it doesn't work.
Solutions =======
a) Add again the notion of parameters inside the link syntax: [[label>>reference>>>param=value...]] (or using some other separator) b) Use a different syntax for link parameters, for ex: {% param=value %}[[link]] (but I really don't like it) c) Force the params in the (% %)[[link]] notation to always apply only to the link and thus force users to use a space if they want to start a styled portion of text beginning with a link: (% param=value %) [[link]] something else %)
As much as I hate having to recode what I've removed, I think the best solution is a).
2) Syntax for images
Problem =======
We had decided to use the following syntax: image:wiki:Space.Page^my.png (note: not sure we agreed about the use of ^ but that's a detail - I couldn't find the email where we discussed that)
The question is how do we set parameters for images. For example: alt, title, width, height, etc?
We have the exact same problem as for links but it's even worse since we don't have the ability to define the parameters inside the image syntax since the image syntax is too limited.
Solutions =======
a) Use a different syntax such as:
!!label>>image>>>param=value...!!
(note that there are several wikis using the !! notation for images, including confluence)
Ex: !!my.png!! !!my image>>my.png!! !!wiki:Space.Page^my.png>>>width=100 height=200!!
b) Decide not to have a syntax for images and instead use an image macro.
Ex: {{image name="my.png" document="wiki:Space.Page" width="100" height="200"/}}
Note that there's one problem with not having a syntax for images in the grammar: it makes it harder to convert from one syntax for another. For example people using wikimodel wouldn't be able to convert from xwiki to another syntax easily and viceversa. In XWiki itself we would need to have some extra handling code to handle the fact that the image is a macro to convert it to another syntax but that's possible (not the easiest but possible).
WDYT for 1) and 2)?
My choice:
1) a)
For 2) I'd prefer to have a syntax for images (for the conversion between syntaxes issue and for the fact that the syntax wouldn't be complete - We've added tables in the syntax so it would be a pity not to have a syntax for images IMO). There's only possibility though: that we add {{image...}} in the syntax, so it would generate an onImage() event in XWiki and we would just convert it internally to an image macro. Ideally I'd still prefer a clean syntax but that'd be my second choice.
Since there is no way currently to set an attribute for an inline element (for the <a> element itself and not a wrapping span), I'd go for adding the parameters syntax, provided that we can do it for *all* inline elements and maybe also make it available, as an alternative, to block elements, where this method could be applied.
I'm not sure I understand what you mean. Basically there are now 2 possibilities:
i) using a special syntax for parameters for links and images. For links that could be [[label>>reference>>>parameters]]. Note that we might also need such a special syntax for inline verbatim blocks. ii) using 2 generic syntaxes for parameters:
(% ... %) for applying parameters only to the next element {% ... %} ... {%%} for applying parameters to the elements inside
Which one do you prefer?
I think we have an issue for i) anyway (for verbatim inline elements for example).
My preference goes to i).
Sorry I mistyped. My preference goes to ii), not i) (although it's a close call but I prefer the homogeneity - my hesitation is that it's slightly more complex for users). Note that I haven't though yet on how to implement it so I might find some surprises there too ;)
Thanks -Vincent
so +1 for 1)a) only if we can do it for all inline elements.
Which brings us to images: I find a wiki syntax quite suitable, for consistency reasons (with links, for example). ! is a pretty used character, even duplicated, so I'd go for another one: pipe (hard to find on some kbds, though), @ (semantically associated with emails, though), # (already taken), & ?
so +1 for wiki syntax for 2)
Happy coding, Anca
Thanks -Vincent
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Lerouge Product Manager - XWiki Skype ID : wikibc http://blog.xwiki.com/
+1 for ii) and for having the wiki syntax for image like it would be a macro. Vincent Massol wrote:
On Oct 27, 2008, at 2:01 PM, Vincent Massol wrote:
On Oct 27, 2008, at 12:44 PM, Anca Paula Luca wrote:
Vincent Massol wrote:
Hi,
There are 2 features I need to finish implementing for the new rendering and I have some doubts.
1) Parameters for links
Problem =======
We decided to use the (% param=value %)[[link]] notation. However this is raising some issues.
First the user needs to close the parameter list so that it doesn't affect other elements coming after.
For example:
(% rel="_blank" %)[[link]](%%) hello
is different from:
(% rel="_blank" %)[[link]] hello
In the second case the rel="_blank" applied to both the link, the space and the word "hello".
However if we consider the params to only apply the link then we cannot set params anymore that span more than the link.
For example: (% style="color:red" %)[[link]] and some text(%%)
Note that technically the params currently generate a <span> element with the params as attributes. Thus right now using rel="_blank" is set on the span and not on the <a> element which means it doesn't work.
Solutions =======
a) Add again the notion of parameters inside the link syntax: [[label>>reference>>>param=value...]] (or using some other separator) b) Use a different syntax for link parameters, for ex: {% param=value %}[[link]] (but I really don't like it) c) Force the params in the (% %)[[link]] notation to always apply only to the link and thus force users to use a space if they want to start a styled portion of text beginning with a link: (% param=value %) [[link]] something else %)
As much as I hate having to recode what I've removed, I think the best solution is a).
2) Syntax for images
Problem =======
We had decided to use the following syntax: image:wiki:Space.Page^my.png (note: not sure we agreed about the use of ^ but that's a detail - I couldn't find the email where we discussed that)
The question is how do we set parameters for images. For example: alt, title, width, height, etc?
We have the exact same problem as for links but it's even worse since we don't have the ability to define the parameters inside the image syntax since the image syntax is too limited.
Solutions =======
a) Use a different syntax such as:
!!label>>image>>>param=value...!!
(note that there are several wikis using the !! notation for images, including confluence)
Ex: !!my.png!! !!my image>>my.png!! !!wiki:Space.Page^my.png>>>width=100 height=200!!
b) Decide not to have a syntax for images and instead use an image macro.
Ex: {{image name="my.png" document="wiki:Space.Page" width="100" height="200"/}}
Note that there's one problem with not having a syntax for images in the grammar: it makes it harder to convert from one syntax for another. For example people using wikimodel wouldn't be able to convert from xwiki to another syntax easily and viceversa. In XWiki itself we would need to have some extra handling code to handle the fact that the image is a macro to convert it to another syntax but that's possible (not the easiest but possible).
WDYT for 1) and 2)?
My choice:
1) a)
For 2) I'd prefer to have a syntax for images (for the conversion between syntaxes issue and for the fact that the syntax wouldn't be complete - We've added tables in the syntax so it would be a pity not to have a syntax for images IMO). There's only possibility though: that we add {{image...}} in the syntax, so it would generate an onImage() event in XWiki and we would just convert it internally to an image macro. Ideally I'd still prefer a clean syntax but that'd be my second choice. Since there is no way currently to set an attribute for an inline element (for the <a> element itself and not a wrapping span), I'd go for adding the parameters syntax, provided that we can do it for *all* inline elements and maybe also make it available, as an alternative, to block elements, where this method could be applied. I'm not sure I understand what you mean. Basically there are now 2 possibilities:
i) using a special syntax for parameters for links and images. For links that could be [[label>>reference>>>parameters]]. Note that we might also need such a special syntax for inline verbatim blocks. ii) using 2 generic syntaxes for parameters:
(% ... %) for applying parameters only to the next element {% ... %} ... {%%} for applying parameters to the elements inside
Which one do you prefer?
I think we have an issue for i) anyway (for verbatim inline elements for example).
My preference goes to i).
Sorry I mistyped. My preference goes to ii), not i) (although it's a close call but I prefer the homogeneity - my hesitation is that it's slightly more complex for users). Note that I haven't though yet on how to implement it so I might find some surprises there too ;)
Thanks -Vincent
so +1 for 1)a) only if we can do it for all inline elements.
Which brings us to images: I find a wiki syntax quite suitable, for consistency reasons (with links, for example). ! is a pretty used character, even duplicated, so I'd go for another one: pipe (hard to find on some kbds, though), @ (semantically associated with emails, though), # (already taken), & ?
so +1 for wiki syntax for 2)
Happy coding, Anca
Thanks -Vincent
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
+1 for ii) Vincent Massol wrote:
On Oct 27, 2008, at 12:44 PM, Anca Paula Luca wrote:
Vincent Massol wrote:
Hi,
There are 2 features I need to finish implementing for the new rendering and I have some doubts.
1) Parameters for links
Problem =======
We decided to use the (% param=value %)[[link]] notation. However this is raising some issues.
First the user needs to close the parameter list so that it doesn't affect other elements coming after.
For example:
(% rel="_blank" %)[[link]](%%) hello
is different from:
(% rel="_blank" %)[[link]] hello
In the second case the rel="_blank" applied to both the link, the space and the word "hello".
However if we consider the params to only apply the link then we cannot set params anymore that span more than the link.
For example: (% style="color:red" %)[[link]] and some text(%%)
Note that technically the params currently generate a <span> element with the params as attributes. Thus right now using rel="_blank" is set on the span and not on the <a> element which means it doesn't work.
Solutions =======
a) Add again the notion of parameters inside the link syntax: [[label>>reference>>>param=value...]] (or using some other separator) b) Use a different syntax for link parameters, for ex: {% param=value %}[[link]] (but I really don't like it) c) Force the params in the (% %)[[link]] notation to always apply only to the link and thus force users to use a space if they want to start a styled portion of text beginning with a link: (% param=value %) [[link]] something else %)
As much as I hate having to recode what I've removed, I think the best solution is a).
2) Syntax for images
Problem =======
We had decided to use the following syntax: image:wiki:Space.Page^my.png (note: not sure we agreed about the use of ^ but that's a detail - I couldn't find the email where we discussed that)
The question is how do we set parameters for images. For example: alt, title, width, height, etc?
We have the exact same problem as for links but it's even worse since we don't have the ability to define the parameters inside the image syntax since the image syntax is too limited.
Solutions =======
a) Use a different syntax such as:
!!label>>image>>>param=value...!!
(note that there are several wikis using the !! notation for images, including confluence)
Ex: !!my.png!! !!my image>>my.png!! !!wiki:Space.Page^my.png>>>width=100 height=200!!
b) Decide not to have a syntax for images and instead use an image macro.
Ex: {{image name="my.png" document="wiki:Space.Page" width="100" height="200"/}}
Note that there's one problem with not having a syntax for images in the grammar: it makes it harder to convert from one syntax for another. For example people using wikimodel wouldn't be able to convert from xwiki to another syntax easily and viceversa. In XWiki itself we would need to have some extra handling code to handle the fact that the image is a macro to convert it to another syntax but that's possible (not the easiest but possible).
WDYT for 1) and 2)?
My choice:
1) a)
For 2) I'd prefer to have a syntax for images (for the conversion between syntaxes issue and for the fact that the syntax wouldn't be complete - We've added tables in the syntax so it would be a pity not to have a syntax for images IMO). There's only possibility though: that we add {{image...}} in the syntax, so it would generate an onImage() event in XWiki and we would just convert it internally to an image macro. Ideally I'd still prefer a clean syntax but that'd be my second choice. Since there is no way currently to set an attribute for an inline element (for the <a> element itself and not a wrapping span), I'd go for adding the parameters syntax, provided that we can do it for *all* inline elements and maybe also make it available, as an alternative, to block elements, where this method could be applied.
I'm not sure I understand what you mean. Basically there are now 2 possibilities:
i) using a special syntax for parameters for links and images. For links that could be [[label>>reference>>>parameters]]. Note that we might also need such a special syntax for inline verbatim blocks. ii) using 2 generic syntaxes for parameters:
(% ... %) for applying parameters only to the next element {% ... %} ... {%%} for applying parameters to the elements inside
Which one do you prefer?
I think we have an issue for i) anyway (for verbatim inline elements for example).
My preference goes to i).
Thanks -Vincent
so +1 for 1)a) only if we can do it for all inline elements.
Which brings us to images: I find a wiki syntax quite suitable, for consistency reasons (with links, for example). ! is a pretty used character, even duplicated, so I'd go for another one: pipe (hard to find on some kbds, though), @ (semantically associated with emails, though), # (already taken), & ?
so +1 for wiki syntax for 2)
Happy coding, Anca
Thanks -Vincent
-- Sergiu Dumitriu http://purl.org/net/sergiu/
On Oct 27, 2008, at 2:01 PM, Vincent Massol wrote: [snip]
Basically there are now 2 possibilities:
i) using a special syntax for parameters for links and images. For links that could be [[label>>reference>>>parameters]]. Note that we might also need such a special syntax for inline verbatim blocks. ii) using 2 generic syntaxes for parameters:
(% ... %) for applying parameters only to the next element {% ... %} ... {%%} for applying parameters to the elements inside
Which one do you prefer?
I think we have an issue for i) anyway (for verbatim inline elements for example).
My preference goes to ii) [EDITED: was i)].
After speaking to Mikhail (wikimodel creator) there's a third possibility: iii) using the same syntax for links, images and attachments. Namely: Links: [[label>>reference||params]] Images: [[label>>image:wiki:Space.Page^my.png||params]] Attachments (download link): [[label>>attach:wiki:Space.Page^my.png||params]] This means that it would also be possible to use links, images and attachments directly in the text using the form: This is a http://... URL This is an image:my.png image This is my word attach:my.doc document Notes: * The "label" for images would correspond to the alt/title attribute. Thus the wiki syntax inside would be transformed into text (for example: "Hello **world**" would generate "Hello world") * It would currently not be possible to disambiguate between a subwiki named "image", "attach" and displaying an image or linking to an attachment. This would be fixed later on when we change the FQN (Fully Qualified Name) for Documents in order to support nested spaces. * This means that we can keep using (% %) notation and there's no need to define a new {% ... %} notation. * It means we need to introduce the "||" separator for link parameters * It is completely inline with the wikimodel way of handling images. * There's no need to introduce a new onImage() event. However we might want to rename our begin/endLink() events to beginReference()/ endReference(). I personally like this solution except for the fact that since we've introduced wiki syntax in place of labels we would be tweaking the model a bit since there's no need for begin/end for images. That said we could also add an onImage() event and emit it at the parser level so that the label would always contain pure text (if we have "hello **world**" we would use "hello **world**"). I'm hesitating between ii) and iii). WDYT? Thanks -Vincent
so +1 for 1)a) only if we can do it for all inline elements.
Which brings us to images: I find a wiki syntax quite suitable, for consistency reasons (with links, for example). ! is a pretty used character, even duplicated, so I'd go for another one: pipe (hard to find on some kbds, though), @ (semantically associated with emails, though), # (already taken), & ?
so +1 for wiki syntax for 2)
Happy coding, Anca
+1 for iii) Thomas Vincent Massol a écrit :
On Oct 27, 2008, at 2:01 PM, Vincent Massol wrote:
[snip]
Basically there are now 2 possibilities:
i) using a special syntax for parameters for links and images. For links that could be [[label>>reference>>>parameters]]. Note that we might also need such a special syntax for inline verbatim blocks. ii) using 2 generic syntaxes for parameters:
(% ... %) for applying parameters only to the next element {% ... %} ... {%%} for applying parameters to the elements inside
Which one do you prefer?
I think we have an issue for i) anyway (for verbatim inline elements for example).
My preference goes to ii) [EDITED: was i)].
After speaking to Mikhail (wikimodel creator) there's a third possibility:
iii) using the same syntax for links, images and attachments. Namely:
Links: [[label>>reference||params]]
Images: [[label>>image:wiki:Space.Page^my.png||params]]
Attachments (download link): [[label>>attach:wiki:Space.Page^my.png||params]]
This means that it would also be possible to use links, images and attachments directly in the text using the form:
This is a http://... URL This is an image:my.png image This is my word attach:my.doc document
Notes: * The "label" for images would correspond to the alt/title attribute. Thus the wiki syntax inside would be transformed into text (for example: "Hello **world**" would generate "Hello world") * It would currently not be possible to disambiguate between a subwiki named "image", "attach" and displaying an image or linking to an attachment. This would be fixed later on when we change the FQN (Fully Qualified Name) for Documents in order to support nested spaces. * This means that we can keep using (% %) notation and there's no need to define a new {% ... %} notation. * It means we need to introduce the "||" separator for link parameters * It is completely inline with the wikimodel way of handling images. * There's no need to introduce a new onImage() event. However we might want to rename our begin/endLink() events to beginReference()/ endReference().
I personally like this solution except for the fact that since we've introduced wiki syntax in place of labels we would be tweaking the model a bit since there's no need for begin/end for images. That said we could also add an onImage() event and emit it at the parser level so that the label would always contain pure text (if we have "hello **world**" we would use "hello **world**").
I'm hesitating between ii) and iii).
WDYT?
Thanks -Vincent
so +1 for 1)a) only if we can do it for all inline elements.
Which brings us to images: I find a wiki syntax quite suitable, for consistency reasons (with links, for example). ! is a pretty used character, even duplicated, so I'd go for another one: pipe (hard to find on some kbds, though), @ (semantically associated with emails, though), # (already taken), & ?
so +1 for wiki syntax for 2)
Happy coding, Anca
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Vincent Massol wrote:
On Oct 27, 2008, at 2:01 PM, Vincent Massol wrote:
[snip]
Basically there are now 2 possibilities:
i) using a special syntax for parameters for links and images. For links that could be [[label>>reference>>>parameters]]. Note that we might also need such a special syntax for inline verbatim blocks. ii) using 2 generic syntaxes for parameters:
(% ... %) for applying parameters only to the next element {% ... %} ... {%%} for applying parameters to the elements inside
Which one do you prefer?
I think we have an issue for i) anyway (for verbatim inline elements for example).
My preference goes to ii) [EDITED: was i)].
After speaking to Mikhail (wikimodel creator) there's a third possibility:
iii) using the same syntax for links, images and attachments. Namely:
Links: [[label>>reference||params]]
Images: [[label>>image:wiki:Space.Page^my.png||params]]
Attachments (download link): [[label>>attach:wiki:Space.Page^my.png||params]]
This means that it would also be possible to use links, images and attachments directly in the text using the form:
This is a http://... URL This is an image:my.png image This is my word attach:my.doc document
this sounds good +1 Happy coding, Anca
Notes: * The "label" for images would correspond to the alt/title attribute. Thus the wiki syntax inside would be transformed into text (for example: "Hello **world**" would generate "Hello world") * It would currently not be possible to disambiguate between a subwiki named "image", "attach" and displaying an image or linking to an attachment. This would be fixed later on when we change the FQN (Fully Qualified Name) for Documents in order to support nested spaces. * This means that we can keep using (% %) notation and there's no need to define a new {% ... %} notation. * It means we need to introduce the "||" separator for link parameters * It is completely inline with the wikimodel way of handling images. * There's no need to introduce a new onImage() event. However we might want to rename our begin/endLink() events to beginReference()/ endReference().
I personally like this solution except for the fact that since we've introduced wiki syntax in place of labels we would be tweaking the model a bit since there's no need for begin/end for images. That said we could also add an onImage() event and emit it at the parser level so that the label would always contain pure text (if we have "hello **world**" we would use "hello **world**").
I'm hesitating between ii) and iii).
WDYT?
Thanks -Vincent
so +1 for 1)a) only if we can do it for all inline elements.
Which brings us to images: I find a wiki syntax quite suitable, for consistency reasons (with links, for example). ! is a pretty used character, even duplicated, so I'd go for another one: pipe (hard to find on some kbds, though), @ (semantically associated with emails, though), # (already taken), & ?
so +1 for wiki syntax for 2)
Happy coding, Anca
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
I'd go for iii), without parsing the label (use "hello **world**" if it is, not make it "hello world") Jerome. Vincent Massol wrote:
On Oct 27, 2008, at 2:01 PM, Vincent Massol wrote:
[snip]
Basically there are now 2 possibilities:
i) using a special syntax for parameters for links and images. For links that could be [[label>>reference>>>parameters]]. Note that we might also need such a special syntax for inline verbatim blocks. ii) using 2 generic syntaxes for parameters:
(% ... %) for applying parameters only to the next element {% ... %} ... {%%} for applying parameters to the elements inside
Which one do you prefer?
I think we have an issue for i) anyway (for verbatim inline elements for example).
My preference goes to ii) [EDITED: was i)].
After speaking to Mikhail (wikimodel creator) there's a third possibility:
iii) using the same syntax for links, images and attachments. Namely:
Links: [[label>>reference||params]]
Images: [[label>>image:wiki:Space.Page^my.png||params]]
Attachments (download link): [[label>>attach:wiki:Space.Page^my.png||params]]
This means that it would also be possible to use links, images and attachments directly in the text using the form:
This is a http://... URL This is an image:my.png image This is my word attach:my.doc document
Notes: * The "label" for images would correspond to the alt/title attribute. Thus the wiki syntax inside would be transformed into text (for example: "Hello **world**" would generate "Hello world") * It would currently not be possible to disambiguate between a subwiki named "image", "attach" and displaying an image or linking to an attachment. This would be fixed later on when we change the FQN (Fully Qualified Name) for Documents in order to support nested spaces. * This means that we can keep using (% %) notation and there's no need to define a new {% ... %} notation. * It means we need to introduce the "||" separator for link parameters * It is completely inline with the wikimodel way of handling images. * There's no need to introduce a new onImage() event. However we might want to rename our begin/endLink() events to beginReference()/ endReference().
I personally like this solution except for the fact that since we've introduced wiki syntax in place of labels we would be tweaking the model a bit since there's no need for begin/end for images. That said we could also add an onImage() event and emit it at the parser level so that the label would always contain pure text (if we have "hello **world**" we would use "hello **world**").
I'm hesitating between ii) and iii).
WDYT?
Thanks -Vincent
so +1 for 1)a) only if we can do it for all inline elements.
Which brings us to images: I find a wiki syntax quite suitable, for consistency reasons (with links, for example). ! is a pretty used character, even duplicated, so I'd go for another one: pipe (hard to find on some kbds, though), @ (semantically associated with emails, though), # (already taken), & ?
so +1 for wiki syntax for 2)
Happy coding, Anca
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
ok so far we have: * Jerome: iii) * Anca: iii) * ThomasE (non-binding): iii) * Vincent: iii) Sergiu, ThomasM, JV, Marius, Asiri (and other committers): are you ok with iii). Barring any more answers, I'll start implementing it in 1 hour (it seems the right solution to me anyway). Implementation note: I'll still introduce an onImage() event and an ImageBlock class. Also as Jerome mentioned I'll use the text specified as the label as is. Thanks -Vincent On Oct 28, 2008, at 6:53 AM, Jerome Velociter wrote:
I'd go for iii), without parsing the label (use "hello **world**" if it is, not make it "hello world")
Jerome.
Vincent Massol wrote:
On Oct 27, 2008, at 2:01 PM, Vincent Massol wrote:
[snip]
Basically there are now 2 possibilities:
i) using a special syntax for parameters for links and images. For links that could be [[label>>reference>>>parameters]]. Note that we might also need such a special syntax for inline verbatim blocks. ii) using 2 generic syntaxes for parameters:
(% ... %) for applying parameters only to the next element {% ... %} ... {%%} for applying parameters to the elements inside
Which one do you prefer?
I think we have an issue for i) anyway (for verbatim inline elements for example).
My preference goes to ii) [EDITED: was i)].
After speaking to Mikhail (wikimodel creator) there's a third possibility:
iii) using the same syntax for links, images and attachments. Namely:
Links: [[label>>reference||params]]
Images: [[label>>image:wiki:Space.Page^my.png||params]]
Attachments (download link): [[label>>attach:wiki:Space.Page^my.png||params]]
This means that it would also be possible to use links, images and attachments directly in the text using the form:
This is a http://... URL This is an image:my.png image This is my word attach:my.doc document
Notes: * The "label" for images would correspond to the alt/title attribute. Thus the wiki syntax inside would be transformed into text (for example: "Hello **world**" would generate "Hello world") * It would currently not be possible to disambiguate between a subwiki named "image", "attach" and displaying an image or linking to an attachment. This would be fixed later on when we change the FQN (Fully Qualified Name) for Documents in order to support nested spaces. * This means that we can keep using (% %) notation and there's no need to define a new {% ... %} notation. * It means we need to introduce the "||" separator for link parameters * It is completely inline with the wikimodel way of handling images. * There's no need to introduce a new onImage() event. However we might want to rename our begin/endLink() events to beginReference()/ endReference().
I personally like this solution except for the fact that since we've introduced wiki syntax in place of labels we would be tweaking the model a bit since there's no need for begin/end for images. That said we could also add an onImage() event and emit it at the parser level so that the label would always contain pure text (if we have "hello **world**" we would use "hello **world**").
I'm hesitating between ii) and iii).
WDYT?
Thanks -Vincent
so +1 for 1)a) only if we can do it for all inline elements.
Which brings us to images: I find a wiki syntax quite suitable, for consistency reasons (with links, for example). ! is a pretty used character, even duplicated, so I'd go for another one: pipe (hard to find on some kbds, though), @ (semantically associated with emails, though), # (already taken), & ?
so +1 for wiki syntax for 2)
Happy coding, Anca
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Vincent Massol wrote:
ok so far we have:
* Jerome: iii) * Anca: iii) * ThomasE (non-binding): iii) * Vincent: iii)
Sergiu, ThomasM, JV, Marius, Asiri (and other committers): are you ok with iii).
yes, go for iii)
Barring any more answers, I'll start implementing it in 1 hour (it seems the right solution to me anyway).
Implementation note: I'll still introduce an onImage() event and an ImageBlock class. Also as Jerome mentioned I'll use the text specified as the label as is.
Thanks -Vincent
On Oct 28, 2008, at 6:53 AM, Jerome Velociter wrote:
I'd go for iii), without parsing the label (use "hello **world**" if it is, not make it "hello world")
Jerome.
Vincent Massol wrote:
On Oct 27, 2008, at 2:01 PM, Vincent Massol wrote:
[snip]
Basically there are now 2 possibilities:
i) using a special syntax for parameters for links and images. For links that could be [[label>>reference>>>parameters]]. Note that we might also need such a special syntax for inline verbatim blocks. ii) using 2 generic syntaxes for parameters:
(% ... %) for applying parameters only to the next element {% ... %} ... {%%} for applying parameters to the elements inside
Which one do you prefer?
I think we have an issue for i) anyway (for verbatim inline elements for example).
My preference goes to ii) [EDITED: was i)]. After speaking to Mikhail (wikimodel creator) there's a third possibility:
iii) using the same syntax for links, images and attachments. Namely:
Links: [[label>>reference||params]]
Images: [[label>>image:wiki:Space.Page^my.png||params]]
Attachments (download link): [[label>>attach:wiki:Space.Page^my.png||params]]
This means that it would also be possible to use links, images and attachments directly in the text using the form:
This is a http://... URL This is an image:my.png image This is my word attach:my.doc document
Notes: * The "label" for images would correspond to the alt/title attribute. Thus the wiki syntax inside would be transformed into text (for example: "Hello **world**" would generate "Hello world") * It would currently not be possible to disambiguate between a subwiki named "image", "attach" and displaying an image or linking to an attachment. This would be fixed later on when we change the FQN (Fully Qualified Name) for Documents in order to support nested spaces. * This means that we can keep using (% %) notation and there's no need to define a new {% ... %} notation. * It means we need to introduce the "||" separator for link parameters * It is completely inline with the wikimodel way of handling images. * There's no need to introduce a new onImage() event. However we might want to rename our begin/endLink() events to beginReference()/ endReference().
I personally like this solution except for the fact that since we've introduced wiki syntax in place of labels we would be tweaking the model a bit since there's no need for begin/end for images. That said we could also add an onImage() event and emit it at the parser level so that the label would always contain pure text (if we have "hello **world**" we would use "hello **world**").
I'm hesitating between ii) and iii).
WDYT?
Thanks -Vincent
so +1 for 1)a) only if we can do it for all inline elements.
Which brings us to images: I find a wiki syntax quite suitable, for consistency reasons (with links, for example). ! is a pretty used character, even duplicated, so I'd go for another one: pipe (hard to find on some kbds, though), @ (semantically associated with emails, though), # (already taken), & ?
so +1 for wiki syntax for 2)
Happy coding, Anca
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Vincent Massol wrote:
ok so far we have:
* Jerome: iii) * Anca: iii) * ThomasE (non-binding): iii) * Vincent: iii)
Sergiu, ThomasM, JV, Marius, Asiri (and other committers): are you ok with iii). Barring any more answers, I'll start implementing it in 1 hour (it seems the right solution to me anyway).
+1 for both ii) and iii) iii) is good because it allows to have different URIs specify different actions. By the way, we could extend the URI prefix so that if there is no special handler for a prefix, we could use it as the action, for example: [[feed:Blog.BlogRSS]] would link to /xwiki/bin/feed/Blog/BlogRSS. At the moment this prevents FQN links to other wikis, so we should decide when to change the FQN syntax. ii) is good because it allows us to specify custom attributes on any element/section, which would be needed for microformats (which rely on class, rel, and title mostly), styling, and with the use of namespaces we can add our own attributes and bind custom behavior on them. Anyway, this is not a priority now, just something for the (not so far) future.
Implementation note: I'll still introduce an onImage() event and an ImageBlock class. Also as Jerome mentioned I'll use the text specified as the label as is.
Thanks -Vincent
On Oct 28, 2008, at 6:53 AM, Jerome Velociter wrote:
I'd go for iii), without parsing the label (use "hello **world**" if it is, not make it "hello world")
Jerome.
Vincent Massol wrote:
On Oct 27, 2008, at 2:01 PM, Vincent Massol wrote:
[snip]
Basically there are now 2 possibilities:
i) using a special syntax for parameters for links and images. For links that could be [[label>>reference>>>parameters]]. Note that we might also need such a special syntax for inline verbatim blocks. ii) using 2 generic syntaxes for parameters:
(% ... %) for applying parameters only to the next element {% ... %} ... {%%} for applying parameters to the elements inside
Which one do you prefer?
I think we have an issue for i) anyway (for verbatim inline elements for example).
My preference goes to ii) [EDITED: was i)]. After speaking to Mikhail (wikimodel creator) there's a third possibility:
iii) using the same syntax for links, images and attachments. Namely:
Links: [[label>>reference||params]]
Images: [[label>>image:wiki:Space.Page^my.png||params]]
Attachments (download link): [[label>>attach:wiki:Space.Page^my.png||params]]
This means that it would also be possible to use links, images and attachments directly in the text using the form:
This is a http://... URL This is an image:my.png image This is my word attach:my.doc document
Notes: * The "label" for images would correspond to the alt/title attribute. Thus the wiki syntax inside would be transformed into text (for example: "Hello **world**" would generate "Hello world") * It would currently not be possible to disambiguate between a subwiki named "image", "attach" and displaying an image or linking to an attachment. This would be fixed later on when we change the FQN (Fully Qualified Name) for Documents in order to support nested spaces. * This means that we can keep using (% %) notation and there's no need to define a new {% ... %} notation. * It means we need to introduce the "||" separator for link parameters * It is completely inline with the wikimodel way of handling images. * There's no need to introduce a new onImage() event. However we might want to rename our begin/endLink() events to beginReference()/ endReference().
I personally like this solution except for the fact that since we've introduced wiki syntax in place of labels we would be tweaking the model a bit since there's no need for begin/end for images. That said we could also add an onImage() event and emit it at the parser level so that the label would always contain pure text (if we have "hello **world**" we would use "hello **world**").
I'm hesitating between ii) and iii).
WDYT?
Thanks -Vincent
so +1 for 1)a) only if we can do it for all inline elements.
Which brings us to images: I find a wiki syntax quite suitable, for consistency reasons (with links, for example). ! is a pretty used character, even duplicated, so I'd go for another one: pipe (hard to find on some kbds, though), @ (semantically associated with emails, though), # (already taken), & ?
so +1 for wiki syntax for 2)
Happy coding, Anca
-- Sergiu Dumitriu http://purl.org/net/sergiu/
On Oct 28, 2008, at 11:00 AM, Sergiu Dumitriu wrote:
Vincent Massol wrote:
ok so far we have:
* Jerome: iii) * Anca: iii) * ThomasE (non-binding): iii) * Vincent: iii)
Sergiu, ThomasM, JV, Marius, Asiri (and other committers): are you ok with iii). Barring any more answers, I'll start implementing it in 1 hour (it seems the right solution to me anyway).
+1 for both ii) and iii)
iii) is good because it allows to have different URIs specify different actions. By the way, we could extend the URI prefix so that if there is no special handler for a prefix, we could use it as the action, for example: [[feed:Blog.BlogRSS]] would link to /xwiki/bin/feed/Blog/BlogRSS. At the moment this prevents FQN links to other wikis, so we should decide when to change the FQN syntax.
ii) is good because it allows us to specify custom attributes on any element/section, which would be needed for microformats (which rely on class, rel, and title mostly), styling, and with the use of namespaces we can add our own attributes and bind custom behavior on them. Anyway, this is not a priority now, just something for the (not so far) future.
I'd like to understand this better since I don't think ii) and iii) are perfectly compatible (this would mean two ways of settings parameters for links for ex which I don't like too much). So what's the exact need of microformats? How will it be represented? We can already do spans so that's a first solution and we can already put parameters on all our elements (lists, paragraphs, tables, links, etc). Then I'm also interested in implementing support for document level parameters too. We need a way to define the syntax for it so that it's different from parameters for a paragraph. For embedded documents it would be easy: (% param=value %) ((( ... ))) Last, I'm also interested in having the notion of properties as described in http://code.google.com/p/wikimodel/wiki/AdvancedStructuralElements . Maybe that could that help for defining microformats? WDYT? Thanks -Vincent
Implementation note: I'll still introduce an onImage() event and an ImageBlock class. Also as Jerome mentioned I'll use the text specified as the label as is.
Thanks -Vincent
On Oct 28, 2008, at 6:53 AM, Jerome Velociter wrote:
I'd go for iii), without parsing the label (use "hello **world**" if it is, not make it "hello world")
Jerome.
Vincent Massol wrote:
On Oct 27, 2008, at 2:01 PM, Vincent Massol wrote:
[snip]
Basically there are now 2 possibilities:
i) using a special syntax for parameters for links and images. For links that could be [[label>>reference>>>parameters]]. Note that we might also need such a special syntax for inline verbatim blocks. ii) using 2 generic syntaxes for parameters:
(% ... %) for applying parameters only to the next element {% ... %} ... {%%} for applying parameters to the elements inside
Which one do you prefer?
I think we have an issue for i) anyway (for verbatim inline elements for example).
My preference goes to ii) [EDITED: was i)]. After speaking to Mikhail (wikimodel creator) there's a third possibility:
iii) using the same syntax for links, images and attachments. Namely:
Links: [[label>>reference||params]]
Images: [[label>>image:wiki:Space.Page^my.png||params]]
Attachments (download link): [[label>>attach:wiki:Space.Page^my.png||params]]
This means that it would also be possible to use links, images and attachments directly in the text using the form:
This is a http://... URL This is an image:my.png image This is my word attach:my.doc document
Notes: * The "label" for images would correspond to the alt/title attribute. Thus the wiki syntax inside would be transformed into text (for example: "Hello **world**" would generate "Hello world") * It would currently not be possible to disambiguate between a subwiki named "image", "attach" and displaying an image or linking to an attachment. This would be fixed later on when we change the FQN (Fully Qualified Name) for Documents in order to support nested spaces. * This means that we can keep using (% %) notation and there's no need to define a new {% ... %} notation. * It means we need to introduce the "||" separator for link parameters * It is completely inline with the wikimodel way of handling images. * There's no need to introduce a new onImage() event. However we might want to rename our begin/endLink() events to beginReference()/ endReference().
I personally like this solution except for the fact that since we've introduced wiki syntax in place of labels we would be tweaking the model a bit since there's no need for begin/end for images. That said we could also add an onImage() event and emit it at the parser level so that the label would always contain pure text (if we have "hello **world**" we would use "hello **world**").
I'm hesitating between ii) and iii).
WDYT?
Thanks -Vincent
so +1 for 1)a) only if we can do it for all inline elements.
Which brings us to images: I find a wiki syntax quite suitable, for consistency reasons (with links, for example). ! is a pretty used character, even duplicated, so I'd go for another one: pipe (hard to find on some kbds, though), @ (semantically associated with emails, though), # (already taken), & ?
so +1 for wiki syntax for 2)
Happy coding, Anca
-- Sergiu Dumitriu http://purl.org/net/sergiu/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
ok for iii) On Tue, Oct 28, 2008 at 12:47 AM, Vincent Massol <[email protected]> wrote:
ok so far we have:
* Jerome: iii) * Anca: iii) * ThomasE (non-binding): iii) * Vincent: iii)
Sergiu, ThomasM, JV, Marius, Asiri (and other committers): are you ok with iii). Barring any more answers, I'll start implementing it in 1 hour (it seems the right solution to me anyway).
Implementation note: I'll still introduce an onImage() event and an ImageBlock class. Also as Jerome mentioned I'll use the text specified as the label as is.
Thanks -Vincent
On Oct 28, 2008, at 6:53 AM, Jerome Velociter wrote:
I'd go for iii), without parsing the label (use "hello **world**" if it is, not make it "hello world")
Jerome.
Vincent Massol wrote:
On Oct 27, 2008, at 2:01 PM, Vincent Massol wrote:
[snip]
Basically there are now 2 possibilities:
i) using a special syntax for parameters for links and images. For links that could be [[label>>reference>>>parameters]]. Note that we might also need such a special syntax for inline verbatim blocks. ii) using 2 generic syntaxes for parameters:
(% ... %) for applying parameters only to the next element {% ... %} ... {%%} for applying parameters to the elements inside
Which one do you prefer?
I think we have an issue for i) anyway (for verbatim inline elements for example).
My preference goes to ii) [EDITED: was i)].
After speaking to Mikhail (wikimodel creator) there's a third possibility:
iii) using the same syntax for links, images and attachments. Namely:
Links: [[label>>reference||params]]
Images: [[label>>image:wiki:Space.Page^my.png||params]]
Attachments (download link): [[label>>attach:wiki:Space.Page^my.png||params]]
This means that it would also be possible to use links, images and attachments directly in the text using the form:
This is a http://... URL This is an image:my.png image This is my word attach:my.doc document
Notes: * The "label" for images would correspond to the alt/title attribute. Thus the wiki syntax inside would be transformed into text (for example: "Hello **world**" would generate "Hello world") * It would currently not be possible to disambiguate between a subwiki named "image", "attach" and displaying an image or linking to an attachment. This would be fixed later on when we change the FQN (Fully Qualified Name) for Documents in order to support nested spaces. * This means that we can keep using (% %) notation and there's no need to define a new {% ... %} notation. * It means we need to introduce the "||" separator for link parameters * It is completely inline with the wikimodel way of handling images. * There's no need to introduce a new onImage() event. However we might want to rename our begin/endLink() events to beginReference()/ endReference().
I personally like this solution except for the fact that since we've introduced wiki syntax in place of labels we would be tweaking the model a bit since there's no need for begin/end for images. That said we could also add an onImage() event and emit it at the parser level so that the label would always contain pure text (if we have "hello **world**" we would use "hello **world**").
I'm hesitating between ii) and iii).
WDYT?
Thanks -Vincent
so +1 for 1)a) only if we can do it for all inline elements.
Which brings us to images: I find a wiki syntax quite suitable, for consistency reasons (with links, for example). ! is a pretty used character, even duplicated, so I'd go for another one: pipe (hard to find on some kbds, though), @ (semantically associated with emails, though), # (already taken), & ?
so +1 for wiki syntax for 2)
Happy coding, Anca
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
participants (8)
-
Anca Paula Luca -
Guillaume Lerouge -
Jerome Velociter -
Marius Dumitru Florea -
Sergiu Dumitriu -
Thomas Eveilleau -
Thomas Mortagne -
Vincent Massol