RE: Extended Enumerations

From: Kevin Menard (kmenar..ervprise.com)
Date: Mon Feb 25 2008 - 11:18:37 EST

  • Next message: Michael Gentry: "Re: Extended Enumerations"

    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:blacknex..mail.com] > Sent: Monday, February 25, 2008 9:43 AM > To: de..ayenne.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



    This archive was generated by hypermail 2.0.0 : Mon Feb 25 2008 - 11:19:15 EST