And to add to that, if it's not clear ......
- Use the same table (as you said "near identical")
- If you like prefix the non-common attributes with underscore or sth, and
write behavior interface cover methods that throw when the attribute is being
set on the wrong type.
- Use type attribute for fetches to exclude user-customized templates.
On May 11, 2011, at 3:56 PM, Kieran Kelleher wrote:
> If I understood you correctly:
>
> - Make option relationship from tUser <-->> tA for "user-owned templates"
> - Add extra fields to tA
> - Add a type field to tA - Integer - each int denotes a behavior
> - Use Strategy Design pattern and create 2 behavior classes that correspond
> to two templates types
> TemplateBehavior interface
> DefaultTemplateBehavior
> UserTemplateBehavior
>
> - Methods/logic that differ between both template scenarios should be put in
> the Behavior interface and implemented in Behavior classes.
> - The EO class corresponding to tA also implements TemplateBehavior interface.
> - Set default value of type to be DefaultTemplateBehavior type (say type = 10)
> - lazy instantiate behavior in the class based on value of type.
> private TemplateBehavior _behavior;
>
> private TemplateBehavior behavior() {
> if ( _behavior == null) {
> if (type().intValue() == 20) {
> _behavior = new UserTemplateBehavior(this);
> } else {
> _behavior = new DefaultTemplateBehavior(this);
> }
> }
> return _behavior;
>
> - implement interface methods in the EO class like this
> public void doSomething() {
> behavior().doSomething();
> }
>
> - Use Chuck's EOCopyable interface and utilities to copy tA instance when a
> user wants to customize. Set your extra attrivutes and change the type of
> the copied template to the int corresponding to the UserTemplateBehavior (and
> reset _behavior to null - I have a reset() method in my GenericEO and is used
> to nullify cached ivars on every didUpdate and didInsert btw)
>
> HTH, Kieran
>
> On May 11, 2011, at 3:14 PM, Michael Gargano wrote:
>
>> I was just talking to David Holt about this and he suggested I tap the brain
>> trust. :)
>>
>> I was wondering if there is a database design pattern for a situation where
>> I have some template structure
>> let's say
>>
>> tA <->> tB <->> tC (records across these tables are the template, the
>> template is a whole object graph rooted at one record in tA)
>>
>> where the templates can be configured on a per tenant basis (so, the
>> templates themselves are records that define defaults and new ones can be
>> added when new tenants or templates are added). I need to make a copy of a
>> template that a tenant uses and make it local to a user (under that tenant)
>> who can then customize the values in that template for their needs.
>>
>> It's basically a class/instance kind of structure, but at the data level in
>> the database. It's as if I need to copy an EOs from one table to another
>> where the destination table has a few more attributes than the source table
>> did. It's made more complicated by the fact that I need to copy that
>> template object graph, not just one EO.
>>
>> Any suggestions?
>> *Hopes beyond hope*
>>
>> Thanks.
>> -Mike
>>
>> _______________________________________________
>> 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/kelleherk%40gmail.com
>>
>> This email sent to kelleh...@gmail.com
>
_______________________________________________
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 arch...@mail-archive.com
