> embeddable-superclass.vm > embedable-singleclass.vm Embeddables (the term is JPA-inspired) is a way to model a bunch of persistent attribute as a single class without its own ID. Then an embeddable can be made an attribute of a regular entity. Eventually we probably want them to have properties too. But I don't see a problem if we omit them initially.
> light-superclass.vm This was work in progress by Andrey Razumovsky to unify ROP client and regular server persistent objects per https://issues.apache.org/jira/browse/CAY-1230 . This is a worthy goal, but it is unfinished. My suggestion would actually be to remove this template and the corresponding Modeler template choice from trunk and 3.1, to avoid misleading the end users into thinking that this is a working option. Andrey may comment on this further... For the purpose of CAY-1724 it can certainly be skipped. Andrus On Jul 13, 2012, at 7:30 AM, John Huss wrote: > I think it makes sense add this to these templates: > > superclass.vm > singeclass.vm > client-superclass.vm > > But should the following templates be changed as well? I'm not familiar > with them. > > embeddable-superclass.vm > embedable-singleclass.vm > light-superclass.vm > > On Thu, Jul 12, 2012 at 8:59 AM, John Huss <johnth...@gmail.com> wrote: > >> Ok, if you approve I'll commit this class and a change to the entity >> templates to use it. Then I can do a separate commit to deprecate >> reflect.Property and create a subclass of it called PropertyDescriptor and >> then replace all the references to reflect.Property to >> reflect.PropertyDescriptor. >> >> >> On Thu, Jul 12, 2012 at 1:47 AM, Andrus Adamchik >> <and...@objectstyle.org>wrote: >> >>> I'd still go with the Property... If we have to I'd rather rename >>> reflect.Property to something else (PropertyDescriptor?), as it is much >>> less exposed to the end users, and it would be great to keep simple >>> expressive names for the "public" side of the API. >>> >>> re: package ... org.apache.cayenne.exp looks like a good place for now. >>> While we are at the very early stages of 3.2, we'll still have the freedom >>> to move it around later if we decide this wasn't the right place. >>> >>> Andrus >>> >>> >>> On Jul 11, 2012, at 6:08 PM, Robert Zeigler wrote: >>>> Yes, it will be confusing. :) >>>> >>>> Robert >>>> >>>> On Jul 11, 2012, at 7/119:24 AM , John Huss wrote: >>>> >>>>> Hmm, there is already a Property class in org.apache.cayenne.reflect. >>>>> Where would this go? Perhaps org.apache.cayenne.exp >>>>> or org.apache.cayenne.util? Will it be confusing to have two classes >>> with >>>>> the same name? >>>>> >>>>> John >>>>> >>>>> On Wed, Jul 11, 2012 at 2:04 AM, Andrus Adamchik < >>> and...@objectstyle.org>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 >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>> >>>> >>> >>> >>
