On Jan 21, 2004, at 2:34 PM, Mike Kienenberger wrote:
> I find the prop methodology quite confusing and limiting.
>
> public void setProp(String prop)
> public String getProp()
> public String getCappedProp()
> public String getPropAsConstantName()
>
> It's unclear to me why there aren't simply
> public String capitalizeString(String aString)
> and
> public String javaToUnderscored(String aString)
> methods.
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 propose adding these two methods (with the guts of both functions in
> NameConverter) and depreciating the prop stuff.
>
> I think it'd also be less confusing if the context were preloaded with
> two
> values, "model" and "utility" rather than "classGen." Again this
> could be
> done with a slow depreciation.
>
> "model" would contain things like entity and package data values,
> whereas
> "utility" would contain capitalizeString, javaToUnderscored,
> formatVariableName, formatJavaType, and any other utility functions.
>
> The package references also should be cleaned up.
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)?
> I'd also like to add a parameter to the ant task to work on a single
> Entity
> rather than generating all entities.
We have an entity filter in DataPort example. We can use something
similar. Though I don't currently have a use for it myself, I can see
how this can be beneficial when you want different groups of entities
to use different templates for instance. This may indeed be a very
useful addition.
> 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.
Andrus
This archive was generated by hypermail 2.0.0 : Sat Jan 24 2004 - 14:09:34 EST