Hi Mark, I favor using an INT to identify the type and I use Properties entries to map to java classes, like shown below.
CampaignBehaviour.10 = wk.cheetah.eof.JobsiteRadiusCampaignBehaviour CampaignBehaviour.70 = wk.cheetah.eof.BirthdayRadiusCampaignBehaviour CampaignBehaviour.80 = wk.cheetah.eof.B2bCampaignBehaviour CampaignBehaviour.90 = wk.cheetah.eof.NewMoverCampaignBehaviour CampaignBehaviour.110 = wk.cheetah.eof.MyMailshopCampaignBehaviour I use a convention of <interface-name>.<type-id> and lazily construct the behaviour class internal to the EO instance. So for replacement of traditional inheritance or for refactoring existing single-table inheritance into a single entity with behaviours, I might typically start with one behaviour and use the existing 'type' values that exist in the db table. However you can obviously have multiple behaviours mapped to multiple attributes. For me, this has made my life easy, and adding new behaviours is as easy as adding a new class and a new property - no eomodel or schema changes. -Kieran On Apr 2, 2010, at 3:13 AM, Mark Wardle wrote: > (the reason I ask is that I find myself needing to select different java > logic depending on instance - with a reference to the logic class generated > (lazily) based on the class name as stored in the database. I've always > wondered whether there is a better way.....?) > > B/w mark > > -- > Dr. Mark Wardle > Specialist registrar, Neurology > (Sent from my mobile) > > > On 1 Apr 2010, at 13:54, Mark Wardle <[email protected]> wrote: > >> Hi Kieran, >> >> Do you store the name of the java class or use a lookup hashmap or >> something else? >> >> Mark >> >> On 1 April 2010 11:52, Kieran Kelleher <[email protected]> wrote: >>> For sure, Roles are the way to go, especially if someone can have more than >>> one Role (outside of the game of Chess, can a King also be a Knight? ;-) ) >>> However if your design really has only one Role and you don't want to or >>> can't change your database schema, you could drop the inheritance on those >>> entities and use the Strategy Design pattern to lazily instantiate >>> composited behaviours .... PeasantBehaviour, KingBehaviour, KnightBehaviour >>> that all implement the RoleBehaviour interface (in American english, drop >>> the 'u' in "behaviour".) You don't even need to change the current >>> database. Just use the current inheritance 'type' field to map to a >>> RoleBehaviour class..... and now the RoleBehaviour becomes an attribute. >>> The work involved is just EOModel simplification and breaking out the >>> behaviours into classes >>> >>> YMMV, Kieran >>> >>> >>> On Mar 31, 2010, at 10:48 PM, Ramsey Lee Gurley wrote: >>> >>>> I can't see this being possible in Vertical or Horizontal, but with single >>>> table... could the qualifying attribute be updated to 'promote' an entity >>>> to a new class? Let's say we have we have an abstract Person entity with >>>> three subclasses, Peasant, Knight, King. If I wanted to promote a knight >>>> to king, is it possible to simply update my type attribute from knight to >>>> king and EOF will start treating that record as a king instead of a >>>> knight? I would assume I would need to invalidate the existing knight >>>> object after saving changes so it could be refetched as a king... and if I >>>> had multiple instances, I'd need to invalidate it in those instances >>>> too... but is it possible? Or will EOF just flip out in the saveChanges() >>>> and refuse to do it? >>>> >>>> Just an academic question, of course (^_^) >>>> >>>> Ramsey _______________________________________________ >>>> Do not post admin requests to the list. They will be ignored. >>>> Webobjects-dev mailing list ([email protected]) >>>> Help/Unsubscribe/Update your Subscription: >>>> http://lists.apple.com/mailman/options/webobjects-dev/kieran_lists%40mac.com >>>> >>>> This email sent to [email protected] >>> >>> _______________________________________________ >>> Do not post admin requests to the list. They will be ignored. >>> Webobjects-dev mailing list ([email protected]) >>> Help/Unsubscribe/Update your Subscription: >>> http://lists.apple.com/mailman/options/webobjects-dev/mark%40wardle.org >>> >>> This email sent to [email protected] >>> >>> >> >> >> >> -- >> Dr. Mark Wardle >> Specialist registrar, Neurology >> Cardiff, UK _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
