> > 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).
Sorry, didn't mean to sound like a "wise guy" :). Just noticed that there
seemed to be some generated code already checked into the CVS. (- not sure
whether this was done for initial prototyping only).
- Christian
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On
> Behalf Of John R. Hogerhuis
> Sent: Dienstag, 17. Juli 2007 18:01
> To: LLRP Toolkit Development List
> Subject: Re: [ltk-d] XML LLRP description
>
> 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
>
-------------------------------------------------------------------------
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
