velocity-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christoph.R...@dlr.de
Subject Re: Quick Question.
Date Tue, 10 Sep 2002 13:05:12 GMT


Geir Magnusson Jr. wrote:
> On 9/10/02 8:11 AM, "Anakreon Mejdi" <amejdi@ertonline.gr> wrote:
> 
> 
>>It would do the job.
>>But the best solution would be not to need anything else to produce
>>the correct output.
> 
> 
> I think the point of difference is the definition of 'correct output'

And that is just *the* point I'm adressing.

Currently directives like #set and #end gobble whitespaces around them,
others don't. This is predictable but does not allow writing templates
with structured directive constructs.

The velocity markup should be transparent to the output; therefore,
the real question is: Is the whitespace around a directive part of
the directive?

The answer is not as simple as it seems: the whitespace around a directive
is part of the directive *only* when the designer has placed a directive
on its own line; otherwise, the whitespace is part of the schmoo within
the line and should not be gobbled.

Example 1:
     #if( $foo )
      $bar
     #end
means that the designer wanted to emit an indented $bar by 5 spaces,
currently velocity outputs 9 spaces indentation.

Example 2:
     You typed:#if( $inputField ) '$inputField'#else nothing#end.
Here you get what you typed now and in the future...

Example 3:
#macro( echo $text )$text#end
##...
     #echo("Hello World!")
Here you expect the text output with no leading whitespaces, currently
it does...
Many of my current templates that include other templates via #parse(...)
need to take into account of this extra space, thus their first line is
not indented, the rest is :<
To keep backward compatibitly I will (I already did this in many ones)
need to make the parser know that it is not intended to be a standalone
directive and append a #**# after the statement:
     #parse("path/to/my/file.vm")#**#
But with 'correct output' and whitespace handling I could have designed
the parsed templates without considering the context where they are
parsed.

This is my view of 'correct output'.

-- 
:) Christoph Reck


--
To unsubscribe, e-mail:   <mailto:velocity-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:velocity-user-help@jakarta.apache.org>


Mime
View raw message