Kieran,
Thanks for the explanation. I understand what you mean now... It
definitely sounds good, though I have still to figure out exactly how
I would apply this to my situation. Since among the inheritance types
EOF provides single-table seems most applicable to my situation, I
might switch to the principle you describe.
Thanks,
Flor
On May 08, 2008, at 13:39, Kieran Kelleher wrote:
In brief, the entity has a type field (just like single table
inheritance has) that determines which Strategy class applies to
the instance. Usually I use an integer and I have a property that
determines the behaviour class in Properties, like this
strategy.entityname.10=com.domain.BehaviourClassOne
strategy.entityname.20=com.domain.BehaviourClassTwo
etc.
The entity has a behaviour method that lazily initialize the
behaviour class with a constructor that takes the entity instance
as an argument.
Usually I have a single static factory method in the entity that
takes the type as an argument. The factory creates and instance
sets the type and then calls initialize(). initialize() delegates
to the behaviour class' initialize() method.
The behaviour classes all implement a common interface. One
behaviour class exists for each Object type you want to model.
Essentially, you can add more object types and change applicable
attributes without touching your eomodel/database.
How are attributes handled ......... well, every entity has all the
attributes from EOF's perspective .... however the behaviour
strategy class associated with each Object Type returns an
NSArray<String> of applicableAttributes(). In your WOComponents a
simple conditional that checks whether an attribute is in the
current object's applicableAttributes() decides whether to display
or not to display the attribute in view/edit components.
that's the gist of it ..... I do use inheritance for simple cases,
but when a lot of various object types are called for I find this
much easier and more flexible to maintain and add functionality
than a multi-tier EOF inheritance of dozens of different
classes ..... all the overrides is enough to make one's head spin!
In any case, take the path of least resistance to get your project
done. You can easily refactor single table inheritance into a
single entity with Strategy Design pattern later if your
inheritance hierarchy is making you tear your hair out. ;-)
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
