replying to Geir's response (without a copy to velocity-user):

>[snip]
> >
> > * Variables starting with a "_" underscore are not converted
> >   - should be allowed and added to the VL grammar.
> 
> That was a decision made a while ago. It's easy to fix if enough people
> think it's a good idea.  It would make our identifiers conform a little
> better to the java spec. (Can we please get rid of the '-' as an
> acceptable identifier character? How many people are going to regularly
> use 'working-dogs' as a reference, jon? :)

I raised this earlyer and jvz stated that it could be made it this was
really a "standard" and people want it (up to now I'm the only one that
has spoken up).

It would be great if you allow the "_" at the beginning of a variable.

+1 to get rid of the "-".

>[snip]
> > * A #set with a following comment causes a NPE, e.g:
> >   #set $color = "0x8080FF" ## light blue
> 
> Yes, currently the #set is standalone to help keep expression parsing
> reasonable, but this example should be doable.  

Great!

> On the same theme, how
> do people feel about changing to #set( expression ) ?  It will then
> conform to our directive syntax #<directive>( optional arg ) and be
> easier to put in-line in template code.  So you can do things like
> 
> #set($foo = $bar + 2) + 3 bears...
> 
> w/o any muss or fuss.  If people like this ( I do - its different but
> useful), we can put the new one in and try to deprecate the existing
> #set.

I don't believe #sets should be done inline, look how ugly:
#if (!$foo) #set $message = "foo is not defined" #end
(now will this emit whitespace or an EOL?)

>[snip]
> > * Whitespaces around standalone #if, #else, #end are now preserved,
> >   it should be possible to handle them like a #set
> >   - Note that this would also make the VSL templates much more
> >     readable!
I placed further below an example of the site.vsl
> >   ---
> >   #set $bar = true
> >   #if ($foo)
> >       \$foo=>$foo
> >   #else    $foo undefined
> >     #if ($bar)
> >       \$bar=>$bar
> >     #else
> >       $bar undefined
> >     #end
> >   #end
> >   ---
> >   should emit
> >   ---
> >       $foo undefined
> >       $bar=>true
> >   ---
> >   where the first else is not standalone, therefore whitespaces
> >   are untouched, all other directives (even the indented ones)
> >   emit nothing (not even a EOL).
> 
> It does emit that, except for the two spaces before $bar=>true because
> you have the #if indented.
> 
> The current behavior was a conscious decision, not an accident, and was
> presented to the group with both an announcement as well as examples in
> the testbed.  The point is to balance between readable templates and
> controllable output.  It has been argued that whitespace should be
> collapsed on the LHS of a standalone directive.  Currently, whitespace
> is collapsed on the RHS.

I was one of the reviewers, I was waiting for VL to be ready for testing
to see the real impact. The examples in the review did not contain
indented #ifs!

> 
> So directives don't emit the EOL, but they will produce the whitespace
> on the left.

Bad.

> 
> I'll take a whack at fixing that.

Good.

> 
> I had some example of where one would want this, but I forget now :)  We
See jon's anaki VSL templates!
> always have to make sure that all outputs are supported w/o excessive
> contortions on the part of the template writer (in my opinion.)

Take a look at jon's anaki VSL templates an tell me these look nice ;)

Directives should be transparent to the data, therefore if the writer
puts these into own lines (to visually separate them from the code)
and indent them when nested, the whole line should not emit anything.

When directives are inline, they should respect any whitespace around
them.

Jon's templates would look nicer, e.g. compare to the original site.vsl:
#macro ( image $value )
  #if ($value.getAttributeValue("width"))
    #set $width=$value.getAttributeValue("width")
  #end
  #if ($value.getAttributeValue("height"))
    #set $height=$value.getAttributeValue("height")
  #end
  #if ($value.getAttributeValue("align"))
    #set $align=$value.getAttributeValue("align")
  #end
<img src="$relativePath$value.getAttributeValue("src")"##
 width="$!width" height="$!height" align="$!align">
#end
## note that the EOL within the <img...> was escaped with a line comment!
## even a cleaner example further below...

BTW:
1. How can I define reference to a string containing a quote: e.g.:
     #set $width=" width=\"$value.getAttributeValue("width")\""
   is this escaping within a string possible?
2. What happens to the localy defined variables $height, $width
   after the macro returns? Can I have the macro set/change global
   references?

> 
> >
> > * Pluggable directives should contain a flag on the interface that
> >   states if whitespaces should be removed when these are standalone.
> >   A #parse should not touch whitespaches, whereas a #include should
> >   in my opinion work, e.g.:
> >     #set $data.Response.setHeader("content-type", "image/gif")
> >     #set $dummy = $data.getOut()
> >     #include ("/images/logo.gif")
> 
> That is incompatible with your previous argument, I think.   (I assume
> that you mean not the action of the PD, but rather the whitespaces pre
> or post the #<dir>() syntactical element.)
(assumption correct)

I would like to call macros and parse without stripping leading
whitespaces:
  <table>
    <tr>
     #foreach ($td in $tableData)
      <td>
        #set $indent = "        "
        #formatTableData($td, $indent)
      </td>
    </tr>
  </table>
So in this example the macro can indent any continuation line
accordingly.

> 
> I don't agree : I think that they all directives should behave the same
> WRT LHS and RHS whitespace/newline gobbling.  Lets keep things simple.
> You can achieve the above my simply removing what I interpret are two
> spaces before the include.  So.

Sorry, but the real world formatting is not *that* simple :)

> 
> #set $data.Response.setHeader("content-type", "image/gif")
> #set $dummy = $data.getOut()
> #include ("/images/logo.gif")
> 
> should give you the correct output

But what about:
## file: dumpText.vm
#set $filename = $data.Request.getString("filename", "")
#if ($filename == "")
  #call $data.setMessage("no file specified")
#else
  #set $data.Response.setHeader("content-type", "plain/text")
  #set $file = $data.ServletContext.getRealPath($l_fileName)
  #include($file)
#end
This is a nicely formatted template. For parse and macro as 
previous example it is desireable to conserve whitespaces,
whereas set, include, foreach, stop, etc. shall not!

The only problem is when you explicetely want to crop leading
white spaces (due to pretty template formatting), which can be 
done as (above vsl extract example simplified):
#macro ( attribute $node, $name )
  #set $value = $node.getAttributeValue("$name")
  #if ($value)#*
    *# $name="$value"##
  #end
#end
#macro ( image $value )
<img src="$relativePath$value.getAttributeValue("src")"#*
  *# border="0"#*
  *##attribute($value, "width")#* 
  *##attribute($value, "height")#* 
  *##attribute($value, "align")>
#end
And obtain beautifully formated output (avoiding the attributes
that have not been specified!). Note that VL comments #* ... *#
where used to escape EOL and leading spaces. (Will the *## cause
problems to the parser?)

> 
> I will be back friday afternoon to dig into this pile!  (Thanksgiving
> holiday here...)
> 
> Happy Thanksgiving.

Happy turkey day!
(here in Italy/Germany it is not celebrated).

> 
> geir

:) Christoph

Reply via email to