velocity-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Barbara Baughman <baugh...@utdallas.edu>
Subject Re: Quick Question.
Date Mon, 09 Sep 2002 17:00:51 GMT
My program line might look like:

         #foreach ($field in $cols)#if ($velocityCount>1), $field.name#end#end

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.

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.

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 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.

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.

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.

Barbara Baughman
X2157

On Mon, 9 Sep 2002 Christoph.Reck@dlr.de 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:
> #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