Re: Event firing from changing EOs
Re: Event firing from changing EOs
- Subject: Re: Event firing from changing EOs
- From: Chuck Hill <email@hidden>
- Date: Tue, 8 Jan 2008 09:04:21 -0800
On Jan 8, 2008, at 8:47 AM, Florijan Stamenkovic wrote:
Chuck,
The stuff I have already made relies on all of this information,
so the notification simply will not do. And, IIRC, the mentioned
notification only gets posted when you ask the EC to save
changes. This is NOT what I need. I need immediate feedback.
They get sent at the end of the event. In a web app, that is at
the end of the RR loop. For a client app, that would be after
processing an event in the event loop. You might need to manually
call ec.processRecentChanges() in your event loop code.
Hm. Well, this is a kind of a batch approach to editing. I can see
what you're saying, but it is very WOish. Which seems to work
brilliantly when making Web apps. It is not (in my eyes) so
glamorous in JavaClients. I mean, it is too oriented towards the RR
loop.
In fact, it is not. This architecture, along with most of the EC
handling, is from the days of NeXT desktop apps. It would get run at
the end of specific events (control losing focus, button click,
etc). In my imagination, that should be quite similar to the way a
JC app operates.
Running processRecentChanges at the end of the RR loop was how this
architecture was adapted to a web app. It does not quite fit. The
origin of the handling for ECs is also why in WO, when an editing
context saves it synchronizes across all the other editing contexts
in that instance (assuming a single EOF stack), but does not
sychronize across other running instances. It used to just
synchronized across all the editing context's in _the app_ the user
was running on their desktop. When moved into a web app, the result
of this was different and so today we have to handle optimistic
locking failures in two ways (changes merged between sessions and
failures when updating the DB).
Multiple edits, multiple values being processed in one big go.
Where, the way I see it, JC offers exactly the opposite: smaller
actions, direct feedback. A million small events as opposed to a
few big ones.
And that was how EOF started out.
Chuck
No words of wisdom on these methods, Chuck?
public void takeStoredValueForKey(Object value, String key)
protected void includeObjectIntoPropertyWithKey(Object eo, String
key)
protected void excludeObjectFromPropertyWithKey(Object eo, String
key)
API and some testing suggests that using them to fire events
should do.
I have not used them for what you are describing so I am a little
cautious to say "Yes, that will do it". I am not sure what
happens, for example, if the object gets invalidated, or saved in
another EC so that this EC updates.
Right, that's interesting. I'd have to see about that. Till now I
have used setters that are generated to fire events when they are
called. The cool thing about that is that none of this used to be
an issue. Maybe I should just stick to that approach. Never got me
in trouble.
I think it doing what you are describing will work. I am not sure
that these three methods will handle 100% of the cases. I'd take
a look at these methods too:
public void turnIntoFault(EOFaultHandler faultHandler)
public void updateFromSnapshot(NSDictionary aSnapshot)
Will do.
Except for the fact that they get called also when the objects
are being initialized after construction. I'd have to work around
that.
You should be able to set a flag in awakeFromFetch (or maybe some
other method) before calling super and suppress the notifications
while the flag is set.
Will try that out.
Thanks!
Flor
--
Practical WebObjects - for developers who want to increase their
overall knowledge of WebObjects or who are trying to solve specific
problems.
http://www.global-village.net/products/practical_webobjects
_______________________________________________
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