[xwiki-devs] [PROPOSAL] Change default velocity macro filter (was Re: [VOTE] HTML and Velocity macro NL/WS behaviors (TAKE 2))
Hi devs, The chosen filter (B2) is becoming more and more complex (I had to code an almost complete velocity parser to support it correctly) and after some more usability tests from Vincent it does not look so good after all. I coded a very simple parser (based on another of the ideas listed) which only take care of indentation: basically it mean it remove all first white spaces of each line. Vincent tested it and use ## to aerate code and actually it looks pretty good. See http://pastebin.com/m4a681aaf for example (the B2 based one is http://pastebin.com/m17149f85) and most of all it's just one line a code, a simple and quick regexp replaceAll. So i propose to put the new filter as default filter. WDYT ? Here is my +1 On Thu, Jun 4, 2009 at 12:54, Vincent Massol<[email protected]> wrote:
Hi,
We really need to close this before 1.9 final. After discussing it with Thomas here's what we propose:
* Introduce a "mode" parameter to the Velocity macro. It's a cleaning mode. * Implement 2 modes for now: - the current mode where no cleaning is done - the B2 mode as defined below (using $nl and $sp) * Introduce a xwiki.properties config to define the default mode (which would be B2 by default for now)
This allows users who are already using the 2.0 syntax today to keep using the current mode. It also allows us to introduce new cleaning mode later on (such as the one Ludovic wanted).
WDYT?
Here's my +1
Thanks -Vincent
PS: Please answer ASAP since 1.9 is supposed to be today and Thomas will need a few hours to implement this.
On Thu, Apr 16, 2009 at 3:56 PM, 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
On Jun 22, 2009, at 4:58 PM, Thomas Mortagne wrote:
Hi devs,
The chosen filter (B2) is becoming more and more complex (I had to code an almost complete velocity parser to support it correctly) and after some more usability tests from Vincent it does not look so good after all.
I coded a very simple parser (based on another of the ideas listed) which only take care of indentation: basically it mean it remove all first white spaces of each line. Vincent tested it and use ## to aerate code and actually it looks pretty good. See http://pastebin.com/m4a681aaf for example (the B2 based one is http://pastebin.com/m17149f85) and most of all it's just one line a code, a simple and quick regexp replaceAll.
So i propose to put the new filter as default filter.
WDYT ?
Here is my +1
+1 to put this as the default for *both* 1.9.1 and trunk. For those interested I have attached converted pages with the html filter and this new indent filter: http://jira.xwiki.org/jira/browse/XE-455 Thanks -Vincent
On Thu, Jun 4, 2009 at 12:54, Vincent Massol<[email protected]> wrote:
Hi,
We really need to close this before 1.9 final. After discussing it with Thomas here's what we propose:
* Introduce a "mode" parameter to the Velocity macro. It's a cleaning mode. * Implement 2 modes for now: - the current mode where no cleaning is done - the B2 mode as defined below (using $nl and $sp) * Introduce a xwiki.properties config to define the default mode (which would be B2 by default for now)
This allows users who are already using the 2.0 syntax today to keep using the current mode. It also allows us to introduce new cleaning mode later on (such as the one Ludovic wanted).
WDYT?
Here's my +1
Thanks -Vincent
PS: Please answer ASAP since 1.9 is supposed to be today and Thomas will need a few hours to implement this.
On Thu, Apr 16, 2009 at 3:56 PM, 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
+1 Thanks, Marius Thomas Mortagne wrote:
Hi devs,
The chosen filter (B2) is becoming more and more complex (I had to code an almost complete velocity parser to support it correctly) and after some more usability tests from Vincent it does not look so good after all.
I coded a very simple parser (based on another of the ideas listed) which only take care of indentation: basically it mean it remove all first white spaces of each line. Vincent tested it and use ## to aerate code and actually it looks pretty good. See http://pastebin.com/m4a681aaf for example (the B2 based one is http://pastebin.com/m17149f85) and most of all it's just one line a code, a simple and quick regexp replaceAll.
So i propose to put the new filter as default filter.
WDYT ?
Here is my +1
On Thu, Jun 4, 2009 at 12:54, Vincent Massol<[email protected]> wrote:
Hi,
We really need to close this before 1.9 final. After discussing it with Thomas here's what we propose:
* Introduce a "mode" parameter to the Velocity macro. It's a cleaning mode. * Implement 2 modes for now: - the current mode where no cleaning is done - the B2 mode as defined below (using $nl and $sp) * Introduce a xwiki.properties config to define the default mode (which would be B2 by default for now)
This allows users who are already using the 2.0 syntax today to keep using the current mode. It also allows us to introduce new cleaning mode later on (such as the one Ludovic wanted).
WDYT?
Here's my +1
Thanks -Vincent
PS: Please answer ASAP since 1.9 is supposed to be today and Thomas will need a few hours to implement this.
On Thu, Apr 16, 2009 at 3:56 PM, 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
+1 On Mon, Jun 22, 2009 at 8:28 PM, Thomas Mortagne <[email protected]>wrote:
Hi devs,
The chosen filter (B2) is becoming more and more complex (I had to code an almost complete velocity parser to support it correctly) and after some more usability tests from Vincent it does not look so good after all.
I coded a very simple parser (based on another of the ideas listed) which only take care of indentation: basically it mean it remove all first white spaces of each line. Vincent tested it and use ## to aerate code and actually it looks pretty good. See http://pastebin.com/m4a681aaf for example (the B2 based one is http://pastebin.com/m17149f85) and most of all it's just one line a code, a simple and quick regexp replaceAll.
So i propose to put the new filter as default filter.
WDYT ?
Here is my +1
On Thu, Jun 4, 2009 at 12:54, Vincent Massol<[email protected]> wrote:
Hi,
We really need to close this before 1.9 final. After discussing it with Thomas here's what we propose:
* Introduce a "mode" parameter to the Velocity macro. It's a cleaning mode. * Implement 2 modes for now: - the current mode where no cleaning is done - the B2 mode as defined below (using $nl and $sp) * Introduce a xwiki.properties config to define the default mode (which would be B2 by default for now)
This allows users who are already using the 2.0 syntax today to keep using the current mode. It also allows us to introduce new cleaning mode later on (such as the one Ludovic wanted).
WDYT?
Here's my +1
Thanks -Vincent
PS: Please answer ASAP since 1.9 is supposed to be today and Thomas will need a few hours to implement this.
On Thu, Apr 16, 2009 at 3:56 PM, 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 _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Four +1 and no other votes, doing it now On Mon, Jun 22, 2009 at 16:58, Thomas Mortagne <[email protected]>wrote:
Hi devs,
The chosen filter (B2) is becoming more and more complex (I had to code an almost complete velocity parser to support it correctly) and after some more usability tests from Vincent it does not look so good after all.
I coded a very simple parser (based on another of the ideas listed) which only take care of indentation: basically it mean it remove all first white spaces of each line. Vincent tested it and use ## to aerate code and actually it looks pretty good. See http://pastebin.com/m4a681aaf for example (the B2 based one is http://pastebin.com/m17149f85) and most of all it's just one line a code, a simple and quick regexp replaceAll.
So i propose to put the new filter as default filter.
WDYT ?
Here is my +1
On Thu, Jun 4, 2009 at 12:54, Vincent Massol<[email protected]> wrote:
Hi,
We really need to close this before 1.9 final. After discussing it with Thomas here's what we propose:
* Introduce a "mode" parameter to the Velocity macro. It's a cleaning mode. * Implement 2 modes for now: - the current mode where no cleaning is done - the B2 mode as defined below (using $nl and $sp) * Introduce a xwiki.properties config to define the default mode (which would be B2 by default for now)
This allows users who are already using the 2.0 syntax today to keep using the current mode. It also allows us to introduce new cleaning mode later on (such as the one Ludovic wanted).
WDYT?
Here's my +1
Thanks -Vincent
PS: Please answer ASAP since 1.9 is supposed to be today and Thomas will need a few hours to implement this.
On Thu, Apr 16, 2009 at 3:56 PM, 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 _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
participants (4)
-
Asiri Rathnayake -
Marius Dumitru Florea -
Thomas Mortagne -
Vincent Massol