velocity-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: Quick Question.
Date Tue, 10 Sep 2002 07:15:26 GMT
Another 2c embedded...

Barbara Baughman wrote:
> My program line might look like:
>          #foreach ($field in $cols)#if ($velocityCount>1), $
> The template defines an output file that will be a java program, and I
> want the program indentation to be consistent and readable in the output
> file.  Just as you want your HTML output to be pretty, I want my Java to
> be pretty.

With the whitespace handling I propose, you could write:
     #foreach( $field in $cols )
        #if( $velocityCount > 1 )
, $
or even:
     #foreach( $field in $cols )
        #if( $velocityCount > 1 )
           #print( ", $" )
which is much more readable and less error prone due to unbalanced
#end statements.

> The templating may be ugly, but the whitespace handling is at least
> predictable to me.  This was meant to be a templating language, not a
> programming language with conventions about pretty indenting to make it
> more readable, where beginning and ending whitespace are irrelevant.

I agree that the whitespace handling is currently predictable, but
ugly and far from being simple.

Please do not forget that a templating language should be so, that the
desired output can be produced. On the other hand the template should be
understandable, readable and updatable without to many ugly quirks to
achieve the desired output.

Templates are not only the input that is editted by the designer, it
creates the output that others see -> so proper whitespace handling is
an *important* issue for a templating language.

There are very few programming languages where beginning whitespace is
irrelevant, e.g. Python.

> Instead of making a lot of rules about how to change Velocity whitespace
> handling, I suggest preparing some tools on the side that make it easier
> to troubleshoot Velocity templates.

I'm not proposing to defining a lot of rules. I'm proposing to replace
the *current* lot of rules by one and only one!

Since it might be an issue to remain backward compatible, we could update
the current parser, or create an paralell one. And add a switch to change
the operational mode between these.

> I suggest having a simple Java program that you feed your template into,
> and it outputs each line of the template and the nesting level of each
> line, since indentation really helps you keep track of nesting for
> troubleshooting.
> Line of code                                 LEVEL
> ------------                                 -----
> This is an example                           0
> #foreach ($field in $cols)                   1
> #if ($velocityCount>1                        2
>   something$field                            2
> #end                                         1
> #end                                         0
> Just a thought                               0
> The output is very helpful in identifying missing or misplaced #end
> statements, and is more reliable than the programmer remembering to
> indent.

This should be relatively easy since velocity syntax is straightforward.

On the other hand, this seems to be a task that could be accomplished
by many available editors if they are enhanced with velocity flavour.
If vel establishes itself to be more of a standard, we might get some
of these soon.

> Or perhaps a tool that reformats a template to make the directives stand
> out more and automatically indents the #foreach and #if directives.  Or
> conversely, a tool that takes the template with the indentation you like
> and translates it without leading spaces in front of the directive for
> use in production, providing pretty HTML output.

I rather vote for post processing tool like tidy and jindent, etc.

> One of the beauties of Velocity is its simplicity.  I would like to keep
> it that way and work around the whitespace indentation if it bothers you.  
> Personally, I don't find whitespace handling to be a problem.  Just my
> humble opinion.

Others, as seen several times on the list do encounter the whitespace
handling aproblem and it is an issue for a templating language.

> Barbara Baughman
> X2157
> On Mon, 9 Sep 2002 wrote:
>>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:
>>#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
>>>On Fri, 6 Sep 2002 wrote:
>>>>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
>>>>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>
>>>>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#*
>>>>:) Christoph Reck
>>>>To unsubscribe, e-mail:   <>
>>>>For additional commands, e-mail: <>
>>>To unsubscribe, e-mail:   <>
>>>For additional commands, e-mail: <>
>>:) Christoph Reck
>>To unsubscribe, e-mail:   <>
>>For additional commands, e-mail: <>
> --
> To unsubscribe, e-mail:   <>
> For additional commands, e-mail: <>

:) Christoph Reck

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message