Yeah, maintaining multiple versions of the template is somewhat of a pain for us (we need better tests I guess, otherwise it is very easy to miss when the old template stops working). And locating the old template and setting up their projects to use it will be a pain for the users.
So while we can provide both versions in 3.2, my vote would be for @Deprecated annotation. Andrus On Aug 9, 2012, at 5:39 AM, Mike Kienenberger wrote: > cgen used to support a version argument, and we had both a 1.1 and 1.2 > version of templates. But it's a pain to have to maintain such > things. > > And is this change really going to change what the generator does? > Probably not. It's only going to change the default template. The > old template would still work, wouldn't it? > > On Wed, Aug 8, 2012 at 2:52 PM, John Huss <[email protected]> wrote: >> On Wed, Aug 8, 2012 at 12:34 PM, Andrus Adamchik >> <[email protected]>wrote: >> >>> I am now experimenting with the new class generation too. Since Property >>> is simply a singleton wrapper of a String name, it is pretty lightweight >>> IMO. >>> >>> But now I am wondering whether we still need String constants for property >>> names? My main use of those was always when building qualifiers. Now this >>> will be handled via Properties. Besides you can do MY_PROP.getName(). >>> >>> So do we need this extra redundancy in declarations, making the class less >>> readable? Or should we just keep the Property kind? >>> >> >> I would vote for deprecating and then removing the string constants. >> >> Have you thought about including multiple revisions of the templates to >> allow people to stick with older ones if they want to? Or are they >> responsible for finding the old file in the source and putting in their app >> if they don't want to change? >> >> John >> >> On Aug 3, 2012, at 4:57 AM, Michael Gentry wrote: >>>> I'm a bit delayed and just saw this ... >>>> >>>> I'm curious how much extra overhead this will add to each Cayenne >>>> class? Probably not a huge issue since it is declared statically, but >>>> I'm still curious. >>>> >>>> Thanks, >>>> >>>> mrg >>>> >>>> >>>> On Wed, Jul 11, 2012 at 3:04 AM, Andrus Adamchik <[email protected]> >>> wrote: >>>>> +1. I saw it used on one project and it was a nice concept. >>>>> >>>>> Andrus >>>>> >>>>> On Jul 11, 2012, at 7:30 AM, John Huss (JIRA) wrote: >>>>> >>>>>> John Huss created CAY-1724: >>>>>> ------------------------------ >>>>>> >>>>>> Summary: Add 'Property' class for easier and better >>> Expression creation >>>>>> Key: CAY-1724 >>>>>> URL: https://issues.apache.org/jira/browse/CAY-1724 >>>>>> Project: Cayenne >>>>>> Issue Type: Improvement >>>>>> Components: Core Library >>>>>> Affects Versions: 3.2M1 >>>>>> Reporter: John Huss >>>>>> Priority: Minor >>>>>> Attachments: Property.java >>>>>> >>>>>> Project Wonder (WebObjects) has a class which is basically just a >>> wrapper around an attribute or relationship name that gives you a way to >>> create Expressions in type-safe manner and with minimal effort. Also sort >>> orderings can be easily generated. In Wonder, these "property" objects are >>> part of the entity template so they are generated automatically. >>>>>> >>>>>> So for example: >>>>>> >>>>>> public class _Artist extends CayenneDataObject { >>>>>> public static final Property<String> NAME = new >>> Property<String>(NAME_PROPERTY); >>>>>> ... >>>>>> } >>>>>> >>>>>> Then client code can do things like: >>>>>> >>>>>> new SelectQuery(Artist.class, NAME.eq("Pablo").andExp(AGE.gt(40)), >>> AGE.descs()); >>>>>> >>>>>> This would select all artists with name equal to Pablo and age greater >>> than 40 and order them in descending age order. >>>>>> >>>>>> This concept has been proven to work incredibly well with WebObjects. >>> It's almost as readable as using plain strings but has complete >>> compile-time checking for the property name and the type of the objects it >>> is compared with. >>>>>> >>>>>> A complete implementation is attached. It's very simple since >>> ExpressionFactory does the work. If this is accepted, it would make sense >>> to modify the built-in entity templates to generate Property constants for >>> all of the properties. >>>>>> >>>>>> -- >>>>>> This message is automatically generated by JIRA. >>>>>> If you think it was sent incorrectly, please contact your JIRA >>> administrators: >>> https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa >>>>>> For more information on JIRA, see: >>> http://www.atlassian.com/software/jira >>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >>> >
