Re: Event firing from changing EOs
Re: Event firing from changing EOs
- Subject: Re: Event firing from changing EOs
- From: Florijan Stamenkovic <email@hidden>
- Date: Tue, 8 Jan 2008 14:15:13 -0400
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).
That's really interesting. But in this light I totally fail to
understand why the change notification system that EOF seems to use
internally is not a bit more sophisticated (client side). I mean,
I've been exploring the best way to handle this on a few occasions
till now, and every time I end up with the impression that client
side of EOF is, well, crude, when it comes to this point. I assume we
can agree that in a client application an immediate, detailed change
notification is only a benefit. Necessarily so on the individual EO
level (aggregating notwithstanding), because quite often that is how
changes happen, one by one. I can understand that one would like to
avoid it server-side because of potential performance costs. But, if
EOF started out in a way that is more similar to today's JC then to
WO WebApps, where in EOF is that change notification???
Flor
_______________________________________________
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