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 protected]> 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 protected]> a écrit : > >> And back to the static objects... >> >> On 27. 11. 2014, at 18:35, OC <[email protected]> wrote: >>> On 26. 11. 2014, at 0:57, Chuck Hill <[email protected]> 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 protected]) >> Help/Unsubscribe/Update your Subscription: >> https://lists.apple.com/mailman/options/webobjects-dev/samuel%40samkar.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: > https://lists.apple.com/mailman/options/webobjects-dev/samuel%40samkar.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: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
