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/archive%40mail-archive.com
This email sent to [email protected]
