On May 12, 2005, at 11:57 AM, Mike Kienenberger wrote:
>> Something like that? Or perhaps with a sub-element for <header>?
>> For sub-element support, you would have a "public void Header
>> createHeader()" method that returns back a Header Java bean with the
>> addText method on it (it could be an inner class).
>>
>
> I was thinking more like
>
> <cayenne:cgen map="config/CollexDomainMap.map.xml"
> destDir="${build.dir}/gen"
> superpkg="org.patacriticism.collex.model.cayenne">
>
> license="// This is my license header"
> or
> licensefile="license.txt"
> </cayenne:gen>
>
> I know I could do it with two separate attributes, but I was
> wondering if
> there's a common ant element that already handles these kinds of
> attributes
> (file contents or constant string).
No, there is nothing in Ant (that I know of) that handles this any
better than you've described. For example, in Ant's <fileset>
element, you can have an "includes" attribute or an "includesfile"
attribute.
>>> Third, I'm considering providing a "version", "compiler",
>>> "templater", or
>>> "target" attribute for class generation along the lines of the
>>> "compiler"
>>> javac task. "1.1" would be how things are done now (single
>>> "classgen").
>>> "1.2" would be how I want to redesign things. Any comments or
>>> preferences?
>>> The default for "version" would be 1.1 for now.
>>>
>>
>> Maybe this could be made into two separate Ant tasks, such that the
>> legacy "classgen" one is deprecated? They could share the same base
>> class in order to share attributes and such.
>>
>
> What's your reasoning for two tasks rather than one with a switch?
> One with
> a switch allows us to control default behavior while still giving the
> advanced user the ability to change behavior.
My only rationale was to have a task you could easily remove later
without any legacy cruft left around. With a switch like you've
described, it seems it could linger longer than you'd like. No other
reason than that and I have no objections to the switch.
> Yeah, it's easy to add in, which is why I don't mind doing it. :)
>
> #if ($footerAvailable)
> #parse ($footer)
> #endif
Why bother with the #if? You could have built-in header and footer
templates coming from a classpath loader with the filesystem loader
ahead.
> Is there a common use case for supporting more than extra methods
> at the
> bottom?
> Anything more than the common case should probably be done by
> creating new
> templates.
With the filesystem loader in place, my custom footer.vm could #parse
to my own sub-templates if I wanted. :)
Erik
This archive was generated by hypermail 2.0.0 : Thu May 12 2005 - 15:54:29 EDT