On Jun 4, 2009, at 5:23 PM, Ludovic Dubost wrote: > +1 Sounds good to me > > Will this change make the macros behave like they are today ? Or > will we > have a slight change behavior in default mode ?
Default will become B2 so it'll be different. If you want the same behavior you'll need to change your xwiki.properties file to specify a different default mode. -Vincent > Ludovic > > Vincent Massol a écrit : >> 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 >> >> > > > -- > 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 _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
