You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@velocity.apache.org by Timothy Stone <re...@petmystone.com> on 2006/11/14 15:49:18 UTC
Whitespace output control
List,
We noticed in #parse'ing an .vm file, excess whitespace, or
linefeeds, are appearing in our templates after merge.
For example, where a '+' indicates a line feed or carriage return:
[mystyles.vm]
+
#set( $foo = "Copyright (c)")
+
#set( $bar = "2006" )
+
[myemail.txt]
#parse("mystyles.vm")
+
Dear bloated warthog,
blah
+
blah
+
blah
+
Regards,
Man in Black
+
${foo} ${bar}
[The final output]
+
+
+
+
Dear bloated warthog,
blah
+
blah
+
blah
+
Regards,
Man in Black
+
Copyright (c) 2006
Can these extra lines be managed in some way?
Thanks,
Tim
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
For additional commands, e-mail: user-help@velocity.apache.org
Re: Whitespace output control
Posted by Michael Giroux <ml...@gmail.com>.
On 3/8/07, Nathan Bubna <nb...@gmail.com> wrote:
>
> If you would like this to be remembered, i'd recommend adding it to
> the Wiki page for the whitespace issue:
>
> http://wiki.apache.org/velocity/VelocityWhitespaceGobbling
I have added a new proposal to the wiki.
Re: Whitespace output control
Posted by Nathan Bubna <nb...@gmail.com>.
This is either the first time i've heard a proposal like this, or else
those who've made such suggestions have not been persistent in them.
If you would like this to be remembered, i'd recommend adding it to
the Wiki page for the whitespace issue:
http://wiki.apache.org/velocity/VelocityWhitespaceGobbling
And as with all the proposals, i've long suspected that patches are
likely to be the deciding factor. I don't think anyone has so far
produced patches to support their choice (though Christoph may once
upon a time have produced a parser grammar or something like that).
And, as things stand, the consensus seems to be that none of the
proposals are likely to be implemented before Velocity 2.0, due to
concerns over backwards compatibility.
That's not to say, of course, that it is impossible to implement one
of these in a way that is backwards compatible. It just means that no
one has done it.
On 3/8/07, Michael Giroux <ml...@gmail.com> wrote:
> I've been reviewing the various discussions on whitespace. I was not able
> to determine if the current proposals cover my thoughts or not, so sorry if
> what follows has been covered already.
>
> For the most part, I want my templates to be readable and I use indenting to
> accomplish that.
>
> My template might appear as follows:
>
> import com.myco.MyClass;
> public Class AnotherClass {
> #foreach ($t in $types)
> #if ($t.name.contains("_")
> Integer $t.name = 0;
> #if ($t.type == "static")
> // ignore static type $t.name
> #end
> #end
> #end
> }
>
> This should produce something like:
> import com.myco.MyClass;
> public Class AnotherClass {
> Integer v_1 = 0;
> Integer v_2 = 0;
> // ignore static type s_0
> }
>
> Given that each line of the nested blocks within template is indented
> further, there would need to be some marker in the template to indicate
> where indentation should be set for subsequent lines.
>
> import com.myco.MyClass;
> public Class AnotherClass {
> #setindent ## a new setindent directive
> #foreach ($t in $types)
> #if ($t.name.contains("_")
> Integer $t.name = 0;
> #if ($t.type == "static")
> // ignore static type $t.name
> #end
> #end
> #end
> }
>
> In this example, (there are probably better ways) a #setindent directive
> would specify the starting location for all subsequent lines. Velocity
> would use the whitespace before the #setindent directive as the amount to
> indent any text that is emitted. In this case, all leading whitespace would
> be ignored, and indentation would be controlled by the #setIndent
> directives.
>
> As I said, if this has been covered already, I'm sorry for the duplicate.
>
> Michael
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
For additional commands, e-mail: user-help@velocity.apache.org
Re: Whitespace output control
Posted by Robert Koberg <ro...@koberg.com>.
On Fri, 09 Mar 2007 11:47:04 -0500, <ap...@recks.org> wrote:
> Hi,
>
> Michael Giroux wrote:
>> On 3/9/07, apache@recks.org <ap...@recks.org> wrote:
>>
>>> Anyhow with the proposed VelocityWhitespaceGobbleStructuredTemplates
>>> you could achieve your desired output with either:
>>>
>>> import com.myco.MyClass;
>>> public Class AnotherClass {
>>> #foreach( $t in $types )
>>> #if( $t.name.contains("_") )
>>> #text( " Integer $t.name = 0;" )
>>> #if( $t.type == "static" )
>>> #text( " // ignore static type $t.name" )
>>> #end
>>> #end
>>> #end
>>> }
>>
>> But this requires that all output is encapsulated in #text() which
>> pretty
>> much eliminates the ability to copy/past text from other sources such as
>> working java programs.
>
> Yes and no - you can intermix the above with the below; thus
> leaving your source lines untouched!
BTW, this is basically how XSL does it.
-Rob
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
For additional commands, e-mail: user-help@velocity.apache.org
Re: Whitespace output control
Posted by ap...@recks.org.
Hi,
Michael Giroux wrote:
> On 3/9/07, apache@recks.org <ap...@recks.org> wrote:
>
>> Anyhow with the proposed VelocityWhitespaceGobbleStructuredTemplates
>> you could achieve your desired output with either:
>>
>> import com.myco.MyClass;
>> public Class AnotherClass {
>> #foreach( $t in $types )
>> #if( $t.name.contains("_") )
>> #text( " Integer $t.name = 0;" )
>> #if( $t.type == "static" )
>> #text( " // ignore static type $t.name" )
>> #end
>> #end
>> #end
>> }
>
> But this requires that all output is encapsulated in #text() which pretty
> much eliminates the ability to copy/past text from other sources such as
> working java programs.
Yes and no - you can intermix the above with the below; thus
leaving your source lines untouched!
>
>> or embedding the directives with a alternate indentation level to
>> optically make it stand out from the schmoo:
>>
>> import com.myco.MyClass;
>> public Class AnotherClass {
>> #foreach( $t in $types )
>> #if( $t.name.contains("_") )
>> Integer $t.name = 0;
>> #if ($t.type == "static")
>> // ignore static type $t.name
>> #end
>> #end
>> #end
>> }
>
>
> This obscures the indenting of the template, making it difficult to
> maintain, at least for those of us who work better with nicely formatted
> files.
>
The "#"-syntax makes it easy for the eye to locate the directives. And
achived your "nicely formatted files" goal just the same
>
>> Your #setindent directive example would be hard for a parser to understand.
>> More standard would be #setindent(" ").
>
>
>
> Or perhaps #setindent(4) ## numeric value indicates amount of indent which
> allows something like
> #set ($indent = $indent +4)
> #setindent($indent)
>
The updated wiki page with #setindent([+-]<number>) syntax is much better!
>
>
>> But creating complex Java code
>> with many indented blocks would clutter the template with these directives
>> and not contribute to readability compared to the two above example approaches.
>> I would therefore vote against the proposal of the *SetindentDirective, which
>> could be also done using:
>> a) code formatter as Jalopy
>
>
> The same argument can be made for XML and HTML files, so why are we
> discussing whitespace at all? What about the case where the template is
> generating sample Java code to be included in a <code>...</code> block
> in an
> HTML document to be sent to a browser. There is no chance to run this
> through Jalopy.
;) I stated my previous post with "for one-time generated thingies ..."
I the case of good looking (managable) templates and dynamically generated
well structured output we need better whitespace handling and support.
>
> We currently use both Jalopy and/or the Eclipse JDT code formatter to
> reformat files that are generated for application code, but these have
> problems from time to time and Jalopy aborts without formatting. It is
> easier to view the generated file if it has some reasonable indentation.
>
>
>
>> b) the the VelocityWhitespaceGobbleAll and an custom #setindent()
>> directive
>> working together with a modified FileWriter
>
>
>
> When you say "custom #setindent()" does this say that it is not a standard
> part of Velocity? I think this should be standard.
It is quite easy to add custom directives per configuration...
>
>> Currently I use the ugly workaround in my macros:
>>
>> #macro( ClassMacro $indent $name $types )
>> ${indent}public Class $name {
>> #**#foreach( $t in $types )##
>> #* *#if( $t.name.contains("_") )##
>> ${indent} Integer $t.name = 0;
>> #* *#if ($t.type == "static")##
>> ${indent} // ignore static type $t.name
>> #* *#end##
>> #* *#end##
>> #**#end##
>> ${indent}}
>
>
> As you say, "ugly". Hopefully VelocityWhitespaceGobbleAll would eliminate
> the nead for the velocity comments #* *# at beginning of every line. It
> would be nice if these tricks were not needed, but the ${indent} would be
> tolerable if all the leading whitespace could be discarded and there was an
> easy way to populate $indent with desired number of blanks.
>
> import com.myco.MyClass;
> public Class AnotherClass {
> $set ($indent = $leadingBlanks.substring(0,$indentAmount))
> #foreach( $t in $types )
> #if( $t.name.contains("_") )
> ${indent} Integer $t.name = 0;
> #if ($t.type == "static")
> ${indent} // ignore static type $t.name
> #end
> #end
> #end
> }
>
> I think this might be equivalent to your suggestion to combine
> VelocityWhitespaceGobbleAll with a new #setindent(amount) directive.
> If Velocity is discarding all leading whitespace, and then injecting the
> amount specified by #setindent() a lot of the formatting issue would e resolved
> and in a lot of cases there would be no need for post processing the generated
> output.
Exaclty, but then you are near to my example with the #text(...) thingies ;)
That is why I suggested to combine this with a custom FileWriter that does this!
>
> Michael
>
You can see the reason for all of the proposed patters:
a) VelocityWhitespaceGobbleAsUsual
b) VelocityWhitespaceGobbleAll
c) VelocityWhitespaceGobbleNone
d) VelocityWhitespaceGobbleStructuredTemplates
Yours can be painlessly achieved with b) plus #setindent(...) and a FileWriter
fitting perfectly your application. OTOH d) would also do the job ;)
Cheers,
Christoph
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
For additional commands, e-mail: user-help@velocity.apache.org
Re: Whitespace output control
Posted by Michael Giroux <ml...@gmail.com>.
On 3/9/07, apache@recks.org <ap...@recks.org> wrote:
> Anyhow with the proposed VelocityWhitespaceGobbleStructuredTemplates
> you could achieve your desired output with either:
>
> import com.myco.MyClass;
> public Class AnotherClass {
> #foreach( $t in $types )
> #if( $t.name.contains("_") )
> #text( " Integer $t.name = 0;" )
> #if( $t.type == "static" )
> #text( " // ignore static type $t.name" )
> #end
> #end
> #end
> }
But this requires that all output is encapsulated in #text() which pretty
much eliminates the ability to copy/past text from other sources such as
working java programs.
> or embedding the directives with a alternate indentation level to
> optically make it stand out from the schmoo:
>
> import com.myco.MyClass;
> public Class AnotherClass {
> #foreach( $t in $types )
> #if( $t.name.contains("_") )
> Integer $t.name = 0;
> #if ($t.type == "static")
> // ignore static type $t.name
> #end
> #end
> #end
> }
This obscures the indenting of the template, making it difficult to
maintain, at least for those of us who work better with nicely formatted
files.
> Your #setindent directive example would be hard for a parser to
> understand.
> More standard would be #setindent(" ").
Or perhaps #setindent(4) ## numeric value indicates amount of indent which
allows something like
#set ($indent = $indent +4)
#setindent($indent)
> But creating complex Java code
> with many indented blocks would clutter the template with these directives
> and not contribute to readability compared to the two above example
> approaches.
> I would therefore vote against the proposal of the *SetindentDirective,
> which
> could be also done using:
> a) code formatter as Jalopy
The same argument can be made for XML and HTML files, so why are we
discussing whitespace at all? What about the case where the template is
generating sample Java code to be included in a <code>...</code> block in an
HTML document to be sent to a browser. There is no chance to run this
through Jalopy.
We currently use both Jalopy and/or the Eclipse JDT code formatter to
reformat files that are generated for application code, but these have
problems from time to time and Jalopy aborts without formatting. It is
easier to view the generated file if it has some reasonable indentation.
> b) the the VelocityWhitespaceGobbleAll and an custom #setindent()
> directive
> working together with a modified FileWriter
When you say "custom #setindent()" does this say that it is not a standard
part of Velocity? I think this should be standard.
> Currently I use the ugly workaround in my macros:
>
> #macro( ClassMacro $indent $name $types )
> ${indent}public Class $name {
> #**#foreach( $t in $types )##
> #* *#if( $t.name.contains("_") )##
> ${indent} Integer $t.name = 0;
> #* *#if ($t.type == "static")##
> ${indent} // ignore static type $t.name
> #* *#end##
> #* *#end##
> #**#end##
> ${indent}}
As you say, "ugly". Hopefully VelocityWhitespaceGobbleAll would eliminate
the nead for the velocity comments #* *# at beginning of every line. It
would be nice if these tricks were not needed, but the ${indent} would be
tolerable if all the leading whitespace could be discarded and there was an
easy way to populate $indent with desired number of blanks.
import com.myco.MyClass;
public Class AnotherClass {
$set ($indent = $leadingBlanks.substring(0,$indentAmount))
#foreach( $t in $types )
#if( $t.name.contains("_") )
${indent} Integer $t.name = 0;
#if ($t.type == "static")
${indent} // ignore static type $t.name
#end
#end
#end
}
I think this might be equivalent to your suggestion to combine
VelocityWhitespaceGobbleAll with a new #setindent(amount) directive. If
Velocity is discarding all leading whitespace, and then injecting the amount
specified by #setindent() a lot of the formatting issue would e resolved and
in a lot of cases there would be no need for post processing the generated
output.
Michael
Re: Whitespace output control
Posted by ap...@recks.org.
for one-time generated thingies like HTML or Java classes, you
can easily post-process the Velocity output with a code formatter.
Anyhow with the proposed VelocityWhitespaceGobbleStructuredTemplates
you could achieve your desired output with either:
import com.myco.MyClass;
public Class AnotherClass {
#foreach( $t in $types )
#if( $t.name.contains("_") )
#text( " Integer $t.name = 0;" )
#if( $t.type == "static" )
#text( " // ignore static type $t.name" )
#end
#end
#end
}
or embedding the directives with a alternate indentation level to
optically make it stand out from the schmoo:
import com.myco.MyClass;
public Class AnotherClass {
#foreach( $t in $types )
#if( $t.name.contains("_") )
Integer $t.name = 0;
#if ($t.type == "static")
// ignore static type $t.name
#end
#end
#end
}
Your #setindent directive example would be hard for a parser to understand.
More standard would be #setindent(" "). But creating complex Java code
with many indented blocks would clutter the template with these directives
and not contribute to readability compared to the two above example approaches.
I would therefore vote against the proposal of the *SetindentDirective, which
could be also done using:
a) code formatter as Jalopy
b) the the VelocityWhitespaceGobbleAll and an custom #setindent() directive
working together with a modified FileWriter
Currently I use the ugly workaround in my macros:
#macro( ClassMacro $indent $name $types )
${indent}public Class $name {
#**#foreach( $t in $types )##
#* *#if( $t.name.contains("_") )##
${indent} Integer $t.name = 0;
#* *#if ($t.type == "static")##
${indent} // ignore static type $t.name
#* *#end##
#* *#end##
#**#end##
${indent}}
Just my 2c...
:) Christoph
Michael Giroux wrote:
> I've been reviewing the various discussions on whitespace. I was not able
> to determine if the current proposals cover my thoughts or not, so sorry if
> what follows has been covered already.
>
> For the most part, I want my templates to be readable and I use
> indenting to
> accomplish that.
>
> My template might appear as follows:
>
> import com.myco.MyClass;
> public Class AnotherClass {
> #foreach ($t in $types)
> #if ($t.name.contains("_")
> Integer $t.name = 0;
> #if ($t.type == "static")
> // ignore static type $t.name
> #end
> #end
> #end
> }
>
> This should produce something like:
> import com.myco.MyClass;
> public Class AnotherClass {
> Integer v_1 = 0;
> Integer v_2 = 0;
> // ignore static type s_0
> }
>
> Given that each line of the nested blocks within template is indented
> further, there would need to be some marker in the template to indicate
> where indentation should be set for subsequent lines.
>
> import com.myco.MyClass;
> public Class AnotherClass {
> #setindent ## a new setindent directive
> #foreach ($t in $types)
> #if ($t.name.contains("_")
> Integer $t.name = 0;
> #if ($t.type == "static")
> // ignore static type $t.name
> #end
> #end
> #end
> }
>
> In this example, (there are probably better ways) a #setindent directive
> would specify the starting location for all subsequent lines. Velocity
> would use the whitespace before the #setindent directive as the amount to
> indent any text that is emitted. In this case, all leading whitespace
> would
> be ignored, and indentation would be controlled by the #setIndent
> directives.
>
> As I said, if this has been covered already, I'm sorry for the duplicate.
>
> Michael
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
For additional commands, e-mail: user-help@velocity.apache.org
Re: Whitespace output control
Posted by Michael Giroux <ml...@gmail.com>.
I've been reviewing the various discussions on whitespace. I was not able
to determine if the current proposals cover my thoughts or not, so sorry if
what follows has been covered already.
For the most part, I want my templates to be readable and I use indenting to
accomplish that.
My template might appear as follows:
import com.myco.MyClass;
public Class AnotherClass {
#foreach ($t in $types)
#if ($t.name.contains("_")
Integer $t.name = 0;
#if ($t.type == "static")
// ignore static type $t.name
#end
#end
#end
}
This should produce something like:
import com.myco.MyClass;
public Class AnotherClass {
Integer v_1 = 0;
Integer v_2 = 0;
// ignore static type s_0
}
Given that each line of the nested blocks within template is indented
further, there would need to be some marker in the template to indicate
where indentation should be set for subsequent lines.
import com.myco.MyClass;
public Class AnotherClass {
#setindent ## a new setindent directive
#foreach ($t in $types)
#if ($t.name.contains("_")
Integer $t.name = 0;
#if ($t.type == "static")
// ignore static type $t.name
#end
#end
#end
}
In this example, (there are probably better ways) a #setindent directive
would specify the starting location for all subsequent lines. Velocity
would use the whitespace before the #setindent directive as the amount to
indent any text that is emitted. In this case, all leading whitespace would
be ignored, and indentation would be controlled by the #setIndent
directives.
As I said, if this has been covered already, I'm sorry for the duplicate.
Michael
Re: Whitespace output control
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
apache@recks.org writes:
+1 on cleaning up the parser.
Best regards
Henning
>Hi,
>For now you can use "#*[ \t]*\n?[ \t]**#" and "##\n" constructs
>to mask out whitespace.
>The whitespace gobbling re-engineering should happen in a later
>version. My Idea would be to cleanup the parser and let it not
>gobble any whitespace, but place them in special whitespace
>AST nodes. Then we could have pluggable AST post processing
>functions:
> - current way
> - do the right thing (tm)
> - NOP
>:) Christoph
>Will Glass-Husain wrote:
>> Hi Marc,
>>
>> Thanks for the input. There seems to be widespread dissatisfaction
>> with the status quo on this issue, yet it's a tricky issue to change
>> while maintaining backwards compatibility (involves fundamental
>> changes to the parser). Currently thinking about this as part of some
>> future 2.0 version.
>>
>> Incidentally, the best solution for leaving out extra newlines is to
>> put "##" at the end of each line. This kills the newline. Doesn't
>> help the issue of extra spaces before indented statements, though.
>>
>> WILL
>>
>> On 11/21/06, Marc Novakowski <ma...@pandora.com> wrote:
>>> I've been meaning to add my vote to this page, so I finally did it.
>>> +1 for gobbling structured templates.
>>>
>>> We use velocity for most of the "backstage" area at Pandora. It's
>>> made development so much easier! However, the final HTML looks quite
>>> messy due to all of the extra whitespace introduced by the velocity
>>> templates.
>>>
>>> Marc
>>>
>>> On 14-Nov-06, at 8:18 AM, apache@recks.org wrote:
>>>
>>> > See the Wiki on this issue:
>>> > http://wiki.apache.org/jakarta-velocity/VelocityWhitespaceGobbling
>>> >
>>> > Please add your opinion (well thought out) or vote for one of the
>>> > presented approaches.
>>> >
>>> > Cheers,
>>> > Christoph
>>> >
>>> > Paul Loy wrote:
>>> >> I would be very interested in a solution to this problem. From a code
>>> >> layout point of view this would be an important feature. Consider:
>>> >>
>>> >> <div>
>>> >> "
>>> >>
>>> >> #if ($somevar)
>>> >> $somevar
>>> >> #else
>>> >> nothing here
>>> >> #end
>>> >>
>>> >> "
>>> >> </div>
>>> >>
>>> >> This nicely formatted code makes it easy to see what's going on
>>> >> but will
>>> >> make the html render with spaces in it like so (if $somevar is
>>> >> false or
>>> >> null):
>>> >>
>>> >> ' nothing here '
>>> >>
>>> >> Now this is a silly example and in this case it would be much
>>> >> easier to
>>> >> simply do this to eliminate the problem:
>>> >>
>>> >>
>>> >> <div>
>>> >>
>>> >> #if ($somevar)
>>> >> "$somevar"
>>> >> #else
>>> >> "nothing here"
>>> >> #end
>>> >>
>>> >> </div>
>>> >>
>>> >> but in more complex examples you'd either have a great amount of
>>> >> duplicated HTML, which makes it bad to maintain and update, or you'd
>>> >> have to make unreadable code (everything on one line with no white
>>> >> spaces).
>>> >>
>>> >> I converted an old nasty taglibbed jsp into velocity and although I
>>> >> cleaned up the html (removing 20+ unnecessary nested tables) the
>>> >> filesize of the velocity version was actually slightly bigger than
>>> >> the
>>> >> old version because of all the whitespace.
>>> >>
>>> >> So... I would very much like velocity to perhaps remove whitespace
>>> >> between a directive (i.e. a # statement) and any other code.
>>> >>
>>> >> Paul.
>>> >>
>>> >> Timothy Stone wrote:
>>> >>> List,
>>> >>>
>>> >>> We noticed in #parse'ing an .vm file, excess whitespace, or
>>> >>> linefeeds,
>>> >>> are appearing in our templates after merge.
>>> >>>
>>> >>> For example, where a '+' indicates a line feed or carriage return:
>>> >>>
>>> >>> [mystyles.vm]
>>> >>> +
>>> >>> #set( $foo = "Copyright (c)")
>>> >>> +
>>> >>> #set( $bar = "2006" )
>>> >>> +
>>> >>>
>>> >>>
>>> >>> [myemail.txt]
>>> >>> #parse("mystyles.vm")
>>> >>> +
>>> >>> Dear bloated warthog,
>>> >>> blah
>>> >>> +
>>> >>> blah
>>> >>> +
>>> >>> blah
>>> >>> +
>>> >>> Regards,
>>> >>> Man in Black
>>> >>> +
>>> >>> ${foo} ${bar}
>>> >>>
>>> >>> [The final output]
>>> >>> +
>>> >>> +
>>> >>> +
>>> >>> +
>>> >>> Dear bloated warthog,
>>> >>> blah
>>> >>> +
>>> >>> blah
>>> >>> +
>>> >>> blah
>>> >>> +
>>> >>> Regards,
>>> >>> Man in Black
>>> >>> +
>>> >>> Copyright (c) 2006
>>> >>>
>>> >>> Can these extra lines be managed in some way?
>>> >>>
>>> >>> Thanks,
>>> >>> Tim
>>> >>>
>>> >>>
>>> >>>
>>> >>> --------------------------------------------------------------------
>>> >>> -
>>> >>> To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
>>> >>> For additional commands, e-mail: user-help@velocity.apache.org
>>> >>>
>>> >>
>>> >>
>>> >
>>> > ---------------------------------------------------------------------
>>> > To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
>>> > For additional commands, e-mail: user-help@velocity.apache.org
>>> >
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
>>> For additional commands, e-mail: user-help@velocity.apache.org
>>>
>>>
>>
>>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
>For additional commands, e-mail: user-help@velocity.apache.org
--
Henning P. Schmiedehausen -- hps@intermeta.de | J2EE, Linux,
91054 Buckenhof, Germany -- +49 9131 506540 | Apache person
Open Source Consulting, Development, Design | Velocity - Turbine guy
"Save the cheerleader. Save the world."
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
For additional commands, e-mail: user-help@velocity.apache.org
Re: Whitespace output control
Posted by Will Glass-Husain <wg...@forio.com>.
"powers that be"?
anyway, we know it. just can't change it in the current version track
or lots and lots of peoples templates will change unexpectedly. we'll
do a less backwards compatible change in the future and bring this in.
WILL
On 11/22/06, apache@recks.org <ap...@recks.org> wrote:
> Hi,
>
> For now you can use "#*[ \t]*\n?[ \t]**#" and "##\n" constructs
> to mask out whitespace.
>
> The whitespace gobbling re-engineering should happen in a later
> version. My Idea would be to cleanup the parser and let it not
> gobble any whitespace, but place them in special whitespace
> AST nodes. Then we could have pluggable AST post processing
> functions:
> - current way
> - do the right thing (tm)
> - NOP
>
> :) Christoph
>
> Will Glass-Husain wrote:
> > Hi Marc,
> >
> > Thanks for the input. There seems to be widespread dissatisfaction
> > with the status quo on this issue, yet it's a tricky issue to change
> > while maintaining backwards compatibility (involves fundamental
> > changes to the parser). Currently thinking about this as part of some
> > future 2.0 version.
> >
> > Incidentally, the best solution for leaving out extra newlines is to
> > put "##" at the end of each line. This kills the newline. Doesn't
> > help the issue of extra spaces before indented statements, though.
> >
> > WILL
> >
> > On 11/21/06, Marc Novakowski <ma...@pandora.com> wrote:
> >> I've been meaning to add my vote to this page, so I finally did it.
> >> +1 for gobbling structured templates.
> >>
> >> We use velocity for most of the "backstage" area at Pandora. It's
> >> made development so much easier! However, the final HTML looks quite
> >> messy due to all of the extra whitespace introduced by the velocity
> >> templates.
> >>
> >> Marc
> >>
> >> On 14-Nov-06, at 8:18 AM, apache@recks.org wrote:
> >>
> >> > See the Wiki on this issue:
> >> > http://wiki.apache.org/jakarta-velocity/VelocityWhitespaceGobbling
> >> >
> >> > Please add your opinion (well thought out) or vote for one of the
> >> > presented approaches.
> >> >
> >> > Cheers,
> >> > Christoph
> >> >
> >> > Paul Loy wrote:
> >> >> I would be very interested in a solution to this problem. From a code
> >> >> layout point of view this would be an important feature. Consider:
> >> >>
> >> >> <div>
> >> >> "
> >> >>
> >> >> #if ($somevar)
> >> >> $somevar
> >> >> #else
> >> >> nothing here
> >> >> #end
> >> >>
> >> >> "
> >> >> </div>
> >> >>
> >> >> This nicely formatted code makes it easy to see what's going on
> >> >> but will
> >> >> make the html render with spaces in it like so (if $somevar is
> >> >> false or
> >> >> null):
> >> >>
> >> >> ' nothing here '
> >> >>
> >> >> Now this is a silly example and in this case it would be much
> >> >> easier to
> >> >> simply do this to eliminate the problem:
> >> >>
> >> >>
> >> >> <div>
> >> >>
> >> >> #if ($somevar)
> >> >> "$somevar"
> >> >> #else
> >> >> "nothing here"
> >> >> #end
> >> >>
> >> >> </div>
> >> >>
> >> >> but in more complex examples you'd either have a great amount of
> >> >> duplicated HTML, which makes it bad to maintain and update, or you'd
> >> >> have to make unreadable code (everything on one line with no white
> >> >> spaces).
> >> >>
> >> >> I converted an old nasty taglibbed jsp into velocity and although I
> >> >> cleaned up the html (removing 20+ unnecessary nested tables) the
> >> >> filesize of the velocity version was actually slightly bigger than
> >> >> the
> >> >> old version because of all the whitespace.
> >> >>
> >> >> So... I would very much like velocity to perhaps remove whitespace
> >> >> between a directive (i.e. a # statement) and any other code.
> >> >>
> >> >> Paul.
> >> >>
> >> >> Timothy Stone wrote:
> >> >>> List,
> >> >>>
> >> >>> We noticed in #parse'ing an .vm file, excess whitespace, or
> >> >>> linefeeds,
> >> >>> are appearing in our templates after merge.
> >> >>>
> >> >>> For example, where a '+' indicates a line feed or carriage return:
> >> >>>
> >> >>> [mystyles.vm]
> >> >>> +
> >> >>> #set( $foo = "Copyright (c)")
> >> >>> +
> >> >>> #set( $bar = "2006" )
> >> >>> +
> >> >>>
> >> >>>
> >> >>> [myemail.txt]
> >> >>> #parse("mystyles.vm")
> >> >>> +
> >> >>> Dear bloated warthog,
> >> >>> blah
> >> >>> +
> >> >>> blah
> >> >>> +
> >> >>> blah
> >> >>> +
> >> >>> Regards,
> >> >>> Man in Black
> >> >>> +
> >> >>> ${foo} ${bar}
> >> >>>
> >> >>> [The final output]
> >> >>> +
> >> >>> +
> >> >>> +
> >> >>> +
> >> >>> Dear bloated warthog,
> >> >>> blah
> >> >>> +
> >> >>> blah
> >> >>> +
> >> >>> blah
> >> >>> +
> >> >>> Regards,
> >> >>> Man in Black
> >> >>> +
> >> >>> Copyright (c) 2006
> >> >>>
> >> >>> Can these extra lines be managed in some way?
> >> >>>
> >> >>> Thanks,
> >> >>> Tim
> >> >>>
> >> >>>
> >> >>>
> >> >>> --------------------------------------------------------------------
> >> >>> -
> >> >>> To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
> >> >>> For additional commands, e-mail: user-help@velocity.apache.org
> >> >>>
> >> >>
> >> >>
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
> >> > For additional commands, e-mail: user-help@velocity.apache.org
> >> >
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
> >> For additional commands, e-mail: user-help@velocity.apache.org
> >>
> >>
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
> For additional commands, e-mail: user-help@velocity.apache.org
>
>
--
Forio Business Simulations
Will Glass-Husain
wglass@forio.com
www.forio.com
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
For additional commands, e-mail: user-help@velocity.apache.org
Re: Whitespace output control
Posted by ap...@recks.org.
Hi,
For now you can use "#*[ \t]*\n?[ \t]**#" and "##\n" constructs
to mask out whitespace.
The whitespace gobbling re-engineering should happen in a later
version. My Idea would be to cleanup the parser and let it not
gobble any whitespace, but place them in special whitespace
AST nodes. Then we could have pluggable AST post processing
functions:
- current way
- do the right thing (tm)
- NOP
:) Christoph
Will Glass-Husain wrote:
> Hi Marc,
>
> Thanks for the input. There seems to be widespread dissatisfaction
> with the status quo on this issue, yet it's a tricky issue to change
> while maintaining backwards compatibility (involves fundamental
> changes to the parser). Currently thinking about this as part of some
> future 2.0 version.
>
> Incidentally, the best solution for leaving out extra newlines is to
> put "##" at the end of each line. This kills the newline. Doesn't
> help the issue of extra spaces before indented statements, though.
>
> WILL
>
> On 11/21/06, Marc Novakowski <ma...@pandora.com> wrote:
>> I've been meaning to add my vote to this page, so I finally did it.
>> +1 for gobbling structured templates.
>>
>> We use velocity for most of the "backstage" area at Pandora. It's
>> made development so much easier! However, the final HTML looks quite
>> messy due to all of the extra whitespace introduced by the velocity
>> templates.
>>
>> Marc
>>
>> On 14-Nov-06, at 8:18 AM, apache@recks.org wrote:
>>
>> > See the Wiki on this issue:
>> > http://wiki.apache.org/jakarta-velocity/VelocityWhitespaceGobbling
>> >
>> > Please add your opinion (well thought out) or vote for one of the
>> > presented approaches.
>> >
>> > Cheers,
>> > Christoph
>> >
>> > Paul Loy wrote:
>> >> I would be very interested in a solution to this problem. From a code
>> >> layout point of view this would be an important feature. Consider:
>> >>
>> >> <div>
>> >> "
>> >>
>> >> #if ($somevar)
>> >> $somevar
>> >> #else
>> >> nothing here
>> >> #end
>> >>
>> >> "
>> >> </div>
>> >>
>> >> This nicely formatted code makes it easy to see what's going on
>> >> but will
>> >> make the html render with spaces in it like so (if $somevar is
>> >> false or
>> >> null):
>> >>
>> >> ' nothing here '
>> >>
>> >> Now this is a silly example and in this case it would be much
>> >> easier to
>> >> simply do this to eliminate the problem:
>> >>
>> >>
>> >> <div>
>> >>
>> >> #if ($somevar)
>> >> "$somevar"
>> >> #else
>> >> "nothing here"
>> >> #end
>> >>
>> >> </div>
>> >>
>> >> but in more complex examples you'd either have a great amount of
>> >> duplicated HTML, which makes it bad to maintain and update, or you'd
>> >> have to make unreadable code (everything on one line with no white
>> >> spaces).
>> >>
>> >> I converted an old nasty taglibbed jsp into velocity and although I
>> >> cleaned up the html (removing 20+ unnecessary nested tables) the
>> >> filesize of the velocity version was actually slightly bigger than
>> >> the
>> >> old version because of all the whitespace.
>> >>
>> >> So... I would very much like velocity to perhaps remove whitespace
>> >> between a directive (i.e. a # statement) and any other code.
>> >>
>> >> Paul.
>> >>
>> >> Timothy Stone wrote:
>> >>> List,
>> >>>
>> >>> We noticed in #parse'ing an .vm file, excess whitespace, or
>> >>> linefeeds,
>> >>> are appearing in our templates after merge.
>> >>>
>> >>> For example, where a '+' indicates a line feed or carriage return:
>> >>>
>> >>> [mystyles.vm]
>> >>> +
>> >>> #set( $foo = "Copyright (c)")
>> >>> +
>> >>> #set( $bar = "2006" )
>> >>> +
>> >>>
>> >>>
>> >>> [myemail.txt]
>> >>> #parse("mystyles.vm")
>> >>> +
>> >>> Dear bloated warthog,
>> >>> blah
>> >>> +
>> >>> blah
>> >>> +
>> >>> blah
>> >>> +
>> >>> Regards,
>> >>> Man in Black
>> >>> +
>> >>> ${foo} ${bar}
>> >>>
>> >>> [The final output]
>> >>> +
>> >>> +
>> >>> +
>> >>> +
>> >>> Dear bloated warthog,
>> >>> blah
>> >>> +
>> >>> blah
>> >>> +
>> >>> blah
>> >>> +
>> >>> Regards,
>> >>> Man in Black
>> >>> +
>> >>> Copyright (c) 2006
>> >>>
>> >>> Can these extra lines be managed in some way?
>> >>>
>> >>> Thanks,
>> >>> Tim
>> >>>
>> >>>
>> >>>
>> >>> --------------------------------------------------------------------
>> >>> -
>> >>> To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
>> >>> For additional commands, e-mail: user-help@velocity.apache.org
>> >>>
>> >>
>> >>
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
>> > For additional commands, e-mail: user-help@velocity.apache.org
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
>> For additional commands, e-mail: user-help@velocity.apache.org
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
For additional commands, e-mail: user-help@velocity.apache.org
Re: Whitespace output control
Posted by Paul Loy <pa...@peoplesarchive.com>.
>
> In (my) ideal world, the following:
>
Mine too!
--
*Paul Loy
Software Developer*
Peoples Archive Ltd.
Middlesex House
34-42 Cleveland Street
London, W1T 4LB
Tel: +44 (0) 20 7323 0323
Fax: +44 (0) 20 7580 1938
paul.loy@peoplesarchive.com
http://www.peoplesarchive.com
Re: Whitespace output control
Posted by Will Glass-Husain <wg...@forio.com>.
Seems like a useful approach. Thanks for sharing.
WILL
On 12/18/06, James Wilson <Ja...@nmcourt.fed.us> wrote:
> Marc Novakowski wrote:
> > Yeah, we use the ## trick in a few macros where removal of whitespace is
> > critical. In most templates, extra whitespace isn't a big deal since,
> > in the end, it's all gobbled into a single whitespace character by the
> > HTML parser. It's just when you look at the HTML source, it's ugly!
> >
> > Also, the "##" trick only works to remove newlines, but the indentation
> > whitespace (i.e. tabs or spaces) before the velocity statement on the
> > line will still be there.
> >
> > In (my) ideal world, the following:
> >
> > <table>
> > <tr>
> > #if ($foo == "bar")
> > <td>Fred</td>
> > #else
> > <td>Bob</td>
> > #end
> > </tr>
> > </table>
> >
> >
> > Would result in:
> >
> > <table>
> > <tr>
> > <td>Fred</td>
> > </tr>
> > </table>
>
> But what is wrong with just providing a custom filter writer to the mergeTemplate
> method? It seems to me that you can create any whitespace policy you want this way.
> Or better yet -- a chained filter writer. One that deals with spaces and maybe another
> that deals with eols. I put an example of this on this list a long time ago -- here
> it is again. These writers can be greatly improved but they worked for us.
>
> James
>
> > Marc
> >
> >
> > On 21-Nov-06, at 9:56 AM, Will Glass-Husain wrote:
> >
> >> Hi Marc,
> >>
> >> Thanks for the input. There seems to be widespread dissatisfaction
> >> with the status quo on this issue, yet it's a tricky issue to change
> >> while maintaining backwards compatibility (involves fundamental
> >> changes to the parser). Currently thinking about this as part of some
> >> future 2.0 version.
> >>
> >> Incidentally, the best solution for leaving out extra newlines is to
> >> put "##" at the end of each line. This kills the newline. Doesn't
> >> help the issue of extra spaces before indented statements, though.
> >>
> >> WILL
> >>
> >> On 11/21/06, Marc Novakowski <ma...@pandora.com> wrote:
> >>> I've been meaning to add my vote to this page, so I finally did it.
> >>> +1 for gobbling structured templates.
> >>>
> >>> We use velocity for most of the "backstage" area at Pandora. It's
> >>> made development so much easier! However, the final HTML looks quite
> >>> messy due to all of the extra whitespace introduced by the velocity
> >>> templates.
> >>>
> >>> Marc
> >>>
> >>> On 14-Nov-06, at 8:18 AM, apache@recks.org wrote:
> >>>
> >>> > See the Wiki on this issue:
> >>> > http://wiki.apache.org/jakarta-velocity/VelocityWhitespaceGobbling
> >>> >
> >>> > Please add your opinion (well thought out) or vote for one of the
> >>> > presented approaches.
> >>> >
> >>> > Cheers,
> >>> > Christoph
> >>> >
> >>> > Paul Loy wrote:
> >>> >> I would be very interested in a solution to this problem. From a code
> >>> >> layout point of view this would be an important feature. Consider:
> >>> >>
> >>> >> <div>
> >>> >> "
> >>> >>
> >>> >> #if ($somevar)
> >>> >> $somevar
> >>> >> #else
> >>> >> nothing here
> >>> >> #end
> >>> >>
> >>> >> "
> >>> >> </div>
> >>> >>
> >>> >> This nicely formatted code makes it easy to see what's going on
> >>> >> but will
> >>> >> make the html render with spaces in it like so (if $somevar is
> >>> >> false or
> >>> >> null):
> >>> >>
> >>> >> ' nothing here '
> >>> >>
> >>> >> Now this is a silly example and in this case it would be much
> >>> >> easier to
> >>> >> simply do this to eliminate the problem:
> >>> >>
> >>> >>
> >>> >> <div>
> >>> >>
> >>> >> #if ($somevar)
> >>> >> "$somevar"
> >>> >> #else
> >>> >> "nothing here"
> >>> >> #end
> >>> >>
> >>> >> </div>
> >>> >>
> >>> >> but in more complex examples you'd either have a great amount of
> >>> >> duplicated HTML, which makes it bad to maintain and update, or you'd
> >>> >> have to make unreadable code (everything on one line with no white
> >>> >> spaces).
> >>> >>
> >>> >> I converted an old nasty taglibbed jsp into velocity and although I
> >>> >> cleaned up the html (removing 20+ unnecessary nested tables) the
> >>> >> filesize of the velocity version was actually slightly bigger than
> >>> >> the
> >>> >> old version because of all the whitespace.
> >>> >>
> >>> >> So... I would very much like velocity to perhaps remove whitespace
> >>> >> between a directive (i.e. a # statement) and any other code.
> >>> >>
> >>> >> Paul.
> >>> >>
> >>> >> Timothy Stone wrote:
> >>> >>> List,
> >>> >>>
> >>> >>> We noticed in #parse'ing an .vm file, excess whitespace, or
> >>> >>> linefeeds,
> >>> >>> are appearing in our templates after merge.
> >>> >>>
> >>> >>> For example, where a '+' indicates a line feed or carriage return:
> >>> >>>
> >>> >>> [mystyles.vm]
> >>> >>> +
> >>> >>> #set( $foo = "Copyright (c)")
> >>> >>> +
> >>> >>> #set( $bar = "2006" )
> >>> >>> +
> >>> >>>
> >>> >>>
> >>> >>> [myemail.txt]
> >>> >>> #parse("mystyles.vm")
> >>> >>> +
> >>> >>> Dear bloated warthog,
> >>> >>> blah
> >>> >>> +
> >>> >>> blah
> >>> >>> +
> >>> >>> blah
> >>> >>> +
> >>> >>> Regards,
> >>> >>> Man in Black
> >>> >>> +
> >>> >>> ${foo} ${bar}
> >>> >>>
> >>> >>> [The final output]
> >>> >>> +
> >>> >>> +
> >>> >>> +
> >>> >>> +
> >>> >>> Dear bloated warthog,
> >>> >>> blah
> >>> >>> +
> >>> >>> blah
> >>> >>> +
> >>> >>> blah
> >>> >>> +
> >>> >>> Regards,
> >>> >>> Man in Black
> >>> >>> +
> >>> >>> Copyright (c) 2006
> >>> >>>
> >>> >>> Can these extra lines be managed in some way?
> >>> >>>
> >>> >>> Thanks,
> >>> >>> Tim
>
>
>
> --
> James Wilson
> Developer
> U.S. District Court
> District of New Mexico
> 333 Lomas Blvd., NW
> Albuquerque, NM 87102
> Phone: (505) 348-2081
> Fax: (505) 348-2028
> jwilson@nmcourt.fed.us
> --
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
> For additional commands, e-mail: user-help@velocity.apache.org
>
>
>
--
Forio Business Simulations
Will Glass-Husain
wglass@forio.com
www.forio.com
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
For additional commands, e-mail: user-help@velocity.apache.org
Re: Whitespace output control
Posted by James Wilson <Ja...@nmcourt.fed.us>.
Marc Novakowski wrote:
> Yeah, we use the ## trick in a few macros where removal of whitespace is
> critical. In most templates, extra whitespace isn't a big deal since,
> in the end, it's all gobbled into a single whitespace character by the
> HTML parser. It's just when you look at the HTML source, it's ugly!
>
> Also, the "##" trick only works to remove newlines, but the indentation
> whitespace (i.e. tabs or spaces) before the velocity statement on the
> line will still be there.
>
> In (my) ideal world, the following:
>
> <table>
> <tr>
> #if ($foo == "bar")
> <td>Fred</td>
> #else
> <td>Bob</td>
> #end
> </tr>
> </table>
>
>
> Would result in:
>
> <table>
> <tr>
> <td>Fred</td>
> </tr>
> </table>
But what is wrong with just providing a custom filter writer to the mergeTemplate
method? It seems to me that you can create any whitespace policy you want this way.
Or better yet -- a chained filter writer. One that deals with spaces and maybe another
that deals with eols. I put an example of this on this list a long time ago -- here
it is again. These writers can be greatly improved but they worked for us.
James
> Marc
>
>
> On 21-Nov-06, at 9:56 AM, Will Glass-Husain wrote:
>
>> Hi Marc,
>>
>> Thanks for the input. There seems to be widespread dissatisfaction
>> with the status quo on this issue, yet it's a tricky issue to change
>> while maintaining backwards compatibility (involves fundamental
>> changes to the parser). Currently thinking about this as part of some
>> future 2.0 version.
>>
>> Incidentally, the best solution for leaving out extra newlines is to
>> put "##" at the end of each line. This kills the newline. Doesn't
>> help the issue of extra spaces before indented statements, though.
>>
>> WILL
>>
>> On 11/21/06, Marc Novakowski <ma...@pandora.com> wrote:
>>> I've been meaning to add my vote to this page, so I finally did it.
>>> +1 for gobbling structured templates.
>>>
>>> We use velocity for most of the "backstage" area at Pandora. It's
>>> made development so much easier! However, the final HTML looks quite
>>> messy due to all of the extra whitespace introduced by the velocity
>>> templates.
>>>
>>> Marc
>>>
>>> On 14-Nov-06, at 8:18 AM, apache@recks.org wrote:
>>>
>>> > See the Wiki on this issue:
>>> > http://wiki.apache.org/jakarta-velocity/VelocityWhitespaceGobbling
>>> >
>>> > Please add your opinion (well thought out) or vote for one of the
>>> > presented approaches.
>>> >
>>> > Cheers,
>>> > Christoph
>>> >
>>> > Paul Loy wrote:
>>> >> I would be very interested in a solution to this problem. From a code
>>> >> layout point of view this would be an important feature. Consider:
>>> >>
>>> >> <div>
>>> >> "
>>> >>
>>> >> #if ($somevar)
>>> >> $somevar
>>> >> #else
>>> >> nothing here
>>> >> #end
>>> >>
>>> >> "
>>> >> </div>
>>> >>
>>> >> This nicely formatted code makes it easy to see what's going on
>>> >> but will
>>> >> make the html render with spaces in it like so (if $somevar is
>>> >> false or
>>> >> null):
>>> >>
>>> >> ' nothing here '
>>> >>
>>> >> Now this is a silly example and in this case it would be much
>>> >> easier to
>>> >> simply do this to eliminate the problem:
>>> >>
>>> >>
>>> >> <div>
>>> >>
>>> >> #if ($somevar)
>>> >> "$somevar"
>>> >> #else
>>> >> "nothing here"
>>> >> #end
>>> >>
>>> >> </div>
>>> >>
>>> >> but in more complex examples you'd either have a great amount of
>>> >> duplicated HTML, which makes it bad to maintain and update, or you'd
>>> >> have to make unreadable code (everything on one line with no white
>>> >> spaces).
>>> >>
>>> >> I converted an old nasty taglibbed jsp into velocity and although I
>>> >> cleaned up the html (removing 20+ unnecessary nested tables) the
>>> >> filesize of the velocity version was actually slightly bigger than
>>> >> the
>>> >> old version because of all the whitespace.
>>> >>
>>> >> So... I would very much like velocity to perhaps remove whitespace
>>> >> between a directive (i.e. a # statement) and any other code.
>>> >>
>>> >> Paul.
>>> >>
>>> >> Timothy Stone wrote:
>>> >>> List,
>>> >>>
>>> >>> We noticed in #parse'ing an .vm file, excess whitespace, or
>>> >>> linefeeds,
>>> >>> are appearing in our templates after merge.
>>> >>>
>>> >>> For example, where a '+' indicates a line feed or carriage return:
>>> >>>
>>> >>> [mystyles.vm]
>>> >>> +
>>> >>> #set( $foo = "Copyright (c)")
>>> >>> +
>>> >>> #set( $bar = "2006" )
>>> >>> +
>>> >>>
>>> >>>
>>> >>> [myemail.txt]
>>> >>> #parse("mystyles.vm")
>>> >>> +
>>> >>> Dear bloated warthog,
>>> >>> blah
>>> >>> +
>>> >>> blah
>>> >>> +
>>> >>> blah
>>> >>> +
>>> >>> Regards,
>>> >>> Man in Black
>>> >>> +
>>> >>> ${foo} ${bar}
>>> >>>
>>> >>> [The final output]
>>> >>> +
>>> >>> +
>>> >>> +
>>> >>> +
>>> >>> Dear bloated warthog,
>>> >>> blah
>>> >>> +
>>> >>> blah
>>> >>> +
>>> >>> blah
>>> >>> +
>>> >>> Regards,
>>> >>> Man in Black
>>> >>> +
>>> >>> Copyright (c) 2006
>>> >>>
>>> >>> Can these extra lines be managed in some way?
>>> >>>
>>> >>> Thanks,
>>> >>> Tim
--
James Wilson
Developer
U.S. District Court
District of New Mexico
333 Lomas Blvd., NW
Albuquerque, NM 87102
Phone: (505) 348-2081
Fax: (505) 348-2028
jwilson@nmcourt.fed.us
--
Re: Whitespace output control
Posted by Marc Novakowski <ma...@pandora.com>.
Yeah, we use the ## trick in a few macros where removal of whitespace
is critical. In most templates, extra whitespace isn't a big deal
since, in the end, it's all gobbled into a single whitespace
character by the HTML parser. It's just when you look at the HTML
source, it's ugly!
Also, the "##" trick only works to remove newlines, but the
indentation whitespace (i.e. tabs or spaces) before the velocity
statement on the line will still be there.
In (my) ideal world, the following:
<table>
<tr>
#if ($foo == "bar")
<td>Fred</td>
#else
<td>Bob</td>
#end
</tr>
</table>
Would result in:
<table>
<tr>
<td>Fred</td>
</tr>
</table>
Marc
On 21-Nov-06, at 9:56 AM, Will Glass-Husain wrote:
> Hi Marc,
>
> Thanks for the input. There seems to be widespread dissatisfaction
> with the status quo on this issue, yet it's a tricky issue to change
> while maintaining backwards compatibility (involves fundamental
> changes to the parser). Currently thinking about this as part of some
> future 2.0 version.
>
> Incidentally, the best solution for leaving out extra newlines is to
> put "##" at the end of each line. This kills the newline. Doesn't
> help the issue of extra spaces before indented statements, though.
>
> WILL
>
> On 11/21/06, Marc Novakowski <ma...@pandora.com> wrote:
>> I've been meaning to add my vote to this page, so I finally did it.
>> +1 for gobbling structured templates.
>>
>> We use velocity for most of the "backstage" area at Pandora. It's
>> made development so much easier! However, the final HTML looks quite
>> messy due to all of the extra whitespace introduced by the velocity
>> templates.
>>
>> Marc
>>
>> On 14-Nov-06, at 8:18 AM, apache@recks.org wrote:
>>
>> > See the Wiki on this issue:
>> > http://wiki.apache.org/jakarta-velocity/
>> VelocityWhitespaceGobbling
>> >
>> > Please add your opinion (well thought out) or vote for one of the
>> > presented approaches.
>> >
>> > Cheers,
>> > Christoph
>> >
>> > Paul Loy wrote:
>> >> I would be very interested in a solution to this problem. From
>> a code
>> >> layout point of view this would be an important feature. Consider:
>> >>
>> >> <div>
>> >> "
>> >>
>> >> #if ($somevar)
>> >> $somevar
>> >> #else
>> >> nothing here
>> >> #end
>> >>
>> >> "
>> >> </div>
>> >>
>> >> This nicely formatted code makes it easy to see what's going on
>> >> but will
>> >> make the html render with spaces in it like so (if $somevar is
>> >> false or
>> >> null):
>> >>
>> >> ' nothing here '
>> >>
>> >> Now this is a silly example and in this case it would be much
>> >> easier to
>> >> simply do this to eliminate the problem:
>> >>
>> >>
>> >> <div>
>> >>
>> >> #if ($somevar)
>> >> "$somevar"
>> >> #else
>> >> "nothing here"
>> >> #end
>> >>
>> >> </div>
>> >>
>> >> but in more complex examples you'd either have a great amount of
>> >> duplicated HTML, which makes it bad to maintain and update, or
>> you'd
>> >> have to make unreadable code (everything on one line with no white
>> >> spaces).
>> >>
>> >> I converted an old nasty taglibbed jsp into velocity and
>> although I
>> >> cleaned up the html (removing 20+ unnecessary nested tables) the
>> >> filesize of the velocity version was actually slightly bigger than
>> >> the
>> >> old version because of all the whitespace.
>> >>
>> >> So... I would very much like velocity to perhaps remove whitespace
>> >> between a directive (i.e. a # statement) and any other code.
>> >>
>> >> Paul.
>> >>
>> >> Timothy Stone wrote:
>> >>> List,
>> >>>
>> >>> We noticed in #parse'ing an .vm file, excess whitespace, or
>> >>> linefeeds,
>> >>> are appearing in our templates after merge.
>> >>>
>> >>> For example, where a '+' indicates a line feed or carriage
>> return:
>> >>>
>> >>> [mystyles.vm]
>> >>> +
>> >>> #set( $foo = "Copyright (c)")
>> >>> +
>> >>> #set( $bar = "2006" )
>> >>> +
>> >>>
>> >>>
>> >>> [myemail.txt]
>> >>> #parse("mystyles.vm")
>> >>> +
>> >>> Dear bloated warthog,
>> >>> blah
>> >>> +
>> >>> blah
>> >>> +
>> >>> blah
>> >>> +
>> >>> Regards,
>> >>> Man in Black
>> >>> +
>> >>> ${foo} ${bar}
>> >>>
>> >>> [The final output]
>> >>> +
>> >>> +
>> >>> +
>> >>> +
>> >>> Dear bloated warthog,
>> >>> blah
>> >>> +
>> >>> blah
>> >>> +
>> >>> blah
>> >>> +
>> >>> Regards,
>> >>> Man in Black
>> >>> +
>> >>> Copyright (c) 2006
>> >>>
>> >>> Can these extra lines be managed in some way?
>> >>>
>> >>> Thanks,
>> >>> Tim
>> >>>
>> >>>
>> >>>
>> >>>
>> --------------------------------------------------------------------
>> >>> -
>> >>> To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
>> >>> For additional commands, e-mail: user-help@velocity.apache.org
>> >>>
>> >>
>> >>
>> >
>> >
>> ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
>> > For additional commands, e-mail: user-help@velocity.apache.org
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
>> For additional commands, e-mail: user-help@velocity.apache.org
>>
>>
>
>
> --
> Forio Business Simulations
>
> Will Glass-Husain
> wglass@forio.com
> www.forio.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
> For additional commands, e-mail: user-help@velocity.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
For additional commands, e-mail: user-help@velocity.apache.org
Re: Whitespace output control
Posted by Will Glass-Husain <wg...@forio.com>.
Hi Marc,
Thanks for the input. There seems to be widespread dissatisfaction
with the status quo on this issue, yet it's a tricky issue to change
while maintaining backwards compatibility (involves fundamental
changes to the parser). Currently thinking about this as part of some
future 2.0 version.
Incidentally, the best solution for leaving out extra newlines is to
put "##" at the end of each line. This kills the newline. Doesn't
help the issue of extra spaces before indented statements, though.
WILL
On 11/21/06, Marc Novakowski <ma...@pandora.com> wrote:
> I've been meaning to add my vote to this page, so I finally did it.
> +1 for gobbling structured templates.
>
> We use velocity for most of the "backstage" area at Pandora. It's
> made development so much easier! However, the final HTML looks quite
> messy due to all of the extra whitespace introduced by the velocity
> templates.
>
> Marc
>
> On 14-Nov-06, at 8:18 AM, apache@recks.org wrote:
>
> > See the Wiki on this issue:
> > http://wiki.apache.org/jakarta-velocity/VelocityWhitespaceGobbling
> >
> > Please add your opinion (well thought out) or vote for one of the
> > presented approaches.
> >
> > Cheers,
> > Christoph
> >
> > Paul Loy wrote:
> >> I would be very interested in a solution to this problem. From a code
> >> layout point of view this would be an important feature. Consider:
> >>
> >> <div>
> >> "
> >>
> >> #if ($somevar)
> >> $somevar
> >> #else
> >> nothing here
> >> #end
> >>
> >> "
> >> </div>
> >>
> >> This nicely formatted code makes it easy to see what's going on
> >> but will
> >> make the html render with spaces in it like so (if $somevar is
> >> false or
> >> null):
> >>
> >> ' nothing here '
> >>
> >> Now this is a silly example and in this case it would be much
> >> easier to
> >> simply do this to eliminate the problem:
> >>
> >>
> >> <div>
> >>
> >> #if ($somevar)
> >> "$somevar"
> >> #else
> >> "nothing here"
> >> #end
> >>
> >> </div>
> >>
> >> but in more complex examples you'd either have a great amount of
> >> duplicated HTML, which makes it bad to maintain and update, or you'd
> >> have to make unreadable code (everything on one line with no white
> >> spaces).
> >>
> >> I converted an old nasty taglibbed jsp into velocity and although I
> >> cleaned up the html (removing 20+ unnecessary nested tables) the
> >> filesize of the velocity version was actually slightly bigger than
> >> the
> >> old version because of all the whitespace.
> >>
> >> So... I would very much like velocity to perhaps remove whitespace
> >> between a directive (i.e. a # statement) and any other code.
> >>
> >> Paul.
> >>
> >> Timothy Stone wrote:
> >>> List,
> >>>
> >>> We noticed in #parse'ing an .vm file, excess whitespace, or
> >>> linefeeds,
> >>> are appearing in our templates after merge.
> >>>
> >>> For example, where a '+' indicates a line feed or carriage return:
> >>>
> >>> [mystyles.vm]
> >>> +
> >>> #set( $foo = "Copyright (c)")
> >>> +
> >>> #set( $bar = "2006" )
> >>> +
> >>>
> >>>
> >>> [myemail.txt]
> >>> #parse("mystyles.vm")
> >>> +
> >>> Dear bloated warthog,
> >>> blah
> >>> +
> >>> blah
> >>> +
> >>> blah
> >>> +
> >>> Regards,
> >>> Man in Black
> >>> +
> >>> ${foo} ${bar}
> >>>
> >>> [The final output]
> >>> +
> >>> +
> >>> +
> >>> +
> >>> Dear bloated warthog,
> >>> blah
> >>> +
> >>> blah
> >>> +
> >>> blah
> >>> +
> >>> Regards,
> >>> Man in Black
> >>> +
> >>> Copyright (c) 2006
> >>>
> >>> Can these extra lines be managed in some way?
> >>>
> >>> Thanks,
> >>> Tim
> >>>
> >>>
> >>>
> >>> --------------------------------------------------------------------
> >>> -
> >>> To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
> >>> For additional commands, e-mail: user-help@velocity.apache.org
> >>>
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
> > For additional commands, e-mail: user-help@velocity.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
> For additional commands, e-mail: user-help@velocity.apache.org
>
>
--
Forio Business Simulations
Will Glass-Husain
wglass@forio.com
www.forio.com
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
For additional commands, e-mail: user-help@velocity.apache.org
Re: Whitespace output control
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
Paul Loy <pa...@peoplesarchive.com> writes:
>> I'm not sure that you can nail this down in pure EBNF. I'm definitely
>> not a parser guru, though (haven't touched my dragon book in
>> ages). Our current parser has a mess of sprinkled in Java code and I'm
>> not really sure how it does it (Geir and Jason might).
>>
>Hi Henning,
>antlr grammars are not pure EBNF but are very similar. I find them a
>little more 'regexpy'. Secondly, I think you're getting confused by
>parsing and rendering. These are two separate steps.
Probably.
>So, after parsing, you would get the first tree back:
><DIRECTIVE START>
> <DIRECTIVE NAME>
> foo
> <MACRO BODY>
> <PARAM>
> 10
> <PARAM>
> 20
>then, when you'd parsed everything, including all your #parse
>directives, you'd start the render process by going back through the
>trees. When you come across this part of the tree, if the foo macro has
>been defined somewhere you do your macro magic, if not you output
>whatever the default would be (which I think is to just treat it as text).
IIRC from my tracing through the code, a non-defined macro is really
rendered as text, else this:
#foo( 20 20 )
would be rendered as #foo(20 20) because currently we have no 'token
for whitespace' concept at all. So the parser does behave differently
whether it finds 'foo' in the macro table or not.
>I'll come up with a EBNF specification of the velocity 1.4 language if
>you like. I quite like doing them and it would give you a good base for
>the velocity 2.0 language!
That would be really great! Still, can I cordially invite you over to
dev@velocity.apache.org ? :-)
Best regards
Henning
--
Henning P. Schmiedehausen -- hps@intermeta.de | J2EE, Linux,
91054 Buckenhof, Germany -- +49 9131 506540 | Apache person
Open Source Consulting, Development, Design | Velocity - Turbine guy
"Save the cheerleader. Save the world."
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
For additional commands, e-mail: user-help@velocity.apache.org
Re: Whitespace output control
Posted by Paul Loy <pa...@peoplesarchive.com>.
Henning P. Schmiedehausen wrote:
> <EMPTY STRING> <DIRECTIVE START> followed by existing <DIRECTIVE NAME>
> Render FOO Macro: <MACRO BODY>
> 10 <PARAM>
> / <MACRO BODY>
> 20 <PARAM>
>
> and the second template renders as
>
> # <DIRECTIVE START> followed by non-existing <DIRECTIVE NAME>
> foo non existing <DIRECTIVE NAME>
> (10 20) <TEXT>
>
> So the AST would be (IMHO) different depending on the existence of
> 'foo' in the table of valid directives (a macro creates a new
> directive).
>
> I'm not sure that you can nail this down in pure EBNF. I'm definitely
> not a parser guru, though (haven't touched my dragon book in
> ages). Our current parser has a mess of sprinkled in Java code and I'm
> not really sure how it does it (Geir and Jason might).
>
Hi Henning,
antlr grammars are not pure EBNF but are very similar. I find them a
little more 'regexpy'. Secondly, I think you're getting confused by
parsing and rendering. These are two separate steps.
So, after parsing, you would get the first tree back:
<DIRECTIVE START>
<DIRECTIVE NAME>
foo
<MACRO BODY>
<PARAM>
10
<PARAM>
20
then, when you'd parsed everything, including all your #parse
directives, you'd start the render process by going back through the
trees. When you come across this part of the tree, if the foo macro has
been defined somewhere you do your macro magic, if not you output
whatever the default would be (which I think is to just treat it as text).
I'll come up with a EBNF specification of the velocity 1.4 language if
you like. I quite like doing them and it would give you a good base for
the velocity 2.0 language!
Paul.
--
*Paul Loy
Software Developer*
Tel: +44 (0) 20 7323 0323
Fax: +44 (0) 20 7580 1938
paul.loy@peoplesarchive.com
paul@keteracel.com
http://www.keteracel.com/paul
This email has been scanned by Postini.
For more information please visit http://www.postini.com
Re: Whitespace output control
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
Paul Loy <pa...@peoplesarchive.com> writes:
Hi Paul,
>Henning P. Schmiedehausen wrote:
>> Haven't heard about JParse yet. antlr looks promising and @ AC US
>> someone told me that antlr3 will no longer need the antlr runtime,
>> which is one of the things that would keep me from using it. Love to
>> hear more about JParse.
>>
>Ok, if you're not keen on antlr you're probably not going to like JParse
>in that it uses antlr.
It's not that I don't like antlr. I just want to avoid adding another
dependency for Velocity, mainly because Velocity itself is usually a
component in a larger application and dragging in the antlr-runtime
might upset application writers. JavaCC, despite all its shortcomings
is better here.
>http://www.ittc.ku.edu/JParse/
Thanks, I looked at it a bit and put down a bookmark.
>Now, correct me if I'm wrong, but you can develop an antlr grammar quite
>easily that would treat whitespace as a token. Then, when you process
>the generated tree, you just decide what you want to do with that token
>depending on where it turns up. You could also have different tokens to
>help you out so you don't need to keep going forwards and backwards
>through the generated tree.
Sure. The problem is, that we don't really have a good grammar
definition yet (see below).
>Do you have the current velocity language in an Extended Backus-Naur
>format? If so I could take a peek and see what we could do with the
>whitespace.
It shames me to no end to say that I had to google for that question
and I found some quite old EBNF grammars (which seem to have been
removed in the 1.2 -> 1.3 dev cycle) for the language itself and I
found
http://marc.theaimsgroup.com/?l=velocity-user&m=101902732218948&w=2
which has some suggestions on how to deal with white space. Aside from
that, no we don't have any current EBNF and I'm not really sure if it
is possible to deal with macros in an EBNF the way we deal with macros
currently.
Consider the following two templates:
--- template1.vm ---
#macro (foo $arg1 $arg2)
Render FOO Macro: $arg1/$arg2
#end
## TEST BEGIN
#foo(10 20)
## TEST END
--- template1.vm ---
--- template2.vm ---
## TEST BEGIN
#foo(10 20)
## TEST END
--- template2.vm ---
In these two templates, the block between TEST BEGIN and TEST END must
be parsed differently according to the presence of the "foo" directive:
Template 1:
---> #
<DIRECTIVE START>
|
<Child>
|
+------> foo
<DIRECTIVE NAME>
|
<Children>
|
+---------> 10
| <PARAM>
|
+---------> 20
<PARAM>
Template 2:
-+-> #
| <DIRECTIVE START>
| |
| <Child>
| |
| +------> foo
| <DIRECTIVE NAME>
|
+-> (10 20)
<TEXT>
so the first template renders as
<EMPTY STRING> <DIRECTIVE START> followed by existing <DIRECTIVE NAME>
Render FOO Macro: <MACRO BODY>
10 <PARAM>
/ <MACRO BODY>
20 <PARAM>
and the second template renders as
# <DIRECTIVE START> followed by non-existing <DIRECTIVE NAME>
foo non existing <DIRECTIVE NAME>
(10 20) <TEXT>
So the AST would be (IMHO) different depending on the existence of
'foo' in the table of valid directives (a macro creates a new
directive).
I'm not sure that you can nail this down in pure EBNF. I'm definitely
not a parser guru, though (haven't touched my dragon book in
ages). Our current parser has a mess of sprinkled in Java code and I'm
not really sure how it does it (Geir and Jason might).
If you want to take a stab at that or even want to help formulating a
'real' EBNF and antlr grammar, I'd love to invite you over to
dev@velocity. We can discuss this in depth there. This is IMHO already
serious voodoo and probably out of scope for most 'regular' velocity
users.
Best regards
Henning
--
Henning P. Schmiedehausen -- hps@intermeta.de | J2EE, Linux,
91054 Buckenhof, Germany -- +49 9131 506540 | Apache person
Open Source Consulting, Development, Design | Velocity - Turbine guy
"Save the cheerleader. Save the world."
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
For additional commands, e-mail: user-help@velocity.apache.org
Re: Whitespace output control
Posted by Paul Loy <pa...@peoplesarchive.com>.
Henning P. Schmiedehausen wrote:
> Haven't heard about JParse yet. antlr looks promising and @ AC US
> someone told me that antlr3 will no longer need the antlr runtime,
> which is one of the things that would keep me from using it. Love to
> hear more about JParse.
>
Ok, if you're not keen on antlr you're probably not going to like JParse
in that it uses antlr.
http://www.ittc.ku.edu/JParse/
But then JParse is just for java code anyway (I used it to create a
software metrics program for analysing how 'well designed' ond
'object-oriented' peoples' code was).
Now, correct me if I'm wrong, but you can develop an antlr grammar quite
easily that would treat whitespace as a token. Then, when you process
the generated tree, you just decide what you want to do with that token
depending on where it turns up. You could also have different tokens to
help you out so you don't need to keep going forwards and backwards
through the generated tree.
Do you have the current velocity language in an Extended Backus-Naur
format? If so I could take a peek and see what we could do with the
whitespace.
Paul.
--
*Paul Loy
Software Developer*
Peoples Archive Ltd.
Middlesex House
34-42 Cleveland Street
London, W1T 4LB
Tel: +44 (0) 20 7323 0323
Fax: +44 (0) 20 7580 1938
paul.loy@peoplesarchive.com
This email has been scanned by Postini.
For more information please visit http://www.postini.com
Re: Whitespace output control
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
Paul Loy <pa...@peoplesarchive.com> writes:
>If you need any more developers I'll be happy to contribute to such a
>worthwhile project. I do have experience with parsers (antlr & JParse)
Haven't heard about JParse yet. antlr looks promising and @ AC US
someone told me that antlr3 will no longer need the antlr runtime,
which is one of the things that would keep me from using it. Love to
hear more about JParse.
The JavaCC thing currently seems to be the least bad way to go unless
you want to hand-roll a parser as (IIRC) FreeMarker did.
Best regards
Henning
--
Henning P. Schmiedehausen -- hps@intermeta.de | J2EE, Linux,
91054 Buckenhof, Germany -- +49 9131 506540 | Apache person
Open Source Consulting, Development, Design | Velocity - Turbine guy
"Save the cheerleader. Save the world."
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
For additional commands, e-mail: user-help@velocity.apache.org
Re: Whitespace output control
Posted by Paul Loy <pa...@peoplesarchive.com>.
Henning P. Schmiedehausen wrote:
> - <shameless-plug mode="on">If your urge is pressing enough, consider making
> a project from it and pay a consultant to implement it</shameless-plug>
> I know a number of Apache people (me included) who got payed working on
> Apache code and were allowed to put that back into the code base.
>
>
Unfortunately it's not too pressing, just annoying. Velocity has made
our site faster and easier to maintain which is great. It's just a shame
it's made the file sizes bigger, and considerably so (~10%). I'll
probably just create a whitespace gobbler filter of my own to stick on
the output. Should only take me a few minutes, will remove all nice
formatting, but will decrease the file size considerably.
> But we *do* listen to you.
Good job. Third-party open source libraries are what is maintaining the
growth in the IT industry. We are very thankful of all the time and
effort you guys put in to projects like this.
If you need any more developers I'll be happy to contribute to such a
worthwhile project. I do have experience with parsers (antlr & JParse)
so I know what the problems and pitfalls of parsing are. But I think in
this case we only have to alter the parser in such a way as to treat
whitespace as an entity. Then, depending on the nesting of the
whitespace entity, depends on whether it appears in the output or is
discarded.
Of course this sounds easy but will depend heavily on the parser you're
using. I wouldn't mind taking a look though!
> The best way for us to keep
> track is opening an issue
> (http://issues.apache.org/jira/browse/VELOCITY-253) and vote
> there. :-)
>
> Best regards
> Henning
>
Maybe I should put this in there?
--
*Paul Loy
Software Developer*
Peoples Archive Ltd.
Middlesex House
34-42 Cleveland Street
London, W1T 4LB
Tel: +44 (0) 20 7323 0323
Fax: +44 (0) 20 7580 1938
paul.loy@peoplesarchive.com
www.peoplesarchive.com
This email has been scanned by Postini.
For more information please visit http://www.postini.com
Re: Whitespace output control
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
Paul Loy <pa...@peoplesarchive.com> writes:
>Please, everyone vote for some type of whitespace gobbling to appear in
>Velocity 2.
>To vote:
Paul, thanks for your initiative. In my world, however the situation
looks like this:
- a contributor gives us a patch (does not need to be polished or complete,
but a general way to go).
- one of the "powers that be" coughs up enough time to seriously wrap a brain
or two around the parser. That is deep voodoo at least to me, so it's not
a five minute thing. I looked a bit at it and I do plan to work on it
for 2.0. However, we currently have the TLP move and the 1.5 release on
our agenda so it will not happen overnight.
- <shameless-plug mode="on">If your urge is pressing enough, consider making
a project from it and pay a consultant to implement it</shameless-plug>
I know a number of Apache people (me included) who got payed working on
Apache code and were allowed to put that back into the code base.
But we *do* listen to you. After all, Velocity lives through our users
and the projects using it. I know that for a long time, it looked
differently but I want to believe that we did change in the last
twelve months and we want to keep this up. The best way for us to keep
track is opening an issue
(http://issues.apache.org/jira/browse/VELOCITY-253) and vote
there. :-)
Best regards
Henning
>go to http://wiki.apache.org/jakarta-velocity/VelocityWhitespaceGobbling
>* click on 'login' (don't worry if you're not registered you can
>register after you've clicked 'login')
>* register or login
>* go back to
>http://wiki.apache.org/jakarta-velocity/VelocityWhitespaceGobbling
>* click 'edit'
>* scroll down to the voting bit and add your name and obfuscated email
>address.
>This is really important as if the powers that be don't know that lots
>of people want (and need) this they may not bother to add it!
>Ok, here's a 'real-world' example of how the comments at the end of the
>line looks and works, from the header of www.peoplesarchive.com :
>original code:
> <ul class="navigation">
> <li class="first
>#if ($sectionName.equals("home"))
> selected_list_item
>#end
>"><a href="/">home</a></li>
> <li
>#if ($sectionName.equals("browse"))
> class="selected_list_item"
>#end
> ><a href="/browse/">browse</a></li>
> <li
>#if ($sectionName.equals("search"))
> class="selected_list_item"
>#end
> ><a href="/search/">search</a></li>
> <li
>#if ($sectionName.equals("playlists"))
> class="selected_list_item"
>#end
> ><a href="/playlists/">playlists</a></li>
>#if ($subscription == 0)
> <li
> #if ($sectionName.equals("login"))
> class="selected_list_item"
> #end
> ><a href="/login/">login</a></li>
> <li
> #if ($sectionName.equals("register"))
> class="selected_list_item"
> #end
> ><a href="/register/">register</a></li>
>#else
> <li
> #if ($sectionName.equals("logout"))
> class="selected_list_item"
> #end
> ><a href="/login/logout.jsp">logout</a></li>
> <li
> #if ($sectionName.equals("myarchive"))
> class="selected_list_item"
> #end
> ><a href="/myarchive/">my archive</a></li>
>#end
> <li
>#if ($sectionName.equals("about"))
> class="selected_list_item"
>#end
> ><a href="/about/">about us</a></li>
> <li
>#if ($sectionName.equals("contact"))
> class="selected_list_item"
>#end
> ><a href="/contact/">contact</a></li>
> <li
>#if ($sectionName.equals("feedback"))
> class="selected_list_item"
>#end
> ><a href="/feedback/">feedback</a></li>
> </ul>
>code trying to eliminate whitespace
><ul class="navigation">##
><li class="first##
>#if ($sectionName.equals("home"))##
> selected_list_item ##
>#end##
>"><a href="/">home</a></li>##
>##
><li##
>#if ($sectionName.equals("browse"))##
> class="selected_list_item"##
>#end##
> ><a href="/browse/">browse</a></li>##
>##
><li##
>#if ($sectionName.equals("search"))##
> class="selected_list_item"##
>#end##
> ><a href="/search/">search</a></li>##
>##
><li##
>#if ($sectionName.equals("playlists"))##
> class="selected_list_item"##
>#end##
> ><a href="/playlists/">playlists</a></li>##
>##
>#if ($subscription == 0)##
>##
><li##
>#if ($sectionName.equals("login")) ##
> class="selected_list_item"##
>#end##
> ><a href="/login/">login</a></li>##
>##
><li##
>#if ($sectionName.equals("register"))##
> class="selected_list_item"##
>#end##
> ><a href="/register/">register</a></li>##
>##
>#else##
>##
><li##
>#if ($sectionName.equals("logout"))##
> class="selected_list_item"##
>#end##
> ><a href="/login/logout.jsp">logout</a></li>##
>##
><li##
>#if ($sectionName.equals("myarchive"))##
> class="selected_list_item"##
>#end##
> ><a href="/myarchive/">my archive</a></li>##
>##
>#end##
>##
>##
><li##
>#if ($sectionName.equals("about"))##
> class="selected_list_item"##
>#end##
> ><a href="/about/">about us</a></li>##
>##
><li##
>#if ($sectionName.equals("contact"))##
> class="selected_list_item"##
>#end##
> ><a href="/contact/">contact</a></li>##
>##
><li##
>#if ($sectionName.equals("feedback"))##
> class="selected_list_item"##
>#end##
> ><a href="/feedback/">feedback</a></li>##
>##
> </ul>
>The first version makes the header twice as long as all the whitespace
>pads it out, the second is normal but the code is now awful!
>Please, everyone vote for some type of whitespace gobbling to appear in
>Velocity 2.
>To vote:
>go to http://wiki.apache.org/jakarta-velocity/VelocityWhitespaceGobbling
>* click on 'login' (don't worry if you're not registered you can
>register after you've clicked 'login')
>* register or login
>* go back to
>http://wiki.apache.org/jakarta-velocity/VelocityWhitespaceGobbling
>* click 'edit'
>* scroll down to the voting bit and add your name and obfuscated email
>address.
>This is really important as if the powers that be don't know that lots
>of people want (and need) this they may not bother to add it!
>Paul.
>
>Marc Novakowski wrote:
>> I've been meaning to add my vote to this page, so I finally did it.
>> +1 for gobbling structured templates.
>>
>> We use velocity for most of the "backstage" area at Pandora. It's
>> made development so much easier! However, the final HTML looks quite
>> messy due to all of the extra whitespace introduced by the velocity
>> templates.
>>
>> Marc
>>
>> On 14-Nov-06, at 8:18 AM, apache@recks.org wrote:
>>
>>> See the Wiki on this issue:
>>> http://wiki.apache.org/jakarta-velocity/VelocityWhitespaceGobbling
>>>
>>> Please add your opinion (well thought out) or vote for one of the
>>> presented approaches.
>>>
>>> Cheers,
>>> Christoph
>>>
>>> Paul Loy wrote:
>>>> I would be very interested in a solution to this problem. From a code
>>>> layout point of view this would be an important feature. Consider:
>>>>
>>>> <div>
>>>> "
>>>>
>>>> #if ($somevar)
>>>> $somevar
>>>> #else
>>>> nothing here
>>>> #end
>>>>
>>>> "
>>>> </div>
>>>>
>>>> This nicely formatted code makes it easy to see what's going on but
>>>> will
>>>> make the html render with spaces in it like so (if $somevar is false or
>>>> null):
>>>>
>>>> ' nothing here '
>>>>
>>>> Now this is a silly example and in this case it would be much easier to
>>>> simply do this to eliminate the problem:
>>>>
>>>>
>>>> <div>
>>>>
>>>> #if ($somevar)
>>>> "$somevar"
>>>> #else
>>>> "nothing here"
>>>> #end
>>>>
>>>> </div>
>>>>
>>>> but in more complex examples you'd either have a great amount of
>>>> duplicated HTML, which makes it bad to maintain and update, or you'd
>>>> have to make unreadable code (everything on one line with no white
>>>> spaces).
>>>>
>>>> I converted an old nasty taglibbed jsp into velocity and although I
>>>> cleaned up the html (removing 20+ unnecessary nested tables) the
>>>> filesize of the velocity version was actually slightly bigger than the
>>>> old version because of all the whitespace.
>>>>
>>>> So... I would very much like velocity to perhaps remove whitespace
>>>> between a directive (i.e. a # statement) and any other code.
>>>>
>>>> Paul.
>>>>
>>>> Timothy Stone wrote:
>>>>> List,
>>>>>
>>>>> We noticed in #parse'ing an .vm file, excess whitespace, or linefeeds,
>>>>> are appearing in our templates after merge.
>>>>>
>>>>> For example, where a '+' indicates a line feed or carriage return:
>>>>>
>>>>> [mystyles.vm]
>>>>> +
>>>>> #set( $foo = "Copyright (c)")
>>>>> +
>>>>> #set( $bar = "2006" )
>>>>> +
>>>>>
>>>>>
>>>>> [myemail.txt]
>>>>> #parse("mystyles.vm")
>>>>> +
>>>>> Dear bloated warthog,
>>>>> blah
>>>>> +
>>>>> blah
>>>>> +
>>>>> blah
>>>>> +
>>>>> Regards,
>>>>> Man in Black
>>>>> +
>>>>> ${foo} ${bar}
>>>>>
>>>>> [The final output]
>>>>> +
>>>>> +
>>>>> +
>>>>> +
>>>>> Dear bloated warthog,
>>>>> blah
>>>>> +
>>>>> blah
>>>>> +
>>>>> blah
>>>>> +
>>>>> Regards,
>>>>> Man in Black
>>>>> +
>>>>> Copyright (c) 2006
>>>>>
>>>>> Can these extra lines be managed in some way?
>>>>>
>>>>> Thanks,
>>>>> Tim
>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
>>>>> For additional commands, e-mail: user-help@velocity.apache.org
>>>>>
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
>>> For additional commands, e-mail: user-help@velocity.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
>> For additional commands, e-mail: user-help@velocity.apache.org
>>
>--
>*Paul Loy
>Software Developer*
>Peoples Archive Ltd.
>Middlesex House
>34-42 Cleveland Street
>London, W1T 4LB
>Tel: +44 (0) 20 7323 0323
>Fax: +44 (0) 20 7580 1938
>paul.loy@peoplesarchive.com
>This email has been scanned by Postini.
>For more information please visit http://www.postini.com
>--------------060003000508070407040500--
--
Henning P. Schmiedehausen -- hps@intermeta.de | J2EE, Linux,
91054 Buckenhof, Germany -- +49 9131 506540 | Apache person
Open Source Consulting, Development, Design | Velocity - Turbine guy
"Save the cheerleader. Save the world."
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
For additional commands, e-mail: user-help@velocity.apache.org
Re: Whitespace output control
Posted by Paul Loy <pa...@peoplesarchive.com>.
Please, everyone vote for some type of whitespace gobbling to appear in
Velocity 2.
To vote:
go to http://wiki.apache.org/jakarta-velocity/VelocityWhitespaceGobbling
* click on 'login' (don't worry if you're not registered you can
register after you've clicked 'login')
* register or login
* go back to
http://wiki.apache.org/jakarta-velocity/VelocityWhitespaceGobbling
* click 'edit'
* scroll down to the voting bit and add your name and obfuscated email
address.
This is really important as if the powers that be don't know that lots
of people want (and need) this they may not bother to add it!
Ok, here's a 'real-world' example of how the comments at the end of the
line looks and works, from the header of www.peoplesarchive.com :
original code:
<ul class="navigation">
<li class="first
#if ($sectionName.equals("home"))
selected_list_item
#end
"><a href="/">home</a></li>
<li
#if ($sectionName.equals("browse"))
class="selected_list_item"
#end
><a href="/browse/">browse</a></li>
<li
#if ($sectionName.equals("search"))
class="selected_list_item"
#end
><a href="/search/">search</a></li>
<li
#if ($sectionName.equals("playlists"))
class="selected_list_item"
#end
><a href="/playlists/">playlists</a></li>
#if ($subscription == 0)
<li
#if ($sectionName.equals("login"))
class="selected_list_item"
#end
><a href="/login/">login</a></li>
<li
#if ($sectionName.equals("register"))
class="selected_list_item"
#end
><a href="/register/">register</a></li>
#else
<li
#if ($sectionName.equals("logout"))
class="selected_list_item"
#end
><a href="/login/logout.jsp">logout</a></li>
<li
#if ($sectionName.equals("myarchive"))
class="selected_list_item"
#end
><a href="/myarchive/">my archive</a></li>
#end
<li
#if ($sectionName.equals("about"))
class="selected_list_item"
#end
><a href="/about/">about us</a></li>
<li
#if ($sectionName.equals("contact"))
class="selected_list_item"
#end
><a href="/contact/">contact</a></li>
<li
#if ($sectionName.equals("feedback"))
class="selected_list_item"
#end
><a href="/feedback/">feedback</a></li>
</ul>
code trying to eliminate whitespace
<ul class="navigation">##
<li class="first##
#if ($sectionName.equals("home"))##
selected_list_item ##
#end##
"><a href="/">home</a></li>##
##
<li##
#if ($sectionName.equals("browse"))##
class="selected_list_item"##
#end##
><a href="/browse/">browse</a></li>##
##
<li##
#if ($sectionName.equals("search"))##
class="selected_list_item"##
#end##
><a href="/search/">search</a></li>##
##
<li##
#if ($sectionName.equals("playlists"))##
class="selected_list_item"##
#end##
><a href="/playlists/">playlists</a></li>##
##
#if ($subscription == 0)##
##
<li##
#if ($sectionName.equals("login")) ##
class="selected_list_item"##
#end##
><a href="/login/">login</a></li>##
##
<li##
#if ($sectionName.equals("register"))##
class="selected_list_item"##
#end##
><a href="/register/">register</a></li>##
##
#else##
##
<li##
#if ($sectionName.equals("logout"))##
class="selected_list_item"##
#end##
><a href="/login/logout.jsp">logout</a></li>##
##
<li##
#if ($sectionName.equals("myarchive"))##
class="selected_list_item"##
#end##
><a href="/myarchive/">my archive</a></li>##
##
#end##
##
##
<li##
#if ($sectionName.equals("about"))##
class="selected_list_item"##
#end##
><a href="/about/">about us</a></li>##
##
<li##
#if ($sectionName.equals("contact"))##
class="selected_list_item"##
#end##
><a href="/contact/">contact</a></li>##
##
<li##
#if ($sectionName.equals("feedback"))##
class="selected_list_item"##
#end##
><a href="/feedback/">feedback</a></li>##
##
</ul>
The first version makes the header twice as long as all the whitespace
pads it out, the second is normal but the code is now awful!
Please, everyone vote for some type of whitespace gobbling to appear in
Velocity 2.
To vote:
go to http://wiki.apache.org/jakarta-velocity/VelocityWhitespaceGobbling
* click on 'login' (don't worry if you're not registered you can
register after you've clicked 'login')
* register or login
* go back to
http://wiki.apache.org/jakarta-velocity/VelocityWhitespaceGobbling
* click 'edit'
* scroll down to the voting bit and add your name and obfuscated email
address.
This is really important as if the powers that be don't know that lots
of people want (and need) this they may not bother to add it!
Paul.
Marc Novakowski wrote:
> I've been meaning to add my vote to this page, so I finally did it.
> +1 for gobbling structured templates.
>
> We use velocity for most of the "backstage" area at Pandora. It's
> made development so much easier! However, the final HTML looks quite
> messy due to all of the extra whitespace introduced by the velocity
> templates.
>
> Marc
>
> On 14-Nov-06, at 8:18 AM, apache@recks.org wrote:
>
>> See the Wiki on this issue:
>> http://wiki.apache.org/jakarta-velocity/VelocityWhitespaceGobbling
>>
>> Please add your opinion (well thought out) or vote for one of the
>> presented approaches.
>>
>> Cheers,
>> Christoph
>>
>> Paul Loy wrote:
>>> I would be very interested in a solution to this problem. From a code
>>> layout point of view this would be an important feature. Consider:
>>>
>>> <div>
>>> "
>>>
>>> #if ($somevar)
>>> $somevar
>>> #else
>>> nothing here
>>> #end
>>>
>>> "
>>> </div>
>>>
>>> This nicely formatted code makes it easy to see what's going on but
>>> will
>>> make the html render with spaces in it like so (if $somevar is false or
>>> null):
>>>
>>> ' nothing here '
>>>
>>> Now this is a silly example and in this case it would be much easier to
>>> simply do this to eliminate the problem:
>>>
>>>
>>> <div>
>>>
>>> #if ($somevar)
>>> "$somevar"
>>> #else
>>> "nothing here"
>>> #end
>>>
>>> </div>
>>>
>>> but in more complex examples you'd either have a great amount of
>>> duplicated HTML, which makes it bad to maintain and update, or you'd
>>> have to make unreadable code (everything on one line with no white
>>> spaces).
>>>
>>> I converted an old nasty taglibbed jsp into velocity and although I
>>> cleaned up the html (removing 20+ unnecessary nested tables) the
>>> filesize of the velocity version was actually slightly bigger than the
>>> old version because of all the whitespace.
>>>
>>> So... I would very much like velocity to perhaps remove whitespace
>>> between a directive (i.e. a # statement) and any other code.
>>>
>>> Paul.
>>>
>>> Timothy Stone wrote:
>>>> List,
>>>>
>>>> We noticed in #parse'ing an .vm file, excess whitespace, or linefeeds,
>>>> are appearing in our templates after merge.
>>>>
>>>> For example, where a '+' indicates a line feed or carriage return:
>>>>
>>>> [mystyles.vm]
>>>> +
>>>> #set( $foo = "Copyright (c)")
>>>> +
>>>> #set( $bar = "2006" )
>>>> +
>>>>
>>>>
>>>> [myemail.txt]
>>>> #parse("mystyles.vm")
>>>> +
>>>> Dear bloated warthog,
>>>> blah
>>>> +
>>>> blah
>>>> +
>>>> blah
>>>> +
>>>> Regards,
>>>> Man in Black
>>>> +
>>>> ${foo} ${bar}
>>>>
>>>> [The final output]
>>>> +
>>>> +
>>>> +
>>>> +
>>>> Dear bloated warthog,
>>>> blah
>>>> +
>>>> blah
>>>> +
>>>> blah
>>>> +
>>>> Regards,
>>>> Man in Black
>>>> +
>>>> Copyright (c) 2006
>>>>
>>>> Can these extra lines be managed in some way?
>>>>
>>>> Thanks,
>>>> Tim
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
>>>> For additional commands, e-mail: user-help@velocity.apache.org
>>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
>> For additional commands, e-mail: user-help@velocity.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
> For additional commands, e-mail: user-help@velocity.apache.org
>
--
*Paul Loy
Software Developer*
Peoples Archive Ltd.
Middlesex House
34-42 Cleveland Street
London, W1T 4LB
Tel: +44 (0) 20 7323 0323
Fax: +44 (0) 20 7580 1938
paul.loy@peoplesarchive.com
This email has been scanned by Postini.
For more information please visit http://www.postini.com
Re: Whitespace output control
Posted by Marc Novakowski <ma...@pandora.com>.
I've been meaning to add my vote to this page, so I finally did it.
+1 for gobbling structured templates.
We use velocity for most of the "backstage" area at Pandora. It's
made development so much easier! However, the final HTML looks quite
messy due to all of the extra whitespace introduced by the velocity
templates.
Marc
On 14-Nov-06, at 8:18 AM, apache@recks.org wrote:
> See the Wiki on this issue:
> http://wiki.apache.org/jakarta-velocity/VelocityWhitespaceGobbling
>
> Please add your opinion (well thought out) or vote for one of the
> presented approaches.
>
> Cheers,
> Christoph
>
> Paul Loy wrote:
>> I would be very interested in a solution to this problem. From a code
>> layout point of view this would be an important feature. Consider:
>>
>> <div>
>> "
>>
>> #if ($somevar)
>> $somevar
>> #else
>> nothing here
>> #end
>>
>> "
>> </div>
>>
>> This nicely formatted code makes it easy to see what's going on
>> but will
>> make the html render with spaces in it like so (if $somevar is
>> false or
>> null):
>>
>> ' nothing here '
>>
>> Now this is a silly example and in this case it would be much
>> easier to
>> simply do this to eliminate the problem:
>>
>>
>> <div>
>>
>> #if ($somevar)
>> "$somevar"
>> #else
>> "nothing here"
>> #end
>>
>> </div>
>>
>> but in more complex examples you'd either have a great amount of
>> duplicated HTML, which makes it bad to maintain and update, or you'd
>> have to make unreadable code (everything on one line with no white
>> spaces).
>>
>> I converted an old nasty taglibbed jsp into velocity and although I
>> cleaned up the html (removing 20+ unnecessary nested tables) the
>> filesize of the velocity version was actually slightly bigger than
>> the
>> old version because of all the whitespace.
>>
>> So... I would very much like velocity to perhaps remove whitespace
>> between a directive (i.e. a # statement) and any other code.
>>
>> Paul.
>>
>> Timothy Stone wrote:
>>> List,
>>>
>>> We noticed in #parse'ing an .vm file, excess whitespace, or
>>> linefeeds,
>>> are appearing in our templates after merge.
>>>
>>> For example, where a '+' indicates a line feed or carriage return:
>>>
>>> [mystyles.vm]
>>> +
>>> #set( $foo = "Copyright (c)")
>>> +
>>> #set( $bar = "2006" )
>>> +
>>>
>>>
>>> [myemail.txt]
>>> #parse("mystyles.vm")
>>> +
>>> Dear bloated warthog,
>>> blah
>>> +
>>> blah
>>> +
>>> blah
>>> +
>>> Regards,
>>> Man in Black
>>> +
>>> ${foo} ${bar}
>>>
>>> [The final output]
>>> +
>>> +
>>> +
>>> +
>>> Dear bloated warthog,
>>> blah
>>> +
>>> blah
>>> +
>>> blah
>>> +
>>> Regards,
>>> Man in Black
>>> +
>>> Copyright (c) 2006
>>>
>>> Can these extra lines be managed in some way?
>>>
>>> Thanks,
>>> Tim
>>>
>>>
>>>
>>> --------------------------------------------------------------------
>>> -
>>> To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
>>> For additional commands, e-mail: user-help@velocity.apache.org
>>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
> For additional commands, e-mail: user-help@velocity.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
For additional commands, e-mail: user-help@velocity.apache.org
Re: Whitespace output control
Posted by ap...@recks.org.
See the Wiki on this issue:
http://wiki.apache.org/jakarta-velocity/VelocityWhitespaceGobbling
Please add your opinion (well thought out) or vote for one of the
presented approaches.
Cheers,
Christoph
Paul Loy wrote:
> I would be very interested in a solution to this problem. From a code
> layout point of view this would be an important feature. Consider:
>
> <div>
> "
>
> #if ($somevar)
> $somevar
> #else
> nothing here
> #end
>
> "
> </div>
>
> This nicely formatted code makes it easy to see what's going on but will
> make the html render with spaces in it like so (if $somevar is false or
> null):
>
> ' nothing here '
>
> Now this is a silly example and in this case it would be much easier to
> simply do this to eliminate the problem:
>
>
> <div>
>
> #if ($somevar)
> "$somevar"
> #else
> "nothing here"
> #end
>
> </div>
>
> but in more complex examples you'd either have a great amount of
> duplicated HTML, which makes it bad to maintain and update, or you'd
> have to make unreadable code (everything on one line with no white spaces).
>
> I converted an old nasty taglibbed jsp into velocity and although I
> cleaned up the html (removing 20+ unnecessary nested tables) the
> filesize of the velocity version was actually slightly bigger than the
> old version because of all the whitespace.
>
> So... I would very much like velocity to perhaps remove whitespace
> between a directive (i.e. a # statement) and any other code.
>
> Paul.
>
> Timothy Stone wrote:
>> List,
>>
>> We noticed in #parse'ing an .vm file, excess whitespace, or linefeeds,
>> are appearing in our templates after merge.
>>
>> For example, where a '+' indicates a line feed or carriage return:
>>
>> [mystyles.vm]
>> +
>> #set( $foo = "Copyright (c)")
>> +
>> #set( $bar = "2006" )
>> +
>>
>>
>> [myemail.txt]
>> #parse("mystyles.vm")
>> +
>> Dear bloated warthog,
>> blah
>> +
>> blah
>> +
>> blah
>> +
>> Regards,
>> Man in Black
>> +
>> ${foo} ${bar}
>>
>> [The final output]
>> +
>> +
>> +
>> +
>> Dear bloated warthog,
>> blah
>> +
>> blah
>> +
>> blah
>> +
>> Regards,
>> Man in Black
>> +
>> Copyright (c) 2006
>>
>> Can these extra lines be managed in some way?
>>
>> Thanks,
>> Tim
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
>> For additional commands, e-mail: user-help@velocity.apache.org
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
For additional commands, e-mail: user-help@velocity.apache.org
Re: Whitespace output control
Posted by Paul Loy <pa...@peoplesarchive.com>.
I would be very interested in a solution to this problem. From a code
layout point of view this would be an important feature. Consider:
<div>
"
#if ($somevar)
$somevar
#else
nothing here
#end
"
</div>
This nicely formatted code makes it easy to see what's going on but will
make the html render with spaces in it like so (if $somevar is false or
null):
' nothing here '
Now this is a silly example and in this case it would be much easier to
simply do this to eliminate the problem:
<div>
#if ($somevar)
"$somevar"
#else
"nothing here"
#end
</div>
but in more complex examples you'd either have a great amount of
duplicated HTML, which makes it bad to maintain and update, or you'd
have to make unreadable code (everything on one line with no white spaces).
I converted an old nasty taglibbed jsp into velocity and although I
cleaned up the html (removing 20+ unnecessary nested tables) the
filesize of the velocity version was actually slightly bigger than the
old version because of all the whitespace.
So... I would very much like velocity to perhaps remove whitespace
between a directive (i.e. a # statement) and any other code.
Paul.
Timothy Stone wrote:
> List,
>
> We noticed in #parse'ing an .vm file, excess whitespace, or linefeeds,
> are appearing in our templates after merge.
>
> For example, where a '+' indicates a line feed or carriage return:
>
> [mystyles.vm]
> +
> #set( $foo = "Copyright (c)")
> +
> #set( $bar = "2006" )
> +
>
>
> [myemail.txt]
> #parse("mystyles.vm")
> +
> Dear bloated warthog,
> blah
> +
> blah
> +
> blah
> +
> Regards,
> Man in Black
> +
> ${foo} ${bar}
>
> [The final output]
> +
> +
> +
> +
> Dear bloated warthog,
> blah
> +
> blah
> +
> blah
> +
> Regards,
> Man in Black
> +
> Copyright (c) 2006
>
> Can these extra lines be managed in some way?
>
> Thanks,
> Tim
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
> For additional commands, e-mail: user-help@velocity.apache.org
>
--
*Paul Loy
Software Developer*
Peoples Archive Ltd.
Middlesex House
34-42 Cleveland Street
London, W1T 4LB
Tel: +44 (0) 20 7323 0323
Fax: +44 (0) 20 7580 1938
paul.loy@peoplesarchive.com