velocity-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christoph.R...@dlr.de
Subject Re: Quick Question.
Date Mon, 09 Sep 2002 15:36:17 GMT
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>


Mime
View raw message