[DVSL] Generating VTL with VTL best practices

[Peter Sojan <il...@gmx.net>]

Hi all!

I know there was a thread on the list some time ago, but I just
wanted to know if someone came up with another nice approach to 
generate VTL via DVSL.

Gabriel Sidler came up with the following idea for generating *.vm
files with DVSL: 

------------------------------------------------------------
... approach was to define a tag <vel></vel> in the
style file:

#match ( "vel" )
  $node.value()
#end

and then wrap all VTL directives with this tag. Above example
result in:

<table>
<vel>#foreach ($i in [1, 2, 3, 4, 5])</vel>
  <tr>
    <td>Current index is: $i</td>
  </tr>
<vel>#end</vel>
</table>
-------------------------------------------------------------

This seems to be a working solution, but I have following concern: 

- Is it "politically correct" to include VTL in the originating XML 
  which was ever since supposed to be "logical" markup only? 

On the other hand I have no idea how to solve such a scenario 
coneptionally. One solution would be to write VTL macros, and for 
each of them a logical tag pendant, e.g.: 

  <dyn_custumer_list sort="alpha">

In my *.dvsl I would then simply generate a parametrized VTL macro-call into
a VTL library which gets executed at servlet run time ... 

Any other ideas about this!?


so long
Peter







--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [DVSL] Generating VTL with VTL best practices

["Geir Magnusson Jr." <ge...@optonline.net>]

On 4/7/02 7:44 AM, "Peter Sojan" <il...@gmx.net> wrote:

> 
> Hi all!
> 
> I know there was a thread on the list some time ago, but I just
> wanted to know if someone came up with another nice approach to
> generate VTL via DVSL.
> 
> Gabriel Sidler came up with the following idea for generating *.vm
> files with DVSL: 
> 
> ------------------------------------------------------------
> ... approach was to define a tag <vel></vel> in the
> style file:
> 
> #match ( "vel" )
> $node.value()
> #end
> 
> and then wrap all VTL directives with this tag. Above example
> result in:
> 
> <table>
> <vel>#foreach ($i in [1, 2, 3, 4, 5])</vel>
> <tr>
>   <td>Current index is: $i</td>
> </tr>
> <vel>#end</vel>
> </table>
> -------------------------------------------------------------
> 
> This seems to be a working solution, but I have following concern:
> 
> - Is it "politically correct" to include VTL in the originating XML
> which was ever since supposed to be "logical" markup only?


I think it really depends on what you are doing.

There are things will cause problems, like pre-styled output as then you've
taken away the style-neutrality of the data.  But if what you are including
doesn't affect the freedom of the transformation process, then it seems like
you aren't causing harm.

For example, the document may be only bits of VTL - you may have some VTL
generator that uses those bits to compose the structure of templates, with
the content for those templates coming from some other place.

I would be very cautious about mixing content and style info in the same doc
though.

> 
> On the other hand I have no idea how to solve such a scenario
> coneptionally. One solution would be to write VTL macros, and for
> each of them a logical tag pendant, e.g.:
> 
> <dyn_custumer_list sort="alpha">
> 
> In my *.dvsl I would then simply generate a parametrized VTL macro-call into
> a VTL library which gets executed at servlet run time ...

That would work too - the difference is that you are reusing an existing
library, where the former <vel> solution allows you to setup one-off code
bits..

geir
 
> Any other ideas about this!?
> 
> 
> so long
> Peter
> 
> 
> 
> 
> 
> 
> 
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> 

-- 
Geir Magnusson Jr.                                     geirm@optonline.net
System and Software Consulting
Java : the speed of Smalltalk with the simple elegance of C++... 


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>