Mike,
My earlier message was an attempt to see if we have a good case for
total class generator revamp. This is a sensitive issue in part because
WOProject wogen depends on it. Well, looks like we do have a pretty
strong case. Especially since you volunteer to write it ;-)
On Jan 24, 2004, at 4:40 PM, Mike Kienenberger wrote:
> The current styles I've seen for Velocity templates contain specific
> tools
> and data rather than one giant catch-all object.
...
> And if you should happen to need to manipulate two prop items on the
> same
> template line, you now have to embed additional #set commands in the
> template line.
Ok, I tend to agree now. If you have a complex template, it is nice to
reuse the utility functions with you template variables. I should stop
thinking about Velocity template as some sort of WOComponent :-).
Scripting environment it is...
> My DataObject classes are a bit more complex than the standard Cayenne
> ones
> as I added in support to create a Log table record for every
> update/insert
> on any other Entity, so maybe my experience is unique.
A lot of people want to customize their templates. The approach that
you suggest indeed seems to be better in this respect. Since users
can't reprogram the model Java classes on the fly, extension via
scripting is the only thing they have. So I guess instead of patching
ClassGenerator, we should deprecate it all-together (keeping it in the
template context for backwards compatibility), and create a separate
utility/model classes.
> The package references also should be cleaned up.
> getSuperClass really needs to return a packageless form of the
> superclass.
If we reimplement ClassGenerator fresh, new utilities class can do it
right.
> The ability to specify an alternate template name should be part of
> cgen
> rather than a separate task because it's a trivial addition, and
> greatly
> increases the usefulness of cgen. It makes little sense to
> reimplement
> those three classes simply to change a hardcoded file suffix into a
> parameter. There's no maintenance cost for supporting this.
Ant already supports advanced file name mappings:
http://ant.apache.org/manual/CoreTypes/mapper.html
We can simply support this as a nested element. This is probably more
coding than simple prefix/suffix, but it takes advantage of a very
powerful built in facility. I guess if we go this way, we'll have to
switch Modeler to use ant task as well - so that it would support
everything cgen does. Once cgen is updated, I will take care of the
modeler part.
> http://objectstyle.org/jira/secure/ViewIssue.jspa?key=CAY-79
If we go with a rewrite, I guess we can open a new issue...
Andrus
This archive was generated by hypermail 2.0.0 : Wed Jan 28 2004 - 01:00:57 EST