You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cayenne.apache.org by Michael Gentry <bl...@gmail.com> on 2008/02/25 15:43:14 UTC
Extended Enumerations
I did some work on extended enumerations (where the DB value can be
defined) this weekend, but wanted to do more testing and get a little
feedback before checking it in. I apologize in advance for the length
of the e-mail, but hopefully it won't be too bad.
First off, there is a new interface to implement in your Enum to flag
it as a Cayenne extended enumeration. I initially had
IntegerEnumeration and StringEnumeration, but then boiled it down to
one. I'll leave it that way unless there are compelling reasons not
to.
public interface ExtendedEnumeration
{
// Return the value to be stored in the database for this enumeration. In
// actuallity, this should be an Integer or a String.
public Object databaseValue();
}
Here are examples of the enumerations I used for testing:
// String example
public enum State implements ExtendedEnumeration
{
ALABAMA("AL"), ALASKA("AK"), ARIZONA("AZ"), MARYLAND("MD"), VIRGINIA("VA");
private String value;
private State(String value)
{
this.value = value;
}
public String databaseValue()
{
return value;
}
}
// Integer example
public enum Color implements ExtendedEnumeration
{
RED(3), GREEN(6), BLUE(9);
private Integer value;
private Color(Integer value)
{
this.value = value;
}
public Integer databaseValue()
{
return value;
}
}
// Integer example where stored value is different than the value you
want to use at runtime
public enum InterestTerm implements ExtendedEnumeration
{
YEARLY(1, 1), QUARTERLY(2, 4), MONTHLY(3, 12);
private Integer dbValue;
private int value;
private InterestTerm(Integer dbValue, int value)
{
this.dbValue = dbValue;
this.value = value;
}
public Integer databaseValue()
{
return dbValue;
}
public int value()
{
return value;
}
}
My sample code using it:
user = dataContext.newObject(User.class);
user.setFavoriteColor(Color.RED);
user.setInterestTerm(InterestTerm.MONTHLY);
user.setLocation(State.ALABAMA);
user.setName("Joe Alabama");
user = dataContext.newObject(User.class);
user.setFavoriteColor(Color.GREEN);
user.setInterestTerm(InterestTerm.QUARTERLY);
user.setLocation(State.ARIZONA);
user.setName("Jose Arizona");
user = dataContext.newObject(User.class);
user.setFavoriteColor(Color.BLUE);
user.setInterestTerm(InterestTerm.YEARLY);
user.setLocation(State.VIRGINIA);
user.setName("Josephine Virginia");
There is currently no Cayenne Modeler support -- you just type the
full class name for your enum for the ObjEntity column type. I'm not
sure if it is required or desired to add support, either. If we do, I
think we should add a value() method to the interface. This could be
useful for localization of string values. For example, you have a
pulldown list of values that is static with specified values in the
DB, but want to present them to the user in their specific languages.
Of course, if the developer needs to do more magic in the value()
method than what CM would generate, then you get into a maintenance
headache with the code generation.
Feedback appreciated.
Thanks!
/dev/mrg
Re: Extended Enumerations
Posted by Michael Gentry <bl...@gmail.com>.
Hi Ari, attachments don't come through the list, so if you want to,
just shoot it to me directly. I suspect what you have might be pretty
similar to the Extended Types I implemented for Cayenne 1.2/2.0
without Java 1.5 enums and supported Integer/String types. What I had
then was more complicated/functional, because it included localization
support, which I'm not trying to do right now.
Thanks!
/dev/mrg
On Mon, Feb 25, 2008 at 5:44 PM, Aristedes Maniatis <ar...@ish.com.au> wrote:
>
> On 26/02/2008, at 1:43 AM, Michael Gentry wrote:
>
> > I did some work on extended enumerations (where the DB value can be
> > defined) this weekend
>
> Interesting. If this list passes through my attachments, I've included
> some classes from our ROP project which might help give you another
> example of how this might be used. They are ExtendedTypeIntegerEnum
> which is an interface implemented by IntegerEnumType (server side
> only) and ClassCostType (an example enumeration which is available to
> both client and server).
>
>
>
>
>
>
> The naming and docs could be better but it works pretty well. Despite
> the copyright headers, you have permission to use any bits of this you
> find useful. As you can see, the approach is quite similar: a
> persistent value and a display value (for popup menus for instance)
> declared in the constructor.
>
>
> Ari
>
>
>
>
> -------------------------->
> ish
> http://www.ish.com.au
> Level 1, 30 Wilson Street Newtown 2042 Australia
> phone +61 2 9550 5001 fax +61 2 9550 4001
> GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
>
>
>
>
Re: Extended Enumerations
Posted by Michael Gentry <bl...@gmail.com>.
Hi Marcin,
When I split up the enum type handling (standard versus extended) as
suggested by Andrus, I can clean up that EnumType<T extends Enum<T>>
bit, I think. The current EnumType which I checked in is supporting
two different types of enum, some of which implement
ExtendedEnumeration and some which do not, so I couldn't lock it down
to ExtendedEnumeration.
I believe for other custom extended types to auto-register themselves,
they'd have to implement an interface so Cayenne could map the values.
It has been a long time since I looked specifically at that. Perhaps
Andrus or another will correct me if I'm wrong on that matter. I'm
not saying it wouldn't be nice, though.
Thanks,
/dev/mrg
On Mon, Mar 3, 2008 at 1:06 AM, Marcin Skladaniec <ma...@ish.com.au> wrote:
> Hi
>
> The EnumType will be very handy indeed. I've read the code and have a
> couple of questions:
>
> EnumType<T extends Enum<T>> made my head square and then round again,
> I dont understand it. Wouldn't a simpler EnumType<T extends
> ExtendedEnumeration> do ?
>
> Would that be possible to make so all the ExtendedTypes (or just
> EnumType) would be auto-registered in the Node ? I believe it could
> be done during the configuration initialization or when the node is
> first accessed. Right now all the extended types must be registered,
> and if you forget to do so it will only come up when the
> materializeObject() method lookup will fail (from my experience
> setJdbcObject will work somehow using enum ordinal() and will not
> throw any exception).
> From different perspective: why would someone add a custom java type
> as a attribute and not register it ? Maybe it should be another part
> of the model/modeler where user defines available java types together
> with their *Type classes ?
>
> Best regards
> Marcin
>
> -------------------------->
> ish
> http://www.ish.com.au
> Level 1, 30 Wilson Street Newtown 2042 Australia
> phone +61 2 9550 5001 fax +61 2 9550 4001
>
>
>
>
>
>
> On 03/03/2008, at 3:13 AM, Michael Gentry wrote:
>
> > http://cwiki.apache.org/confluence/display/CAYDOC/Extended+Types
> >
> > First cut is checked into SVN. If no problems, I'll add a couple more
> > features sometime. I especially want to add localization support for
> > GUI developers.
> >
> > Thanks,
> >
> > /dev/mrg
> >
> > PS. Ari, I've never used ROP and I think you are the big ROP guy. If
> > you get a chance sometime, please test it a bit with ROP and let me
> > know if there are issues. Thanks!
>
>
Re: Extended Enumerations
Posted by Marcin Skladaniec <ma...@ish.com.au>.
Hi
The EnumType will be very handy indeed. I've read the code and have a
couple of questions:
EnumType<T extends Enum<T>> made my head square and then round again,
I dont understand it. Wouldn't a simpler EnumType<T extends
ExtendedEnumeration> do ?
Would that be possible to make so all the ExtendedTypes (or just
EnumType) would be auto-registered in the Node ? I believe it could
be done during the configuration initialization or when the node is
first accessed. Right now all the extended types must be registered,
and if you forget to do so it will only come up when the
materializeObject() method lookup will fail (from my experience
setJdbcObject will work somehow using enum ordinal() and will not
throw any exception).
From different perspective: why would someone add a custom java type
as a attribute and not register it ? Maybe it should be another part
of the model/modeler where user defines available java types together
with their *Type classes ?
Best regards
Marcin
-------------------------->
ish
http://www.ish.com.au
Level 1, 30 Wilson Street Newtown 2042 Australia
phone +61 2 9550 5001 fax +61 2 9550 4001
On 03/03/2008, at 3:13 AM, Michael Gentry wrote:
> http://cwiki.apache.org/confluence/display/CAYDOC/Extended+Types
>
> First cut is checked into SVN. If no problems, I'll add a couple more
> features sometime. I especially want to add localization support for
> GUI developers.
>
> Thanks,
>
> /dev/mrg
>
> PS. Ari, I've never used ROP and I think you are the big ROP guy. If
> you get a chance sometime, please test it a bit with ROP and let me
> know if there are issues. Thanks!
Re: Extended Enumerations
Posted by Michael Gentry <bl...@gmail.com>.
http://cwiki.apache.org/confluence/display/CAYDOC/Extended+Types
First cut is checked into SVN. If no problems, I'll add a couple more
features sometime. I especially want to add localization support for
GUI developers.
Thanks,
/dev/mrg
PS. Ari, I've never used ROP and I think you are the big ROP guy. If
you get a chance sometime, please test it a bit with ROP and let me
know if there are issues. Thanks!
Re: Extended Enumerations
Posted by Michael Gentry <bl...@gmail.com>.
The original enum code by Andrus only accounted for strings/ints, too.
If there is a compelling argument later to support additional basic
types, I think that can be handled. I was talking with a co-worker
and he suggested dates. The more we talked about it, though, the less
it made sense. For example, if you had a Holidays enum, the Java date
also contains the year. That makes it less useful, plus you have
holidays (Easter) that shift around ever year. It just didn't seem
reasonable to make a sort-of constant out of something like that. I'm
not claiming I've thought of every possible usage, but supporting
string/int seems a good start.
Thanks,
/dev/mrg
On Thu, Feb 28, 2008 at 5:45 AM, Aristedes Maniatis <ar...@ish.com.au> wrote:
> Great. That's good for me too, since whatever you add will be easy
> enough for me to incorporate in our work and I'll give you my +1 now
> for adding it to Cayenne :-)
>
> Please pinch anything from it you find useful. Without thinking about
> it deeply though, it does seem possible that this API could be
> generified to be more useful, although in 99% of cases a user will
> want integer database values and string user interface values.
>
> Ari
>
>
>
>
>
>
> On 28/02/2008, at 3:01 AM, Michael Gentry wrote:
>
> > Ari, I took a glance at the code you sent me and on first look, it
> > appears to be similar to what I did for my Cayenne 1.2/2.0 enum
> > support (using Java 1.4 only, though) and the current stuff I'm
> > adding. I'll get to work on it again in the next few days, but wanted
> > to give you a little feedback.
> >
> > Thanks,
> >
> > /dev/mrg
> >
> >
> > On Mon, Feb 25, 2008 at 5:44 PM, Aristedes Maniatis <ar...@ish.com.au>
> > wrote:
> >>
> >> On 26/02/2008, at 1:43 AM, Michael Gentry wrote:
> >>
> >>> I did some work on extended enumerations (where the DB value can be
> >>> defined) this weekend
> >>
> >> Interesting. If this list passes through my attachments, I've
> >> included
> >> some classes from our ROP project which might help give you another
> >> example of how this might be used. They are ExtendedTypeIntegerEnum
> >> which is an interface implemented by IntegerEnumType (server side
> >> only) and ClassCostType (an example enumeration which is available to
> >> both client and server).
> >>
> >>
> >>
> >>
> >>
> >>
> >> The naming and docs could be better but it works pretty well. Despite
> >> the copyright headers, you have permission to use any bits of this
> >> you
> >> find useful. As you can see, the approach is quite similar: a
> >> persistent value and a display value (for popup menus for instance)
> >> declared in the constructor.
> >>
> >>
> >> Ari
> >>
> >>
> >>
> >>
> >> -------------------------->
> >> ish
> >> http://www.ish.com.au
> >> Level 1, 30 Wilson Street Newtown 2042 Australia
> >> phone +61 2 9550 5001 fax +61 2 9550 4001
> >> GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
> >>
> >>
> >>
> >>
>
>
>
>
>
> -------------------------->
> ish
> http://www.ish.com.au
> Level 1, 30 Wilson Street Newtown 2042 Australia
> phone +61 2 9550 5001 fax +61 2 9550 4001
> GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
>
>
>
Re: Extended Enumerations
Posted by Aristedes Maniatis <ar...@ish.com.au>.
Great. That's good for me too, since whatever you add will be easy
enough for me to incorporate in our work and I'll give you my +1 now
for adding it to Cayenne :-)
Please pinch anything from it you find useful. Without thinking about
it deeply though, it does seem possible that this API could be
generified to be more useful, although in 99% of cases a user will
want integer database values and string user interface values.
Ari
On 28/02/2008, at 3:01 AM, Michael Gentry wrote:
> Ari, I took a glance at the code you sent me and on first look, it
> appears to be similar to what I did for my Cayenne 1.2/2.0 enum
> support (using Java 1.4 only, though) and the current stuff I'm
> adding. I'll get to work on it again in the next few days, but wanted
> to give you a little feedback.
>
> Thanks,
>
> /dev/mrg
>
>
> On Mon, Feb 25, 2008 at 5:44 PM, Aristedes Maniatis <ar...@ish.com.au>
> wrote:
>>
>> On 26/02/2008, at 1:43 AM, Michael Gentry wrote:
>>
>>> I did some work on extended enumerations (where the DB value can be
>>> defined) this weekend
>>
>> Interesting. If this list passes through my attachments, I've
>> included
>> some classes from our ROP project which might help give you another
>> example of how this might be used. They are ExtendedTypeIntegerEnum
>> which is an interface implemented by IntegerEnumType (server side
>> only) and ClassCostType (an example enumeration which is available to
>> both client and server).
>>
>>
>>
>>
>>
>>
>> The naming and docs could be better but it works pretty well. Despite
>> the copyright headers, you have permission to use any bits of this
>> you
>> find useful. As you can see, the approach is quite similar: a
>> persistent value and a display value (for popup menus for instance)
>> declared in the constructor.
>>
>>
>> Ari
>>
>>
>>
>>
>> -------------------------->
>> ish
>> http://www.ish.com.au
>> Level 1, 30 Wilson Street Newtown 2042 Australia
>> phone +61 2 9550 5001 fax +61 2 9550 4001
>> GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
>>
>>
>>
>>
-------------------------->
ish
http://www.ish.com.au
Level 1, 30 Wilson Street Newtown 2042 Australia
phone +61 2 9550 5001 fax +61 2 9550 4001
GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
Re: Extended Enumerations
Posted by Michael Gentry <bl...@gmail.com>.
Ari, I took a glance at the code you sent me and on first look, it
appears to be similar to what I did for my Cayenne 1.2/2.0 enum
support (using Java 1.4 only, though) and the current stuff I'm
adding. I'll get to work on it again in the next few days, but wanted
to give you a little feedback.
Thanks,
/dev/mrg
On Mon, Feb 25, 2008 at 5:44 PM, Aristedes Maniatis <ar...@ish.com.au> wrote:
>
> On 26/02/2008, at 1:43 AM, Michael Gentry wrote:
>
> > I did some work on extended enumerations (where the DB value can be
> > defined) this weekend
>
> Interesting. If this list passes through my attachments, I've included
> some classes from our ROP project which might help give you another
> example of how this might be used. They are ExtendedTypeIntegerEnum
> which is an interface implemented by IntegerEnumType (server side
> only) and ClassCostType (an example enumeration which is available to
> both client and server).
>
>
>
>
>
>
> The naming and docs could be better but it works pretty well. Despite
> the copyright headers, you have permission to use any bits of this you
> find useful. As you can see, the approach is quite similar: a
> persistent value and a display value (for popup menus for instance)
> declared in the constructor.
>
>
> Ari
>
>
>
>
> -------------------------->
> ish
> http://www.ish.com.au
> Level 1, 30 Wilson Street Newtown 2042 Australia
> phone +61 2 9550 5001 fax +61 2 9550 4001
> GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
>
>
>
>
Re: Extended Enumerations
Posted by Aristedes Maniatis <ar...@ish.com.au>.
On 26/02/2008, at 1:43 AM, Michael Gentry wrote:
> I did some work on extended enumerations (where the DB value can be
> defined) this weekend
Interesting. If this list passes through my attachments, I've included
some classes from our ROP project which might help give you another
example of how this might be used. They are ExtendedTypeIntegerEnum
which is an interface implemented by IntegerEnumType (server side
only) and ClassCostType (an example enumeration which is available to
both client and server).
Re: Extended Enumerations
Posted by Michael Gentry <bl...@gmail.com>.
I can play around with the first suggestion later this week. I'm not
adamant either way. I just want what is best for the end-user, even
if the underlying Cayenne code is a bit more complex.
Changing the method name to getDatabaseValue() is fine.
Thanks,
/dev/mrg
On Mon, Feb 25, 2008 at 11:47 AM, Kevin Menard <km...@servprise.com> wrote:
> Right. What I was suggesting was being able to do:
>
> public interface MyInterface extends ExtendedEnumeration<String>
> {
> public String databaseValue();
> }
>
> And the Cayenne bit could just accept Object anyway.
>
> As another suggested improvement, it'd probably be useful to rename
> databaseValue to adhere to the JavaBeans naming convention. It would
> make introspection a bit easier.
>
> --
>
> Kevin Menard
> Servprise International, Inc.
> Remote reboot & power control for your network
> www.servprise.com +1 508.892.3823 x308
RE: Extended Enumerations
Posted by Kevin Menard <km...@servprise.com>.
Right. What I was suggesting was being able to do:
public interface MyInterface extends ExtendedEnumeration<String>
{
public String databaseValue();
}
And the Cayenne bit could just accept Object anyway.
As another suggested improvement, it'd probably be useful to rename
databaseValue to adhere to the JavaBeans naming convention. It would
make introspection a bit easier.
--
Kevin Menard
Servprise International, Inc.
Remote reboot & power control for your network
www.servprise.com +1 508.892.3823 x308
> -----Original Message-----
> From: Michael Gentry [mailto:blacknext@gmail.com]
> Sent: Monday, February 25, 2008 11:32 AM
> To: dev@cayenne.apache.org
> Subject: Re: Extended Enumerations
>
> By typing, I assume you mean the return type? That's why I originally
> had two different interfaces:
>
> public interface IntegerEnumeration
> {
> public Integer databaseValue();
> }
>
> public interface StringEnumeration
> {
> public String databaseValue();
> }
>
> I then decided to collapse it down into one thinking that might be
> easier on the user. Cayenne internally does care which one it is (I
> use instanceof Integer/String on the return value to determine it).
> It actually made the Cayenne code a tad easier to deal with only one
> interface, but the real answer is if it is better for the end-user to
> only have to deal with one interface (I think).
>
> Thanks,
>
> /dev/mrg
>
>
> On Mon, Feb 25, 2008 at 11:18 AM, Kevin Menard <km...@servprise.com>
> wrote:
> > All in all, this looks like a good step in the right direction. I
> might
> > recommend typing ExtendedEnumeration. You may even be able to
> constrain
> > the domain to both String & Integer via wildcards, but that'd
likely
> be
> > an evil beast to inflict on someone. That would allow you to
> tighten
> > the contract on the return type though (or at least force the
> developer
> > to specify it).
> >
> > On the other hand, if I always work with String or Integer, it
could
> get
> > annoying to type it every time, especially if Cayenne ultimately
> doesn't
> > care.
> >
> > --
> > Kevin Menard
> > Servprise International, Inc.
> > Remote reboot & power control for your network
> > www.servprise.com +1 508.892.3823 x308
Re: Extended Enumerations
Posted by Michael Gentry <bl...@gmail.com>.
By typing, I assume you mean the return type? That's why I originally
had two different interfaces:
public interface IntegerEnumeration
{
public Integer databaseValue();
}
public interface StringEnumeration
{
public String databaseValue();
}
I then decided to collapse it down into one thinking that might be
easier on the user. Cayenne internally does care which one it is (I
use instanceof Integer/String on the return value to determine it).
It actually made the Cayenne code a tad easier to deal with only one
interface, but the real answer is if it is better for the end-user to
only have to deal with one interface (I think).
Thanks,
/dev/mrg
On Mon, Feb 25, 2008 at 11:18 AM, Kevin Menard <km...@servprise.com> wrote:
> All in all, this looks like a good step in the right direction. I might
> recommend typing ExtendedEnumeration. You may even be able to constrain
> the domain to both String & Integer via wildcards, but that'd likely be
> an evil beast to inflict on someone. That would allow you to tighten
> the contract on the return type though (or at least force the developer
> to specify it).
>
> On the other hand, if I always work with String or Integer, it could get
> annoying to type it every time, especially if Cayenne ultimately doesn't
> care.
>
> --
> Kevin Menard
> Servprise International, Inc.
> Remote reboot & power control for your network
> www.servprise.com +1 508.892.3823 x308
RE: Extended Enumerations
Posted by Kevin Menard <km...@servprise.com>.
All in all, this looks like a good step in the right direction. I might
recommend typing ExtendedEnumeration. You may even be able to constrain
the domain to both String & Integer via wildcards, but that'd likely be
an evil beast to inflict on someone. That would allow you to tighten
the contract on the return type though (or at least force the developer
to specify it).
On the other hand, if I always work with String or Integer, it could get
annoying to type it every time, especially if Cayenne ultimately doesn't
care.
--
Kevin Menard
Servprise International, Inc.
Remote reboot & power control for your network
www.servprise.com +1 508.892.3823 x308
> -----Original Message-----
> From: Michael Gentry [mailto:blacknext@gmail.com]
> Sent: Monday, February 25, 2008 9:43 AM
> To: dev@cayenne.apache.org
> Subject: Extended Enumerations
>
> I did some work on extended enumerations (where the DB value can be
> defined) this weekend, but wanted to do more testing and get a little
> feedback before checking it in. I apologize in advance for the length
> of the e-mail, but hopefully it won't be too bad.
>
> First off, there is a new interface to implement in your Enum to flag
> it as a Cayenne extended enumeration. I initially had
> IntegerEnumeration and StringEnumeration, but then boiled it down to
> one. I'll leave it that way unless there are compelling reasons not
> to.
>
>
> public interface ExtendedEnumeration
> {
> // Return the value to be stored in the database for this
> enumeration. In
> // actuallity, this should be an Integer or a String.
> public Object databaseValue();
> }
>
>
> Here are examples of the enumerations I used for testing:
>
>
> // String example
> public enum State implements ExtendedEnumeration
> {
> ALABAMA("AL"), ALASKA("AK"), ARIZONA("AZ"), MARYLAND("MD"),
> VIRGINIA("VA");
>
> private String value;
>
> private State(String value)
> {
> this.value = value;
> }
>
> public String databaseValue()
> {
> return value;
> }
> }
>
> // Integer example
> public enum Color implements ExtendedEnumeration
> {
> RED(3), GREEN(6), BLUE(9);
>
> private Integer value;
>
> private Color(Integer value)
> {
> this.value = value;
> }
>
> public Integer databaseValue()
> {
> return value;
> }
> }
>
> // Integer example where stored value is different than the value you
> want to use at runtime
> public enum InterestTerm implements ExtendedEnumeration
> {
> YEARLY(1, 1), QUARTERLY(2, 4), MONTHLY(3, 12);
>
> private Integer dbValue;
> private int value;
>
> private InterestTerm(Integer dbValue, int value)
> {
> this.dbValue = dbValue;
> this.value = value;
> }
>
> public Integer databaseValue()
> {
> return dbValue;
> }
>
> public int value()
> {
> return value;
> }
> }
>
>
> My sample code using it:
>
>
> user = dataContext.newObject(User.class);
> user.setFavoriteColor(Color.RED);
> user.setInterestTerm(InterestTerm.MONTHLY);
> user.setLocation(State.ALABAMA);
> user.setName("Joe Alabama");
>
> user = dataContext.newObject(User.class);
> user.setFavoriteColor(Color.GREEN);
> user.setInterestTerm(InterestTerm.QUARTERLY);
> user.setLocation(State.ARIZONA);
> user.setName("Jose Arizona");
>
> user = dataContext.newObject(User.class);
> user.setFavoriteColor(Color.BLUE);
> user.setInterestTerm(InterestTerm.YEARLY);
> user.setLocation(State.VIRGINIA);
> user.setName("Josephine Virginia");
>
>
> There is currently no Cayenne Modeler support -- you just type the
> full class name for your enum for the ObjEntity column type. I'm not
> sure if it is required or desired to add support, either. If we do, I
> think we should add a value() method to the interface. This could be
> useful for localization of string values. For example, you have a
> pulldown list of values that is static with specified values in the
> DB, but want to present them to the user in their specific languages.
> Of course, if the developer needs to do more magic in the value()
> method than what CM would generate, then you get into a maintenance
> headache with the code generation.
>
> Feedback appreciated.
>
> Thanks!
>
> /dev/mrg