On Jun 6, 2009, at 7:07 PM, Thomas Mortagne wrote: > 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.
Yes, ok I see. Then you need full names like: macro.velocity.filter = fullWhitespaceStripper For the "no filter", we could use: macro.velocity.filter = noFilter, voidFilter, noneFilter or simply none We could also not define any value for "no filter": macro.velocity.filter = Thanks -Vincent >> 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
