velocity-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Claude Brisson" <cla...@savoirweb.com>
Subject Re: Quick Question.
Date Mon, 09 Sep 2002 16:13:04 GMT
Christoph.Reck wrote :
> 1. To enable the new whitespace handling provide a configurable switch and
>     enhance the parser. Ugh, this will make the parser code even more ugly :(

Yes, we should avoid I guess...

There are easier solutions.
For example, with DVSL, I had to produce a non-html output with rigorous line and space handling.

What I did is :

 - indent all my macros with tabs (and not spaces)
 - filter the outputstream and remove tabs

=> My macros had a clean indentation
=> My output was right as I expected

It worked because I did not need tabs, but it could give others some ideas on similar situations.

Especially, I think we could incorpore sthing like
output.globbing.policy= [ trim-lines | eat-tabs | ... ]

CloD

----- Original Message ----- 
From: <Christoph.Reck@dlr.de>
To: "Velocity Users List" <velocity-user@jakarta.apache.org>
Sent: lundi 9 septembre 2002 17:36
Subject: Re: Quick Question.


> It seems that to get the desired whitespace handling we need to
> remain backward compatible...
> 
> Possible solutions (maybe the sum of all is the way to go ?):
> 
> 1. To enable the new whitespace handling provide a configurable switch and
>     enhance the parser. Ugh, this will make the parser code even more ugly :(
> 
> 2. Move to Vel 2.0 and provide an automatic conversion for existing
>     templates to ensure they produce the original output by detecting
>     standalone directives and postfixing #**# to the line.
>     -> HTML user would not need to migrate anything...
>     -> This would allow other users to migrate to the proper whitespace
>     handling and create pretty tamples but still reuse the ported backward
>     compatible templates.
> 
> 3. Create a directive that acts like a pragma statement that is settable
>     within each template:
> #gobble_standalone_directive_whitespaces(true)
> or
> #pragma( gobble_directive_whitespaces true )
> 
> 4. Make the parser switchable by configuration, thus keeping the 1.3 parser
>     and creating a new clean-room one for the new whitespace handling mode.
> 
> Would this be a feasible solution that does not brake backward compatiblity?
> 
> one more comment embedded below:
> 
> Barbara Baughman wrote:
> > For those of us who use Velocity to generate something other than HTML
> > code, the suggestion to ignore leading whitespace before a directive
> > breaks our templates.  I have velocity templates that have leading spaces
> > before the directives, and I want those spaces to remain.
> 
> Do you have templates like:
> 
>     #if( $foo )
>       woogie
>     #end
> 
> that expects the indentation from the #if statement to appear before the
> woogie output? Ugh :<
> 
> My guess was that only unit test code would require changes to conform
> with an updated engine.
> 
> Applications that merge non HTML/Java/SQL-outputting templates could profit
> from using a configuration parameter that disables the gobbling, thus being
> backward compatible to vel 1.3.
> 
> > 
> > At one time, there was the suggestion to have an intermediate step between
> > the template parsing and output to add embellishments and modifications.
> > If that ever comes to pass, that's where you should put the method that
> > outputs pretty html code.
> > 
> > This IS a vote for the intermediate processing feature.  I can see using
> > it to add a word-processing-type step for parsed text to nicely align the
> > margins.  Personally, the HTML output is good enough for me.
> > 
> > Barbara Baughman
> > X2157
> > 
> > On Fri, 6 Sep 2002 Christoph.Reck@dlr.de wrote:
> > 
> >>Hi,
> >>
> >>Velocity has some quirks with whitespaces. Currently nicely structured
> >>templates produce ugly HTML souce, since whitespaces of indented
> >>directives are emitted to the output (except around #set(...) and #end
> >>statements).
> >>
> >>I have requested in the list to implement clear whitespace handling rules
> >>in the past within a thread called "Whitespace redux" started by Steven Hugg
> >>which got a good solution proposed by Daniel Dekany and me:
> >> >
> >> > If a line is looks like this:
> >> >   DirectiveLine ::= LineEnd TabsAndSpaces? Directive TabsAndSpaces? LineEnd
> >> >   TabsAndSpaces ::= (#x20 | #x09)+
> >> >   LineEnd       ::= StartOfStream | ((#x0D #x0A) | #x0D | #x0A) | EndOfStream
> >> > then the first "TabsAndSpaces?" and the closing "TabsAndSpaces? LineEnd"
> >> > should be gobbled. (Note that it supports multiline directives, that is
> >> > why "DirectiveLine" is not simply "Line".)
> >> > If you want the first "LineEnd" to be gobbled prepend a ## before
> >> > it (makes it part of the comment!).
> >> > To have an indented directive remain indented, add a #**# before it.
> >> >
> >> > I guess this is the nearest we can get to a perfect solution.
> >> >
> >>But sorry to say the thread did not reach a consensus and a solution. Maybe
> >>its time to take another try on getting votes the proposed solution?
> >>
> >>
> >>So to get structured templates and output you currently need to "escape" the
> >>leading whitespaces of directives. This can be done either with a #* ... *#
> >>spanning the leading whitespaces or by adding a #* at each line-end
> >>and indenting the next line and then closing with *#.
> >>
> >>For Example:
> >>## ------------------------------------------------------------------------
> >>## LOG
> >>## ------------------------------------------------------------------------
> >>### allow toggling log display
> >>#if( !$hideLog && $log && ($log.size() != 0) )
> >>#**#<br><font size="+1"><b>Log:</b></font><br>
> >>#**##foreach( $l_line in $log )
> >>#*  *##set( $l_line = $Context.encodeMarkup($l_line) )
> >>#*  *#<tt>$Regexp.substitute('s/  /&nbsp;&nbsp;/g', $l_line)</tt><br>
> >>#**##end
> >>#**#<br>
> >>#end
> >>
> >>Here the #if and #foreach emit a NL, the set gobbles it, the <tt>
> >>and <br> lines are passed as expected. So I get some extra lines
> >>in the output but no unexpected indentation.
> >>
> >>or use explicit $NL to insert line brakes where desired:
> >>
> >>#if( !$hideLog && $log && ($log.size() != 0) )#*
> >>   *#<br><font size="+1"><b>Log:</b></font><br>$NL#*
> >>   *##foreach( $l_line in $log )#*
> >>     *##set( $l_line = $Context.encodeMarkup($l_line) )#*
> >>     *#<tt>$Regexp.substitute('s/  /&nbsp;&nbsp;/g', $l_line)</tt><br>$NL#*
> >>   *##end#*
> >>   *#<br>$NL#*
> >>*##end
> >>
> >>-- 
> >>:) Christoph Reck
> >>
> >>
> >>--
> >>To unsubscribe, e-mail:   <mailto:velocity-user-unsubscribe@jakarta.apache.org>
> >>For additional commands, e-mail: <mailto:velocity-user-help@jakarta.apache.org>
> >>
> >>
> > 
> > 
> > --
> > To unsubscribe, e-mail:   <mailto:velocity-user-unsubscribe@jakarta.apache.org>
> > For additional commands, e-mail: <mailto:velocity-user-help@jakarta.apache.org>
> > 
> > 
> 
> -- 
> :) Christoph Reck
> 
> 
> --
> To unsubscribe, e-mail:   <mailto:velocity-user-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:velocity-user-help@jakarta.apache.org>
> 
> 


--
To unsubscribe, e-mail:   <mailto:velocity-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:velocity-user-help@jakarta.apache.org>


Mime
View raw message