Andrus Adamchik <andru..bjectstyle.org> wrote:
> On Jan 21, 2004, at 2:34 PM, Mike Kienenberger wrote:
> > I find the prop methodology quite confusing and limiting.
[...]
> >
> > It's unclear to me why there aren't simply
> > public String capitalizeString(String aString)
> > public String javaToUnderscored(String aString)
>
> I don't think it makes much difference either way. Why is it limiting?
> Do you have an example of a specific problem this would solve?
>
> > I think it'd also be less confusing if the context were preloaded with
> > two values, "model" and "utility" rather than "classGen."
> >
> > "model" would contain things like entity and package data values,
> > whereas "utility" would contain capitalizeString, javaToUnderscored,
> > formatVariableName, formatJavaType, and any other utility functions.
>
> I don't see much benefit of doing this - again, are there specific
> cases that would demonstrate the benefits (keeping in mind your second
> message in this thread)?
It turns out that it's probably not limiting so much as confusing. Or maybe
it's just a matter of style.
The current styles I've seen for Velocity templates contain specific tools
and data rather than one giant catch-all object.
I find it clearer to understand the following statement
$utility.capitalizeString($model.attribute.name)
over the statements
#set ($prop = $classgen.attribute.name)
$classgen.getCappedProp()
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.
On the other hand, the first form is longer, but I'm of the school that
clearer-to-read trumps longer-to-type.
It's also easier to do a find and/or replace on the first than on the
second, especially once you start having a lot of $classgen.getCappedProp()s
in the code. When you're putting everything into $prop, it's not always
obvious what $prop contains.
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.
Also, currently there's no explicit documentation on the cgen context.
Using the above methodology is easier to document:
$model in the context maps to the appropriate ObjEntity
$utility maps to a utility class which supports such-and-such
functionality.
All that said, I understand how it works well enough to use it for my own
needs. If there's strong feeling that the current style should be kept, I
won't press.
> > The package references also should be cleaned up.
getSuperClass really needs to return a packageless form of the superclass.
As it is, I have to use ${classGen.superPrefix}${classGen.className} in my
subclass.vm, and that feels like a hack to me.
> > I think I'd also like to rework the target template set so that it's a
> > list of templates to generate against rather than "hardcoding"
superclass
> > and subclass types. Right now, I'm using the task to generate a Struts
> > java action (intialization), a Struts java action (action), and a
velocity
> > web template.
>
> Well, using cgen for things other than Cayenne persistent classes is a
> much bigger thing. We are not trying to be everything to everybody. You
> can definitely subclass cgen and use your own extensions. And it would
> make sense to release such extensions under "cayenne-examples", but we
> need a stronger case on why this should be a part of Cayenne.
My final implementation of this was simply to add the ability to specify a
file prefix and suffix rather than take a list of files.
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.
Examples of use cases are my use case above, going to a three-tier
DataObject class hierarchy, and generating documentation on models. For
comparison, http://www.rubicode.com/Software/ highlights
identically-featured utilities for EOModels.
Note that the patch I submitted in
http://objectstyle.org/jira/secure/ViewIssue.jspa?key=CAY-79
doesn't really contain anything controversial. Well, it might be
controversial that I used $classgen.function() rather than
$classgen.functionProp, but I can change those if it's a problem.
I would like stripPackageName to be in there in some form as well, be it
stripPackageName or stripPackageNameFromProp so one can deal with
classGen.formatJavaType and getSuperClass returning fully-qualified class
names. I used uncapitalizeString() to lowercase Entity names when
generating entityPrefixedVariableNames.
-Mike
This archive was generated by hypermail 2.0.0 : Sat Jan 24 2004 - 16:39:20 EST