On 06/04/2009 01:54 PM, Vincent Massol 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)
+1, if we need more or different, we'll implement later. > * 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 _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
