exactly, my problem with the

#*        *#foreach(---)##

argument is that it is difficult to read.
regards

----- Original Message -----
From: "Claude Brisson" <[EMAIL PROTECTED]>
To: "Velocity Developers List" <[email protected]>
Sent: Monday, March 14, 2005 9:27 PM
Subject: Re: merge-time output on/off control?


> copy pasted from the wiki:
>
> 1.1. Possible (competing?) Objectives
>       * Make Velocity whitespace handling more intuitive
>       * Source text should become easier to read
>       * Backwards compatible: Results from existing templates should be
>         the same
>
> should we introduce some context state variables, the third objective is
> reached ipso facto.
>
> --
> Claude
>
> On Sun, 2005-03-13 at 14:11 -0800, Will Glass-Husain wrote:
> > Have you seen this?
> > http://wiki.apache.org/jakarta-velocity/VelocityWhitespaceGobbling
> >
> > Adding "##" to the end of a line seems to be the best suggestion so far.
> >
http://wiki.apache.org/jakarta-velocity/VelocityWhitespaceTruncatedByLineCom
ment
> >
> > WILL
> >
> > ----- Original Message -----
> > From: "Tim Pierce" <[EMAIL PROTECTED]>
> > To: <[email protected]>
> > Sent: Sunday, March 13, 2005 9:57 AM
> > Subject: merge-time output on/off control?
> >
> >
> > Using velocity, I have become increasingly frustrated with trying to
control
> > whitespace.
> >
> > I am generating source-code and therefore tight control of indentation
is of
> > great benefit to me.
> >
> > my velocity statements are nested to such a degree that indentation of
> > *them* is important for maintenance of the template. The example below
is a
> > real snippet from a template I'm building. Obviously, the whitespace for
> > documents produced will be a real mess with tabs everywhere, though it
is
> > (relatively) readable - which illustrates my point, it seems difficult
to
> > control whitespace without sacrificing readability. Both readability of
the
> > produced source-code document and of the template are important to me.
> >
> > example:
> >
> >            #if( $xpath.single( $class, "field/@default" ) )
> >            #set( $initialiserName = "initialise${classname}" )
> > void ${classname}::${initialiserName}(){
> >            #foreach( $field in $class.getChildren( "field" ) )
> >             #set( $manyAtt = xpath.single( $field, "@many" ) )
> >             ## don't worry about many's
> >             #if( !$manyAtt || !( "true".equals( $manyAtt ) ) )
> >              #set( $defaultAtt = $xpath.single( $field, "@default" ) )
> >              #if( $defaultAtt )
> >               #set( $staticAtt = $xpath.single( $field, "@static" ) )
> >               #if( "true".equals( $staticAtt ) )
> >                #if( $xpath.single( $field, "@bean|@state" )
> >  set${utils.cap( $xpath.single( $field, "@name" )} )}( ${xpath.single(
> > $field, "@default" )} );
> >                #else
> >  ${xpath.single( $field,"@name" )} = ${xpath.single(
$field,"@default" )};
> >                #end
> >               #end
> >              #end
> >             #end
> >            #end
> >
> > I have known people hack velocity to cut out any whitesapce on a line
> > directly before a velocity directive (#), which might work in my case.
> >
> > I can't hepl think though that there must be a better way.
> >
> > I was considering if it might be possible to get some control in there
which
> > would give the template functionality to allow output from the merge to
be
> > written to the writer or ignored say by something like ${vel.stop()} and
> > ${vel.go()} (by popping some piece of the running velocity class into
the
> > context)
> >
> > so you may get
> >
> > ${vel.stop}
> > #foreach( $class in $classes)
> >     #foreach( $method in $class.methods )
> >         This line will not get written out to the document
> >         ${vel.go} This line will! ${vel.stop} This one won't
> >     #end
> > #end
> >
> > which would likely approximate to something like
> >
> > This line will!
> > This line will!
> > This line will!
> >
> > Alternatively #on #off directives.
> >
> > What are peoples thoughts on this? is something like this already
available?
> > how do other people get around the whitespace nightmare, or is it just
me?
> >
> > regards
> >
> > T
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
>
> --
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
> ---
> [This E-mail has been scanned for viruses but it is your responsibility
> to maintain up to date anti virus software on the device that you are
> currently using to read this email. ]
>
>

---
[This E-mail has been scanned for viruses but it is your responsibility 
to maintain up to date anti virus software on the device that you are
currently using to read this email. ]


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to