On 7/17/07, Christian Floerkemeier <[EMAIL PROTECTED]> wrote:
>
> My (limited) experience with XSLT for code generation is that transparency
> tends to suffer because the output code is mixed with parsing logic ("No
> seperation of concerns"). There is also no way to visualize how the output
> code will look like. Maintenance of the XSLT code over the project lifecycle
> thus tends to become more difficult.
>
> We are currently looking into Apache Velocity because of its template
> strategy, where the (XML) parsing code is separate from the output
> generation code. One of the benefits of this separation is that the parsing
> code can be reused for different implementations (say java and c#).
>Well I don't think I agree that parsing code or DOM walk code is mixed into XSLT. XSLT is higher level... essentially it is a rule-based language for processing XML and producing output. "Match this XPath and format the found node like this." However, I agree XSLT code is noisy compared to the inversion where you make a template document that mostly looks like what you want but gaps get filled in. XSLT looks very <xsl:whatever> heavy by nature of it being an XML based scripting language. My guess though is based on the the nature of the input vs. the desired final output it is going to get hairy either way. But who knows... it'll be interesting to see how the Velocity stuff turns out. > We just started with the implementation so I cannot really say how well the > template approach works for LLRP code generation. I'll post an update to the > mailing list soon. > cool :-) > John, you mentioned work on a perl implementation. Are you using the perl > template toolkit (http://www.template-toolkit.org/) ? > We use Text::Template extensively. It is a very simple templating mechanism but one that gives you the full power of Perl in your template. I evaluated template-toolkit but didn't like the "near-Perl" nature of it since that would be harder for me to deal with than something that didn't look like Perl at all. Take a look at $/Perl/examples/inventory_example.pl for a simple example of an embedded text template. The problem with Text::Template of course is that it is language specific. I didn't use it in the Perl form of the toolkit, but I do use it in Perl clients of the toolkit. > In our opinion, one thing that should be avoided is code generators which > require manual adjustment after some of the code is generated. The problem > with that is that developers start making changes to the generated code > instead of the code generator. This makes future use of the code generation > tricky if not impossible. One trick to avoid this problem is never to check > the generated source into the version control system. > Go tell it on the mountain (I agree, avoid checking in build products in general). -- John. ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ llrp-toolkit-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/llrp-toolkit-devel
