[xwiki-devs] [VOTE] HTML and Velocity macro NL/WS behaviors
Hi devs, We need to come to a conclusion for handling New Lines(NL) and white spaces (WS) in HTML and Velocity Macro. If you remember from http://markmail.org/thread/mhqhxnz5twhev5se the current problem is that we cannot indent scripts since WS and NL are meaningful. I'd like to reiterate the proposal that was sent but not enough people voted on it (only Thomas did). A) For the HTML macro, we propose to make the following changes: - strip NL/WS between elements (elements that don't accept CDATA) - strip leading/trailing NL/WS for element content before passing them to the wiki syntax parser B) for the Velocity macro we have 2 choices I can think of: 1) strip all leading spaces for all lines (but keep NL) Note that this means that inside a velocity macro you wouldn't be able to have a line break with the new line starting with spaces without escaping the leading space with ~(space). Note also that this means we will not be able to add extra new lines to format the text nicely (since that would add new paragraphs) or split a single line into several lines for extra readability. This is the case today with the old syntax and it's a pain not to be able to aerate the text with empty lines. Ex: some text ~ next line #if (...) this goes on the same line #something(...) #end This is a new paragraph In this example notice that we need the velocity #if to be on the same line since NL are significant. 2) strip all leading spaces for all lines + remove all NL too. This means we need to ensure we still have one space remaining between "words" (same as HTML). The user would use something like $nl and $sp to explicitely enter new lines and spaces. The advantage is that you control completely the formatting (no magic anymore) at the cost of a little extra work (adding the $nl where required). Basically this means the same pros/cons as when you work with HTML where you need to explicitly add <br/> when you want new lines. Ex: some text $nl $sp next line #if (...) this goes on the same line #something(...) <-- this is also on the same line #end $nl $nl This a new paragraph Note: I've aerated the text by putting extra new lines around the velocity #if to show that it would work. 3) Same as 1) + strip 1 NL (i.e. line breaks) and only allow "forced" line breaks with "\\". The exact algorithm is: if there's 1 NL remove it, if there's more than 1 leave them. Ex: some text\\ ~ next line #if (...) this goes on the same line #something(...) <-- this is also on the same line #end This a new paragraph I'm +1 for A) For B) I think the most flexible is 2) but I'm wondering if it's too big a change for our users or not. If not 2) then 3). Thanks -Vincent
Vincent Massol wrote:
Hi devs,
We need to come to a conclusion for handling New Lines(NL) and white spaces (WS) in HTML and Velocity Macro. If you remember from http://markmail.org/thread/mhqhxnz5twhev5se the current problem is that we cannot indent scripts since WS and NL are meaningful.
I'd like to reiterate the proposal that was sent but not enough people voted on it (only Thomas did).
A) For the HTML macro, we propose to make the following changes: - strip NL/WS between elements (elements that don't accept CDATA) - strip leading/trailing NL/WS for element content before passing them to the wiki syntax parser
But if macro specifies wiki=no, then all whitespaces should be interpreted HTML style.
B) for the Velocity macro we have 2 choices I can think of:
1) strip all leading spaces for all lines (but keep NL)
Note that this means that inside a velocity macro you wouldn't be able to have a line break with the new line starting with spaces without escaping the leading space with ~(space). Note also that this means we will not be able to add extra new lines to format the text nicely (since that would add new paragraphs) or split a single line into several lines for extra readability. This is the case today with the old syntax and it's a pain not to be able to aerate the text with empty lines.
Ex:
some text ~ next line #if (...) this goes on the same line #something(...) #end
This is a new paragraph
In this example notice that we need the velocity #if to be on the same line since NL are significant.
2) strip all leading spaces for all lines + remove all NL too.
This means we need to ensure we still have one space remaining between "words" (same as HTML). The user would use something like $nl and $sp to explicitely enter new lines and spaces. The advantage is that you control completely the formatting (no magic anymore) at the cost of a little extra work (adding the $nl where required). Basically this means the same pros/cons as when you work with HTML where you need to explicitly add <br/> when you want new lines.
Ex:
some text $nl $sp next line
#if (...) this goes on the same line #something(...) <-- this is also on the same line #end
$nl $nl This a new paragraph
Note: I've aerated the text by putting extra new lines around the velocity #if to show that it would work.
3) Same as 1) + strip 1 NL (i.e. line breaks) and only allow "forced" line breaks with "\\".
The exact algorithm is: if there's 1 NL remove it, if there's more than 1 leave them.
Ex:
some text\\ ~ next line #if (...) this goes on the same line #something(...) <-- this is also on the same line #end
This a new paragraph
I'm +1 for A)
For B) I think the most flexible is 2) but I'm wondering if it's too big a change for our users or not. If not 2) then 3).
+1 for A) +1 for B2), I think it's the only one with simple rules (the others are a bit sophisticated with too many particular cases), and even if it's a big change, at least it's easy to understand.
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Apr 16, 2009, at 4:33 PM, Anca Paula Luca wrote:
Vincent Massol wrote:
Hi devs,
We need to come to a conclusion for handling New Lines(NL) and white spaces (WS) in HTML and Velocity Macro. If you remember from http://markmail.org/thread/mhqhxnz5twhev5se the current problem is that we cannot indent scripts since WS and NL are meaningful.
I'd like to reiterate the proposal that was sent but not enough people voted on it (only Thomas did).
A) For the HTML macro, we propose to make the following changes: - strip NL/WS between elements (elements that don't accept CDATA) - strip leading/trailing NL/WS for element content before passing them to the wiki syntax parser
But if macro specifies wiki=no, then all whitespaces should be interpreted HTML style.
yes, this is only for when wiki=true. [snip] Thanks -Vincent
Vincent Massol wrote:
Hi devs,
We need to come to a conclusion for handling New Lines(NL) and white spaces (WS) in HTML and Velocity Macro. If you remember from http://markmail.org/thread/mhqhxnz5twhev5se the current problem is that we cannot indent scripts since WS and NL are meaningful.
I'd like to reiterate the proposal that was sent but not enough people voted on it (only Thomas did).
A) For the HTML macro, we propose to make the following changes: - strip NL/WS between elements (elements that don't accept CDATA) - strip leading/trailing NL/WS for element content before passing them to the wiki syntax parser
B) for the Velocity macro we have 2 choices I can think of:
1) strip all leading spaces for all lines (but keep NL)
Note that this means that inside a velocity macro you wouldn't be able to have a line break with the new line starting with spaces without escaping the leading space with ~(space). Note also that this means we will not be able to add extra new lines to format the text nicely (since that would add new paragraphs) or split a single line into several lines for extra readability. This is the case today with the old syntax and it's a pain not to be able to aerate the text with empty lines.
Ex:
some text ~ next line #if (...) this goes on the same line #something(...) #end
This is a new paragraph
In this example notice that we need the velocity #if to be on the same line since NL are significant.
2) strip all leading spaces for all lines + remove all NL too.
This means we need to ensure we still have one space remaining between "words" (same as HTML). The user would use something like $nl and $sp to explicitely enter new lines and spaces. The advantage is that you control completely the formatting (no magic anymore) at the cost of a little extra work (adding the $nl where required). Basically this means the same pros/cons as when you work with HTML where you need to explicitly add <br/> when you want new lines.
Ex:
some text $nl $sp next line
#if (...) this goes on the same line #something(...) <-- this is also on the same line #end
$nl $nl This a new paragraph
Note: I've aerated the text by putting extra new lines around the velocity #if to show that it would work.
3) Same as 1) + strip 1 NL (i.e. line breaks) and only allow "forced" line breaks with "\\".
The exact algorithm is: if there's 1 NL remove it, if there's more than 1 leave them.
Ex:
some text\\ ~ next line #if (...) this goes on the same line #something(...) <-- this is also on the same line #end
This a new paragraph
I'm +1 for A)
For B) I think the most flexible is 2) but I'm wondering if it's too big a change for our users or not. If not 2) then 3).
+1 for A and B2 -- Sergiu Dumitriu http://purl.org/net/sergiu/
A) +1 B) +1 for 2) On Thu, Apr 16, 2009 at 15:56, Vincent Massol <[email protected]> wrote:
Hi devs,
We need to come to a conclusion for handling New Lines(NL) and white spaces (WS) in HTML and Velocity Macro. If you remember from http://markmail.org/thread/mhqhxnz5twhev5se the current problem is that we cannot indent scripts since WS and NL are meaningful.
I'd like to reiterate the proposal that was sent but not enough people voted on it (only Thomas did).
A) For the HTML macro, we propose to make the following changes: - strip NL/WS between elements (elements that don't accept CDATA) - strip leading/trailing NL/WS for element content before passing them to the wiki syntax parser
B) for the Velocity macro we have 2 choices I can think of:
1) strip all leading spaces for all lines (but keep NL)
Note that this means that inside a velocity macro you wouldn't be able to have a line break with the new line starting with spaces without escaping the leading space with ~(space). Note also that this means we will not be able to add extra new lines to format the text nicely (since that would add new paragraphs) or split a single line into several lines for extra readability. This is the case today with the old syntax and it's a pain not to be able to aerate the text with empty lines.
Ex:
some text ~ next line #if (...) this goes on the same line #something(...) #end
This is a new paragraph
In this example notice that we need the velocity #if to be on the same line since NL are significant.
2) strip all leading spaces for all lines + remove all NL too.
This means we need to ensure we still have one space remaining between "words" (same as HTML). The user would use something like $nl and $sp to explicitely enter new lines and spaces. The advantage is that you control completely the formatting (no magic anymore) at the cost of a little extra work (adding the $nl where required). Basically this means the same pros/cons as when you work with HTML where you need to explicitly add <br/> when you want new lines.
Ex:
some text $nl $sp next line
#if (...) this goes on the same line #something(...) <-- this is also on the same line #end
$nl $nl This a new paragraph
Note: I've aerated the text by putting extra new lines around the velocity #if to show that it would work.
3) Same as 1) + strip 1 NL (i.e. line breaks) and only allow "forced" line breaks with "\\".
The exact algorithm is: if there's 1 NL remove it, if there's more than 1 leave them.
Ex:
some text\\ ~ next line #if (...) this goes on the same line #something(...) <-- this is also on the same line #end
This a new paragraph
I'm +1 for A)
For B) I think the most flexible is 2) but I'm wondering if it's too big a change for our users or not. If not 2) then 3).
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
+1 for A and B2 Vincent Massol wrote:
Hi devs,
We need to come to a conclusion for handling New Lines(NL) and white spaces (WS) in HTML and Velocity Macro. If you remember from http://markmail.org/thread/mhqhxnz5twhev5se the current problem is that we cannot indent scripts since WS and NL are meaningful.
I'd like to reiterate the proposal that was sent but not enough people voted on it (only Thomas did).
A) For the HTML macro, we propose to make the following changes: - strip NL/WS between elements (elements that don't accept CDATA) - strip leading/trailing NL/WS for element content before passing them to the wiki syntax parser
B) for the Velocity macro we have 2 choices I can think of:
1) strip all leading spaces for all lines (but keep NL)
Note that this means that inside a velocity macro you wouldn't be able to have a line break with the new line starting with spaces without escaping the leading space with ~(space). Note also that this means we will not be able to add extra new lines to format the text nicely (since that would add new paragraphs) or split a single line into several lines for extra readability. This is the case today with the old syntax and it's a pain not to be able to aerate the text with empty lines.
Ex:
some text ~ next line #if (...) this goes on the same line #something(...) #end
This is a new paragraph
In this example notice that we need the velocity #if to be on the same line since NL are significant.
2) strip all leading spaces for all lines + remove all NL too.
This means we need to ensure we still have one space remaining between "words" (same as HTML). The user would use something like $nl and $sp to explicitely enter new lines and spaces. The advantage is that you control completely the formatting (no magic anymore) at the cost of a little extra work (adding the $nl where required). Basically this means the same pros/cons as when you work with HTML where you need to explicitly add <br/> when you want new lines.
Ex:
some text $nl $sp next line
#if (...) this goes on the same line #something(...) <-- this is also on the same line #end
$nl $nl This a new paragraph
Note: I've aerated the text by putting extra new lines around the velocity #if to show that it would work.
3) Same as 1) + strip 1 NL (i.e. line breaks) and only allow "forced" line breaks with "\\".
The exact algorithm is: if there's 1 NL remove it, if there's more than 1 leave them.
Ex:
some text\\ ~ next line #if (...) this goes on the same line #something(...) <-- this is also on the same line #end
This a new paragraph
I'm +1 for A)
For B) I think the most flexible is 2) but I'm wondering if it's too big a change for our users or not. If not 2) then 3).
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
I'm a bit afraid by B2.. It sound really weird to me to have all this some text $nl $sp next line #if (...) this goes on the same line #something(...) <-- this is also on the same line #end $nl $nl This a new paragraph Not produce something that would look more like what is typed. The stripping of leading white spaces sounds ok to me. But the stripping of new lines sounds bad to me. We can still use ## for spacing out code if I don't want a line for it. This sounds a good solution to me. I don't really understand the issur with line breaks with the new line starting with space. For splitting code over 2 lines, could we use \ at the end of the line to remove the new line ? So I'm +1 B1/ -1 on B2/ I'm not sure to understand the implications of A/ Vincent Massol a écrit :
Hi devs,
We need to come to a conclusion for handling New Lines(NL) and white spaces (WS) in HTML and Velocity Macro. If you remember from http://markmail.org/thread/mhqhxnz5twhev5se the current problem is that we cannot indent scripts since WS and NL are meaningful.
I'd like to reiterate the proposal that was sent but not enough people voted on it (only Thomas did).
A) For the HTML macro, we propose to make the following changes: - strip NL/WS between elements (elements that don't accept CDATA) - strip leading/trailing NL/WS for element content before passing them to the wiki syntax parser
B) for the Velocity macro we have 2 choices I can think of:
1) strip all leading spaces for all lines (but keep NL)
Note that this means that inside a velocity macro you wouldn't be able to have a line break with the new line starting with spaces without escaping the leading space with ~(space). Note also that this means we will not be able to add extra new lines to format the text nicely (since that would add new paragraphs) or split a single line into several lines for extra readability. This is the case today with the old syntax and it's a pain not to be able to aerate the text with empty lines.
Ex:
some text ~ next line #if (...) this goes on the same line #something(...) #end
This is a new paragraph
In this example notice that we need the velocity #if to be on the same line since NL are significant.
2) strip all leading spaces for all lines + remove all NL too.
This means we need to ensure we still have one space remaining between "words" (same as HTML). The user would use something like $nl and $sp to explicitely enter new lines and spaces. The advantage is that you control completely the formatting (no magic anymore) at the cost of a little extra work (adding the $nl where required). Basically this means the same pros/cons as when you work with HTML where you need to explicitly add <br/> when you want new lines.
Ex:
some text $nl $sp next line
#if (...) this goes on the same line #something(...) <-- this is also on the same line #end
$nl $nl This a new paragraph
Note: I've aerated the text by putting extra new lines around the velocity #if to show that it would work.
3) Same as 1) + strip 1 NL (i.e. line breaks) and only allow "forced" line breaks with "\\".
The exact algorithm is: if there's 1 NL remove it, if there's more than 1 leave them.
Ex:
some text\\ ~ next line #if (...) this goes on the same line #something(...) <-- this is also on the same line #end
This a new paragraph
I'm +1 for A)
For B) I think the most flexible is 2) but I'm wondering if it's too big a change for our users or not. If not 2) then 3).
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
On Apr 16, 2009, at 11:49 PM, Ludovic Dubost wrote:
I'm a bit afraid by B2.. It sound really weird to me to have all this
some text $nl $sp next line
#if (...) this goes on the same line #something(...) <-- this is also on the same line #end
$nl $nl This a new paragraph
Not produce something that would look more like what is typed. The stripping of leading white spaces sounds ok to me. But the stripping of new lines sounds bad to me.
We can still use ## for spacing out code if I don't want a line for it. This sounds a good solution to me.
B1 means that have to put velocity code on the same line if it goes on the same line and we cannot align it on following lines (as shown in the example below). For ex: hello #if (...) ... #end The following will generate an extra NL: hello #if (...) ... #end Right now we already have an important issue in velocity code that make it awkward and generate lots of problems: the fact that code cannot be spaced out and empty lines generate paragraphs. With B1 we have the same problems but worse since NL are significants.
I don't really understand the issur with line breaks with the new line starting with space.
If you strip leading spaces you need a way to force a leading space when you have a line break and want to have the second line with leading spaces.
For splitting code over 2 lines, could we use \ at the end of the line to remove the new line ?
\\ forces a line break so it's the opposite. You don't need \\ with B1 since NL are significant. BTW if you want to see more exampleq, see http://jira.xwiki.org/jira/browse/XWIKI-3107?focusedCommentId=37707&page=com... Another example is: hello #if (...) ... #end #if (...) ... meaning you have to make sure you put velocity commands one next to the other or they'll be displayed on the next line. Thanks -Vincent
So I'm +1 B1/ -1 on B2/
I'm not sure to understand the implications of A/
Vincent Massol a écrit :
Hi devs,
We need to come to a conclusion for handling New Lines(NL) and white spaces (WS) in HTML and Velocity Macro. If you remember from http://markmail.org/thread/mhqhxnz5twhev5se the current problem is that we cannot indent scripts since WS and NL are meaningful.
I'd like to reiterate the proposal that was sent but not enough people voted on it (only Thomas did).
A) For the HTML macro, we propose to make the following changes: - strip NL/WS between elements (elements that don't accept CDATA) - strip leading/trailing NL/WS for element content before passing them to the wiki syntax parser
B) for the Velocity macro we have 2 choices I can think of:
1) strip all leading spaces for all lines (but keep NL)
Note that this means that inside a velocity macro you wouldn't be able to have a line break with the new line starting with spaces without escaping the leading space with ~(space). Note also that this means we will not be able to add extra new lines to format the text nicely (since that would add new paragraphs) or split a single line into several lines for extra readability. This is the case today with the old syntax and it's a pain not to be able to aerate the text with empty lines.
Ex:
some text ~ next line #if (...) this goes on the same line #something(...) #end
This is a new paragraph
In this example notice that we need the velocity #if to be on the same line since NL are significant.
2) strip all leading spaces for all lines + remove all NL too.
This means we need to ensure we still have one space remaining between "words" (same as HTML). The user would use something like $nl and $sp to explicitely enter new lines and spaces. The advantage is that you control completely the formatting (no magic anymore) at the cost of a little extra work (adding the $nl where required). Basically this means the same pros/cons as when you work with HTML where you need to explicitly add <br/> when you want new lines.
Ex:
some text $nl $sp next line
#if (...) this goes on the same line #something(...) <-- this is also on the same line #end
$nl $nl This a new paragraph
Note: I've aerated the text by putting extra new lines around the velocity #if to show that it would work.
3) Same as 1) + strip 1 NL (i.e. line breaks) and only allow "forced" line breaks with "\\".
The exact algorithm is: if there's 1 NL remove it, if there's more than 1 leave them.
Ex:
some text\\ ~ next line #if (...) this goes on the same line #something(...) <-- this is also on the same line #end
This a new paragraph
I'm +1 for A)
For B) I think the most flexible is 2) but I'm wondering if it's too big a change for our users or not. If not 2) then 3).
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Apr 17, 2009, at 12:01 AM, Vincent Massol wrote:
On Apr 16, 2009, at 11:49 PM, Ludovic Dubost wrote:
I'm a bit afraid by B2.. It sound really weird to me to have all this
some text $nl $sp next line
#if (...) this goes on the same line #something(...) <-- this is also on the same line #end
$nl $nl This a new paragraph
Not produce something that would look more like what is typed.
The problem is that this is scripting and some construct take several lines for ex and you don't want to put everything on the same line when you code so we definitely not want to display what is typed. -Vincent
The stripping of leading white spaces sounds ok to me. But the stripping of new lines sounds bad to me.
We can still use ## for spacing out code if I don't want a line for it. This sounds a good solution to me.
B1 means that have to put velocity code on the same line if it goes on the same line and we cannot align it on following lines (as shown in the example below).
For ex:
hello #if (...) ... #end
The following will generate an extra NL:
hello #if (...) ... #end
Right now we already have an important issue in velocity code that make it awkward and generate lots of problems: the fact that code cannot be spaced out and empty lines generate paragraphs. With B1 we have the same problems but worse since NL are significants.
I don't really understand the issur with line breaks with the new line starting with space.
If you strip leading spaces you need a way to force a leading space when you have a line break and want to have the second line with leading spaces.
For splitting code over 2 lines, could we use \ at the end of the line to remove the new line ?
\\ forces a line break so it's the opposite. You don't need \\ with B1 since NL are significant.
BTW if you want to see more exampleq, see http://jira.xwiki.org/jira/browse/XWIKI-3107?focusedCommentId=37707&page=com...
Another example is:
hello #if (...) ... #end #if (...) ...
meaning you have to make sure you put velocity commands one next to the other or they'll be displayed on the next line.
Thanks -Vincent
So I'm +1 B1/ -1 on B2/
I'm not sure to understand the implications of A/
Vincent Massol a écrit :
Hi devs,
We need to come to a conclusion for handling New Lines(NL) and white spaces (WS) in HTML and Velocity Macro. If you remember from http://markmail.org/thread/mhqhxnz5twhev5se the current problem is that we cannot indent scripts since WS and NL are meaningful.
I'd like to reiterate the proposal that was sent but not enough people voted on it (only Thomas did).
A) For the HTML macro, we propose to make the following changes: - strip NL/WS between elements (elements that don't accept CDATA) - strip leading/trailing NL/WS for element content before passing them to the wiki syntax parser
B) for the Velocity macro we have 2 choices I can think of:
1) strip all leading spaces for all lines (but keep NL)
Note that this means that inside a velocity macro you wouldn't be able to have a line break with the new line starting with spaces without escaping the leading space with ~(space). Note also that this means we will not be able to add extra new lines to format the text nicely (since that would add new paragraphs) or split a single line into several lines for extra readability. This is the case today with the old syntax and it's a pain not to be able to aerate the text with empty lines.
Ex:
some text ~ next line #if (...) this goes on the same line #something(...) #end
This is a new paragraph
In this example notice that we need the velocity #if to be on the same line since NL are significant.
2) strip all leading spaces for all lines + remove all NL too.
This means we need to ensure we still have one space remaining between "words" (same as HTML). The user would use something like $nl and $sp to explicitely enter new lines and spaces. The advantage is that you control completely the formatting (no magic anymore) at the cost of a little extra work (adding the $nl where required). Basically this means the same pros/cons as when you work with HTML where you need to explicitly add <br/> when you want new lines.
Ex:
some text $nl $sp next line
#if (...) this goes on the same line #something(...) <-- this is also on the same line #end
$nl $nl This a new paragraph
Note: I've aerated the text by putting extra new lines around the velocity #if to show that it would work.
3) Same as 1) + strip 1 NL (i.e. line breaks) and only allow "forced" line breaks with "\\".
The exact algorithm is: if there's 1 NL remove it, if there's more than 1 leave them.
Ex:
some text\\ ~ next line #if (...) this goes on the same line #something(...) <-- this is also on the same line #end
This a new paragraph
I'm +1 for A)
For B) I think the most flexible is 2) but I'm wondering if it's too big a change for our users or not. If not 2) then 3).
Thanks -Vincent
______________
Can't we make NL be removed only before velocity directives: (\n\s+)#if (\n\s+)#foreach (\n\s+)#set (\n\s+)#else (\n\s+)#elseif This would sound much better to me Ludovic Vincent Massol a écrit :
On Apr 17, 2009, at 12:01 AM, Vincent Massol wrote:
On Apr 16, 2009, at 11:49 PM, Ludovic Dubost wrote:
I'm a bit afraid by B2.. It sound really weird to me to have all this
some text $nl $sp next line
#if (...) this goes on the same line #something(...) <-- this is also on the same line #end
$nl $nl This a new paragraph
Not produce something that would look more like what is typed.
The problem is that this is scripting and some construct take several lines for ex and you don't want to put everything on the same line when you code so we definitely not want to display what is typed.
-Vincent
The stripping of leading white spaces sounds ok to me. But the stripping of new lines sounds bad to me.
We can still use ## for spacing out code if I don't want a line for it. This sounds a good solution to me.
B1 means that have to put velocity code on the same line if it goes on the same line and we cannot align it on following lines (as shown in the example below).
For ex:
hello #if (...) ... #end
The following will generate an extra NL:
hello #if (...) ... #end
Right now we already have an important issue in velocity code that make it awkward and generate lots of problems: the fact that code cannot be spaced out and empty lines generate paragraphs. With B1 we have the same problems but worse since NL are significants.
I don't really understand the issur with line breaks with the new line starting with space.
If you strip leading spaces you need a way to force a leading space when you have a line break and want to have the second line with leading spaces.
For splitting code over 2 lines, could we use \ at the end of the line to remove the new line ?
\\ forces a line break so it's the opposite. You don't need \\ with B1 since NL are significant.
BTW if you want to see more exampleq, see http://jira.xwiki.org/jira/browse/XWIKI-3107?focusedCommentId=37707&page=com...
Another example is:
hello #if (...) ... #end #if (...) ...
meaning you have to make sure you put velocity commands one next to the other or they'll be displayed on the next line.
Thanks -Vincent
So I'm +1 B1/ -1 on B2/
I'm not sure to understand the implications of A/
Vincent Massol a écrit :
Hi devs,
We need to come to a conclusion for handling New Lines(NL) and white spaces (WS) in HTML and Velocity Macro. If you remember from http://markmail.org/thread/mhqhxnz5twhev5se the current problem is that we cannot indent scripts since WS and NL are meaningful.
I'd like to reiterate the proposal that was sent but not enough people voted on it (only Thomas did).
A) For the HTML macro, we propose to make the following changes: - strip NL/WS between elements (elements that don't accept CDATA) - strip leading/trailing NL/WS for element content before passing them to the wiki syntax parser
B) for the Velocity macro we have 2 choices I can think of:
1) strip all leading spaces for all lines (but keep NL)
Note that this means that inside a velocity macro you wouldn't be able to have a line break with the new line starting with spaces without escaping the leading space with ~(space). Note also that this means we will not be able to add extra new lines to format the text nicely (since that would add new paragraphs) or split a single line into several lines for extra readability. This is the case today with the old syntax and it's a pain not to be able to aerate the text with empty lines.
Ex:
some text ~ next line #if (...) this goes on the same line #something(...) #end
This is a new paragraph
In this example notice that we need the velocity #if to be on the same line since NL are significant.
2) strip all leading spaces for all lines + remove all NL too.
This means we need to ensure we still have one space remaining between "words" (same as HTML). The user would use something like $nl and $sp to explicitely enter new lines and spaces. The advantage is that you control completely the formatting (no magic anymore) at the cost of a little extra work (adding the $nl where required). Basically this means the same pros/cons as when you work with HTML where you need to explicitly add <br/> when you want new lines.
Ex:
some text $nl $sp next line
#if (...) this goes on the same line #something(...) <-- this is also on the same line #end
$nl $nl This a new paragraph
Note: I've aerated the text by putting extra new lines around the velocity #if to show that it would work.
3) Same as 1) + strip 1 NL (i.e. line breaks) and only allow "forced" line breaks with "\\".
The exact algorithm is: if there's 1 NL remove it, if there's more than 1 leave them.
Ex:
some text\\ ~ next line #if (...) this goes on the same line #something(...) <-- this is also on the same line #end
This a new paragraph
I'm +1 for A)
For B) I think the most flexible is 2) but I'm wondering if it's too big a change for our users or not. If not 2) then 3).
Thanks -Vincent
______________
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
Ludovic Dubost wrote:
Can't we make NL be removed only before velocity directives:
(\n\s+)#if (\n\s+)#foreach (\n\s+)#set (\n\s+)#else (\n\s+)#elseif
This would sound much better to me
Note that velocity also has its own newline removal rules, which we can't control. This means that even if we want it, we can't introduce a newline here: Start the line #set($x = 'x') ... and this is on the same line
Ludovic
Vincent Massol a écrit :
On Apr 17, 2009, at 12:01 AM, Vincent Massol wrote:
On Apr 16, 2009, at 11:49 PM, Ludovic Dubost wrote:
I'm a bit afraid by B2.. It sound really weird to me to have all this
some text $nl $sp next line
#if (...) this goes on the same line #something(...) <-- this is also on the same line #end
$nl $nl This a new paragraph
Not produce something that would look more like what is typed.
The problem is that this is scripting and some construct take several lines for ex and you don't want to put everything on the same line when you code so we definitely not want to display what is typed.
-Vincent
The stripping of leading white spaces sounds ok to me. But the stripping of new lines sounds bad to me.
We can still use ## for spacing out code if I don't want a line for it. This sounds a good solution to me.
B1 means that have to put velocity code on the same line if it goes on the same line and we cannot align it on following lines (as shown in the example below).
For ex:
hello #if (...) ... #end
The following will generate an extra NL:
hello #if (...) ... #end
Right now we already have an important issue in velocity code that make it awkward and generate lots of problems: the fact that code cannot be spaced out and empty lines generate paragraphs. With B1 we have the same problems but worse since NL are significants.
I don't really understand the issur with line breaks with the new line starting with space.
If you strip leading spaces you need a way to force a leading space when you have a line break and want to have the second line with leading spaces.
For splitting code over 2 lines, could we use \ at the end of the line to remove the new line ?
\\ forces a line break so it's the opposite. You don't need \\ with B1 since NL are significant.
BTW if you want to see more exampleq, see http://jira.xwiki.org/jira/browse/XWIKI-3107?focusedCommentId=37707&page=com...
Another example is:
hello #if (...) ... #end #if (...) ...
meaning you have to make sure you put velocity commands one next to the other or they'll be displayed on the next line.
Thanks -Vincent
So I'm +1 B1/ -1 on B2/
I'm not sure to understand the implications of A/
Vincent Massol a écrit :
Hi devs,
We need to come to a conclusion for handling New Lines(NL) and white spaces (WS) in HTML and Velocity Macro. If you remember from http://markmail.org/thread/mhqhxnz5twhev5se the current problem is that we cannot indent scripts since WS and NL are meaningful.
I'd like to reiterate the proposal that was sent but not enough people voted on it (only Thomas did).
A) For the HTML macro, we propose to make the following changes: - strip NL/WS between elements (elements that don't accept CDATA) - strip leading/trailing NL/WS for element content before passing them to the wiki syntax parser
B) for the Velocity macro we have 2 choices I can think of:
1) strip all leading spaces for all lines (but keep NL)
Note that this means that inside a velocity macro you wouldn't be able to have a line break with the new line starting with spaces without escaping the leading space with ~(space). Note also that this means we will not be able to add extra new lines to format the text nicely (since that would add new paragraphs) or split a single line into several lines for extra readability. This is the case today with the old syntax and it's a pain not to be able to aerate the text with empty lines.
Ex:
some text ~ next line #if (...) this goes on the same line #something(...) #end
This is a new paragraph
In this example notice that we need the velocity #if to be on the same line since NL are significant.
2) strip all leading spaces for all lines + remove all NL too.
This means we need to ensure we still have one space remaining between "words" (same as HTML). The user would use something like $nl and $sp to explicitely enter new lines and spaces. The advantage is that you control completely the formatting (no magic anymore) at the cost of a little extra work (adding the $nl where required). Basically this means the same pros/cons as when you work with HTML where you need to explicitly add <br/> when you want new lines.
Ex:
some text $nl $sp next line
#if (...) this goes on the same line #something(...) <-- this is also on the same line #end
$nl $nl This a new paragraph
Note: I've aerated the text by putting extra new lines around the velocity #if to show that it would work.
3) Same as 1) + strip 1 NL (i.e. line breaks) and only allow "forced" line breaks with "\\".
The exact algorithm is: if there's 1 NL remove it, if there's more than 1 leave them.
Ex:
some text\\ ~ next line #if (...) this goes on the same line #something(...) <-- this is also on the same line #end
This a new paragraph
I'm +1 for A)
For B) I think the most flexible is 2) but I'm wondering if it's too big a change for our users or not. If not 2) then 3).
Thanks -Vincent
-- Sergiu Dumitriu http://purl.org/net/sergiu/
Let's be clear with exact examples: With B2/ rule what do we get for I like this #if($a==1) apple #else orange #end blabla I would like to get I like this apple blabla Which is passed to the following rendered. I agree that white spaces should be non meaningful I like this #if($a==1) apple #else orange #end blabla Should get the exact same result I like this apple blabla Basically I think it should give about the same result it used to get in syntax 1.0 Ludovic Sergiu Dumitriu a écrit :
Ludovic Dubost wrote:
Can't we make NL be removed only before velocity directives:
(\n\s+)#if (\n\s+)#foreach (\n\s+)#set (\n\s+)#else (\n\s+)#elseif
This would sound much better to me
Note that velocity also has its own newline removal rules, which we can't control. This means that even if we want it, we can't introduce a newline here:
Start the line #set($x = 'x') ... and this is on the same line
Ludovic
Vincent Massol a écrit :
On Apr 17, 2009, at 12:01 AM, Vincent Massol wrote:
On Apr 16, 2009, at 11:49 PM, Ludovic Dubost wrote:
I'm a bit afraid by B2.. It sound really weird to me to have all this
some text $nl $sp next line
#if (...) this goes on the same line #something(...) <-- this is also on the same line #end
$nl $nl This a new paragraph
Not produce something that would look more like what is typed.
The problem is that this is scripting and some construct take several lines for ex and you don't want to put everything on the same line when you code so we definitely not want to display what is typed.
-Vincent
The stripping of leading white spaces sounds ok to me. But the stripping of new lines sounds bad to me.
We can still use ## for spacing out code if I don't want a line for it. This sounds a good solution to me.
B1 means that have to put velocity code on the same line if it goes on the same line and we cannot align it on following lines (as shown in the example below).
For ex:
hello #if (...) ... #end
The following will generate an extra NL:
hello #if (...) ... #end
Right now we already have an important issue in velocity code that make it awkward and generate lots of problems: the fact that code cannot be spaced out and empty lines generate paragraphs. With B1 we have the same problems but worse since NL are significants.
I don't really understand the issur with line breaks with the new line starting with space.
If you strip leading spaces you need a way to force a leading space when you have a line break and want to have the second line with leading spaces.
For splitting code over 2 lines, could we use \ at the end of the line to remove the new line ?
\\ forces a line break so it's the opposite. You don't need \\ with B1 since NL are significant.
BTW if you want to see more exampleq, see http://jira.xwiki.org/jira/browse/XWIKI-3107?focusedCommentId=37707&page=com...
Another example is:
hello #if (...) ... #end #if (...) ...
meaning you have to make sure you put velocity commands one next to the other or they'll be displayed on the next line.
Thanks -Vincent
So I'm +1 B1/ -1 on B2/
I'm not sure to understand the implications of A/
Vincent Massol a écrit :
Hi devs,
We need to come to a conclusion for handling New Lines(NL) and white spaces (WS) in HTML and Velocity Macro. If you remember from http://markmail.org/thread/mhqhxnz5twhev5se the current problem is that we cannot indent scripts since WS and NL are meaningful.
I'd like to reiterate the proposal that was sent but not enough people voted on it (only Thomas did).
A) For the HTML macro, we propose to make the following changes: - strip NL/WS between elements (elements that don't accept CDATA) - strip leading/trailing NL/WS for element content before passing them to the wiki syntax parser
B) for the Velocity macro we have 2 choices I can think of:
1) strip all leading spaces for all lines (but keep NL)
Note that this means that inside a velocity macro you wouldn't be able to have a line break with the new line starting with spaces without escaping the leading space with ~(space). Note also that this means we will not be able to add extra new lines to format the text nicely (since that would add new paragraphs) or split a single line into several lines for extra readability. This is the case today with the old syntax and it's a pain not to be able to aerate the text with empty lines.
Ex:
some text ~ next line #if (...) this goes on the same line #something(...) #end
This is a new paragraph
In this example notice that we need the velocity #if to be on the same line since NL are significant.
2) strip all leading spaces for all lines + remove all NL too.
This means we need to ensure we still have one space remaining between "words" (same as HTML). The user would use something like $nl and $sp to explicitely enter new lines and spaces. The advantage is that you control completely the formatting (no magic anymore) at the cost of a little extra work (adding the $nl where required). Basically this means the same pros/cons as when you work with HTML where you need to explicitly add <br/> when you want new lines.
Ex:
some text $nl $sp next line
#if (...) this goes on the same line #something(...) <-- this is also on the same line #end
$nl $nl This a new paragraph
Note: I've aerated the text by putting extra new lines around the velocity #if to show that it would work.
3) Same as 1) + strip 1 NL (i.e. line breaks) and only allow "forced" line breaks with "\\".
The exact algorithm is: if there's 1 NL remove it, if there's more than 1 leave them.
Ex:
some text\\ ~ next line #if (...) this goes on the same line #something(...) <-- this is also on the same line #end
This a new paragraph
I'm +1 for A)
For B) I think the most flexible is 2) but I'm wondering if it's too big a change for our users or not. If not 2) then 3).
Thanks -Vincent
-- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
On Apr 17, 2009, at 3:10 PM, Ludovic Dubost wrote:
Let's be clear with exact examples:
With B2/ rule what do we get for
I like this #if($a==1) apple #else orange #end blabla
I would like to get
I like this apple blabla
Which is passed to the following rendered.
I agree that white spaces should be non meaningful
I like this #if($a==1) apple #else orange #end blabla
In B2 you'd be able to write: ------ start here ----- I like this ## Compute the list of fruits to be... #if ($a == 1) apple #else orange #end $nl blabla ------ stop here ----- Note the extra lines to present the code in a clean manner that is readable (as we do for any java code - count the number of empty new lines we have in code just to make it more readable). -Vincent
Should get the exact same result
I like this apple blabla
Basically I think it should give about the same result it used to get in syntax 1.0
Ludovic
Sergiu Dumitriu a écrit :
Ludovic Dubost wrote:
Can't we make NL be removed only before velocity directives:
(\n\s+)#if (\n\s+)#foreach (\n\s+)#set (\n\s+)#else (\n\s+)#elseif
This would sound much better to me
Note that velocity also has its own newline removal rules, which we can't control. This means that even if we want it, we can't introduce a newline here:
Start the line #set($x = 'x') ... and this is on the same line
Ludovic
Vincent Massol a écrit :
On Apr 17, 2009, at 12:01 AM, Vincent Massol wrote:
On Apr 16, 2009, at 11:49 PM, Ludovic Dubost wrote:
I'm a bit afraid by B2.. It sound really weird to me to have all this
some text $nl $sp next line
#if (...) this goes on the same line #something(...) <-- this is also on the same line #end
$nl $nl This a new paragraph
Not produce something that would look more like what is typed.
The problem is that this is scripting and some construct take several lines for ex and you don't want to put everything on the same line when you code so we definitely not want to display what is typed.
-Vincent
The stripping of leading white spaces sounds ok to me. But the stripping of new lines sounds bad to me.
We can still use ## for spacing out code if I don't want a line for it. This sounds a good solution to me.
B1 means that have to put velocity code on the same line if it goes on the same line and we cannot align it on following lines (as shown in the example below).
For ex:
hello #if (...) ... #end
The following will generate an extra NL:
hello #if (...) ... #end
Right now we already have an important issue in velocity code that make it awkward and generate lots of problems: the fact that code cannot be spaced out and empty lines generate paragraphs. With B1 we have the same problems but worse since NL are significants.
I don't really understand the issur with line breaks with the new line starting with space.
If you strip leading spaces you need a way to force a leading space when you have a line break and want to have the second line with leading spaces.
For splitting code over 2 lines, could we use \ at the end of the line to remove the new line ?
\\ forces a line break so it's the opposite. You don't need \\ with B1 since NL are significant.
BTW if you want to see more exampleq, see http://jira.xwiki.org/jira/browse/XWIKI-3107?focusedCommentId=37707&page=com...
Another example is:
hello #if (...) ... #end #if (...) ...
meaning you have to make sure you put velocity commands one next to the other or they'll be displayed on the next line.
Thanks -Vincent
So I'm +1 B1/ -1 on B2/
I'm not sure to understand the implications of A/
Vincent Massol a écrit :
> Hi devs, > > We need to come to a conclusion for handling New Lines(NL) and > white > spaces (WS) in HTML and Velocity Macro. > If you remember from http://markmail.org/thread/ > mhqhxnz5twhev5se the > current problem is that we cannot indent scripts since WS and > NL are > meaningful. > > I'd like to reiterate the proposal that was sent but not enough > people > voted on it (only Thomas did). > > A) For the HTML macro, we propose to make the following changes: > - strip NL/WS between elements (elements that don't accept > CDATA) > - strip leading/trailing NL/WS for element content before > passing > them > to the wiki syntax parser > > B) for the Velocity macro we have 2 choices I can think of: > > 1) strip all leading spaces for all lines (but keep NL) > > Note that this means that inside a velocity macro you wouldn't > be > able > to have a line break with the new line starting with spaces > without > escaping the leading space with ~(space). > Note also that this means we will not be able to add extra new > lines > to format the text nicely (since that would add new > paragraphs) or > split a single line into several lines for extra readability. > This > is > the case today with the old syntax and it's a pain not to be > able to > aerate the text with empty lines. > > Ex: > > some text > ~ next line #if (...) this goes on the same line > #something(...) > #end > > This is a new paragraph > > In this example notice that we need the velocity #if to be on > the > same > line since NL are significant. > > 2) strip all leading spaces for all lines + remove all NL too. > > This means we need to ensure we still have one space remaining > between > "words" (same as HTML). > The user would use something like $nl and $sp to explicitely > enter > new > lines and spaces. > The advantage is that you control completely the formatting (no > magic > anymore) at the cost of a little extra work (adding the $nl > where > required). > Basically this means the same pros/cons as when you work with > HTML > where you need to explicitly add <br/> when you want new lines. > > Ex: > > some text $nl > $sp next line > > #if (...) > this goes on the same line > #something(...) <-- this is also on the same line > #end > > $nl $nl > This a new paragraph > > Note: I've aerated the text by putting extra new lines around > the > velocity #if to show that it would work. > > 3) Same as 1) + strip 1 NL (i.e. line breaks) and only allow > "forced" > line breaks with "\\". > > The exact algorithm is: if there's 1 NL remove it, if there's > more > than 1 leave them. > > Ex: > > some text\\ > ~ next line > #if (...) > this goes on the same line > #something(...) <-- this is also on the same line > #end > > This a new paragraph > > I'm +1 for A) > > For B) I think the most flexible is 2) but I'm wondering if > it's too > big a change for our users or not. If not 2) then 3). > > Thanks > -Vincent > >
-- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Vincent Massol a écrit :
On Apr 17, 2009, at 3:10 PM, Ludovic Dubost wrote:
Let's be clear with exact examples:
With B2/ rule what do we get for
I like this #if($a==1) apple #else orange #end blabla
I would like to get
I like this apple blabla
Which is passed to the following rendered.
I agree that white spaces should be non meaningful
I like this #if($a==1) apple #else orange #end blabla
In B2 you'd be able to write:
------ start here ----- I like this
## Compute the list of fruits to be... #if ($a == 1) apple #else orange #end
$nl blabla ------ stop here -----
Note the extra lines to present the code in a clean manner that is readable (as we do for any java code - count the number of empty new lines we have in code just to make it more readable).
Yes but if you want to actually put new lines you'll have to add $nl I fear that this will lead to plenty of pages saved where you then realize that you forgot plenty of $nl Anyway, I have the feeling that we cannot know which one is good unless we actuall test them. Anyway to implement a mode on {{velocity}} so that we can decide later which one to use as default ? Ludovic
-Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
ok to go for A) and B-2) Jerome Vincent Massol wrote:
Hi devs,
We need to come to a conclusion for handling New Lines(NL) and white spaces (WS) in HTML and Velocity Macro. If you remember from http://markmail.org/thread/mhqhxnz5twhev5se the current problem is that we cannot indent scripts since WS and NL are meaningful.
I'd like to reiterate the proposal that was sent but not enough people voted on it (only Thomas did).
A) For the HTML macro, we propose to make the following changes: - strip NL/WS between elements (elements that don't accept CDATA) - strip leading/trailing NL/WS for element content before passing them to the wiki syntax parser
B) for the Velocity macro we have 2 choices I can think of:
1) strip all leading spaces for all lines (but keep NL)
Note that this means that inside a velocity macro you wouldn't be able to have a line break with the new line starting with spaces without escaping the leading space with ~(space). Note also that this means we will not be able to add extra new lines to format the text nicely (since that would add new paragraphs) or split a single line into several lines for extra readability. This is the case today with the old syntax and it's a pain not to be able to aerate the text with empty lines.
Ex:
some text ~ next line #if (...) this goes on the same line #something(...) #end
This is a new paragraph
In this example notice that we need the velocity #if to be on the same line since NL are significant.
2) strip all leading spaces for all lines + remove all NL too.
This means we need to ensure we still have one space remaining between "words" (same as HTML). The user would use something like $nl and $sp to explicitely enter new lines and spaces. The advantage is that you control completely the formatting (no magic anymore) at the cost of a little extra work (adding the $nl where required). Basically this means the same pros/cons as when you work with HTML where you need to explicitly add <br/> when you want new lines.
Ex:
some text $nl $sp next line
#if (...) this goes on the same line #something(...) <-- this is also on the same line #end
$nl $nl This a new paragraph
Note: I've aerated the text by putting extra new lines around the velocity #if to show that it would work.
3) Same as 1) + strip 1 NL (i.e. line breaks) and only allow "forced" line breaks with "\\".
The exact algorithm is: if there's 1 NL remove it, if there's more than 1 leave them.
Ex:
some text\\ ~ next line #if (...) this goes on the same line #something(...) <-- this is also on the same line #end
This a new paragraph
I'm +1 for A)
For B) I think the most flexible is 2) but I'm wondering if it's too big a change for our users or not. If not 2) then 3).
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
participants (7)
-
Anca Paula Luca -
Jerome Velociter -
Ludovic Dubost -
Marius Dumitru Florea -
Sergiu Dumitriu -
Thomas Mortagne -
Vincent Massol