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: Samuel Pelletier <email@hidden>
- Date: Mon, 08 Dec 2014 17:07:14 -0500
Hi OC'
I suggest to have a single instance responsible for the static object database update. You design the instance by adding a property value in the app status arguments.
Other instance will pick the new value when the snapshots are refreshed. If you to propagate the changes, a direct action or other notification mecanism to refresh the objects can be used.
Samuel
Le 2014-12-08 à 10:12, Samuel Pelletier <email@hidden> a écrit :
> Hi OC,
>
> I had to use 2 kinds of static objects like this in the past, here was my solutions.
>
> 1- Simple objects with no link to other EOs. I store some sort of identifier, usually a string in an attribute of the EOs that refer them. The normal setter is blocked with an override in the EO class like this:
> @Override
> public void setEtat(String value) {
> throw new IllegalAccessError("Do not use setEtat, use the state transition methods.");
> }
>
> I add a getter and setter with the static object class as value type. This method convert the identifier to the real object in both directions. A static list of possible values is kept in a singleton, a global var or a injected service.
>
> 2- For complex objects with relationships to others EOs, it is easier to store them as real EOs in the database. To get a fast access to them, keep their globalIDs in memory and let EOF cache the snapshots for you. Converting globalID to real EO when snapshots are in cache is very fast. The tricky part is to get the globalIDs, fetching by primary key is not efficient, it always hit the database. Here is the pattern:
>
> - initialize a global array of EOGlobalID ether at launch or lazily :
> private void initStaticGlobalIDs(EOEditingContext ec) {
> NSArray<EOClass> staticObjects = EOClass.fetchEOClasses(ec, ...);
> staticGlobalIDs = ERXEOControlUtilities.globalIDsForObjects(staticObjects);
> }
>
> - Return an array of static objects for an EOEditingContext (called in the EO or component that display it:
> public static NSArray<EOClass> EOClass.listOfChoices(EOEditingContext ec) {
> return (NSArray<EOClass> ) ERXEOControlUtilities.convertGIDtoEO(ec, staticGlobalIDs);
> }
>
>
> Samuel
>
>
>
> Le 2014-12-07 à 17:55, OC <email@hidden> a écrit :
>
>> 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
>
>
> _______________________________________________
> 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
_______________________________________________
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