On Sat, Jun 6, 2009 at 18:48, Vincent Massol<[email protected]> wrote: > > On Jun 6, 2009, at 6:02 PM, Thomas Mortagne wrote: > >> I would need some ideas for the differents modes names configuration. > > What's the config param name? Any proposal? > > rendering.velocity.whitespaceMode
I did not test yet if we can have dot in in a property key. but I was thinking of something more like macro.velocity.filter since it's not have to be a white space cleaner but it's specific to velocity macro, anyone could code any kind of velocity macro content filter. > ? > > (provided dots work, if not: > velocityMacro.whitespaceMode for ex) > >> Here are some proposals: >> - "none": the one which do nothing (the current bahavior of velocity >> macro) > > sounds good. > >> - "html"/"compact"/"full" (I don't really like any of theses): the B2 >> behavior, i.e. replace whites spaces/new lines groups by a space >> (which looks like html behavior and so "html" mode name) and inject >> $nl and $sp binding in velocity context > > "html" sounds good to me since it's the HTML behavior. > > Another idea: > use a config param name of: stripWhitespace = none, all This is way too specific IMO, with a conf like that it's pretty useless to have generic component to clean/filter velocity content. > > Thanks > -Vincent > >> On Thu, Jun 4, 2009 at 17:24, Vincent Massol<[email protected]> >> wrote: >>> >>> 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 >>> >> >> >> >> -- >> Thomas Mortagne >> _______________________________________________ >> devs mailing list >> [email protected] >> http://lists.xwiki.org/mailman/listinfo/devs > > _______________________________________________ > 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
