Re: [xwiki-devs] [VOTE] HTML and Velocity macro NL/WS behaviors

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.

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. 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. \\ 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&pag… 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 >> >> ______________