Re: "Static" objects in EC (was: multi-instance sync woes)
Re: "Static" objects in EC (was: multi-instance sync woes)
- Subject: Re: "Static" objects in EC (was: multi-instance sync woes)
- From: OC <email@hidden>
- Date: Sun, 07 Dec 2014 23:55:02 +0100
And back to the static objects...
On 27. 11. 2014, at 18:35, OC <email@hidden> wrote:
> On 26. 11. 2014, at 0:57, Chuck Hill <email@hidden> wrote:
>> On 2014-11-25, 3:22 PM, "OC" wrote:
>>
>>> There are objects of a given entity; most of them have normal lifecycle like a normal EO, but some of them are "static": conceptually, they should be hard-coded in the application.
>>>
>>> Something like, hmmm, say the app manages print templates. There are a couple of hard-coded ones, and the user can create his own ones as well.
>>>
>>> All the objects -- "static" and normal as well -- need to go to relationships, which (far as I understand EOF and unless I'm missing something) prevents not just the shared EC, but also the otherwise-best solution of having these "static" objects in-memory only, without actually storing them in the DB.
>>
>> Do they have to be in the same relationship? Could you have two, one for the hard-coded and one for the normal objects? They could both share a common interface. Then you could use custom attribute types to create a POJO based on the attribute value for the hard coded ones. I don’t think you can easily use a relationship (as opposed to an attribute) as EOF will want it to have GID. So code like
>>
>> public ITemplate printTemplate() {
>> return builtInTemplateFromAttribute() != null ? builtInTemplateFromAttribute() : userCreatedTemplate();
>> }
>
> This can be done (and perhaps it might truly be the best course in the long run), but the problem is that those “print templates“ themselves are non-atomic; they are made from a network of objects, all of which have their own relationships -- amongst them, and to normal EOs “outside” the “static” part both.
>
> It would be possible to implement it all manually, so to speak -- but it would be rather lots of work, compared with what one gets “for free” if all those objects and their relationships are simply set up in Modeller.
... now I wonder.
Correct me please if I am overlooking something, but I believe it is completely harmless to use EOs which are not in any EC, far as these EOs are never put into any relationship, right?
Well... what if I
(a) use transient, memory-only, not-in-EC EO instances for the static objects
(b) for each relationship 'rel' which can contain both static and normal EOs define in model actually two items:
- rel_dynamic -- this would be normal EOF relationship
- rel_static -- this would be an attribute some representation of an NSArray of strings (e.g., comma-delimited)
(b) override addObjectToBothSides... so that if there is no relationhip for given key
- it checks whether the object being added is in an EC
- if so, it would send super.addObjectToBothSides...(object,key+'_dynamic')
- if not, it would instead add objects internal identifier to rel_static
(c) override storedValueForKey so that if there is no relationship for given key
- it checks whether key+'_dynamic' and key+'_static' exist
- if so, it would construct a new array of objects from storedValueForKey(key+'_dynamic') ...
- ... and objects internally found for all identifiers from key+'_static' (these might be cached if need be)
(d) override appropriately removObjectFromBothSides... of course, too.
Do you see some inherent idiocy in this approach, anything bound to rise its head soon and bite me in my tender parts?
Thanks a lot,
OC
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden