• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: [Somewhat OT] Code organization question
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Somewhat OT] Code organization question


  • Subject: Re: [Somewhat OT] Code organization question
  • From: Stamenkovic Florijan <email@hidden>
  • Date: Sat, 28 Mar 2009 12:15:45 -0400

Hi Lachlan,

On Mar 28, 2009, at 06:55, Lachlan Deck wrote:

You've described how they're used, which is all cool, but the particular problem you're trying to solve sounds like it's more to do with how they're initialised.

Yes, it does. Read on...

So the normal EOClassDescription, for example, is usually derived from the model and is therefore loaded at runtime from the plist definitions.

In a JC situation a class description is loaded from the server, which loads it from the model. The model itself is not available on the client.


I'm guess that you have something else happening (e.g., definitions in code rather than plist?)

Definitions of what? Derived properties? Yes, they only are in code. I do not define my derived properties in the model because EOF's derived prop system is not capable of doing what I need done. As for manipulating the class descriptions in code, nope, I don't do that.


DataType interface (JBND equivalent of EOClassDescription) among other things defines some method:

<...>
public void addDerivedProp(String key, PropType type, Class<?> propClass,
String... derivedFromProps);


<...>	public Set<String> propsDerivedFrom(String key);


Then this info is queried by EOs, which use it in the following way:
- the constructor of EOFDataObject (EO superclass) checks the info in it's DataType to see if there are derived properties that depend on keypaths. If there are, it schedules the creation of KeyPathChangeManagers. Those are objects made to observe changes happening on trees of inter-related objects, defined by a keypath. EOFDataObject uses a specialized KeyPathChangeManager subclass that reports the changes on the path back to the EO that created it. When a relevant change is detected, a change event is fired for the property that is derived from the keypath, resulting in the clearing of it's cache.

Aha. This is the crux of the problem: the need to observe changes of derived properties destinations.
Perhaps DataType - which is the conceptual representation of the type - is not the right place for initialising keypath observance implementations.

Well, the DataType stores this information. It does not initialize it. Please see below.


This could be trigged, for example, from the first awakeFrom[Insertion|Fetch] for each entity perhaps?

Yes! This is exactly what I am doing :) I inform the DataType of the derived props for that DataType, on the first init of an EO of that type. I do it from the constructor. It is safe to do in the constructor as this process does not involved any EOF work in the EO itself.


You might thing that awakeFromFetch could be a better option because it would enable me to immediately initialize keypath change observers. This would be ideal, but unfortunately it does not work, I tried it out. For some convoluted reason that my hung-over head can't exactly remember... The initialization of observing the object graph that defines a derived property works properly only if done at a later point, such as valueForKey, which is why I do it there.

I believe now you can see exactly what I meant in the first post... In essence we came up with the same solution to the problem... Now, my first post also describes why I don't like it too much, even though it's fully functional. Which brings us back to the original question: any thoughts on improving this?

Thanks,
F
_______________________________________________
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


References: 
 >[Somewhat OT] Code organization question (From: Stamenkovic Florijan <email@hidden>)
 >Re: [Somewhat OT] Code organization question (From: Lachlan Deck <email@hidden>)
 >Re: [Somewhat OT] Code organization question (From: Stamenkovic Florijan <email@hidden>)
 >Re: [Somewhat OT] Code organization question (From: Lachlan Deck <email@hidden>)
 >Re: [Somewhat OT] Code organization question (From: Stamenkovic Florijan <email@hidden>)
 >Re: [Somewhat OT] Code organization question (From: Lachlan Deck <email@hidden>)

  • Prev by Date: Re: [Somewhat OT] Code organization question
  • Next by Date: Re: used shibboleth
  • Previous by thread: Re: [Somewhat OT] Code organization question
  • Next by thread: Setting not-nullable field to null - nothing happens
  • Index(es):
    • Date
    • Thread