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: Thu, 10 Jan 2008 10:14:42 -0800
Hi David,
On Jan 10, 2008, at 8:56 AM, David Avendasora wrote:
Hey Flor,
You should take a look at what Paolo Sommaruga has done with his
JPBindings framework http://www.jpaso.com/name/
XMLBindingForJavaClient. In it he is using EODisplayGroup and
EOAssociation, so he may have more to add on what they do and don't
do.
I _LOVE_ that we have two competing/complimentary frameworks to aid
in WO Java Client development!
Chuck, did you ever think you'd see the day?! :D
No, I really did not. I expected it to die a lingering and painful
death. I am very impressed with what Florijan and Paolo have done.
Once again members of our community snatch victory from the jaws of
defeat. I love this place!
Chuck
On Jan 8, 2008, at 1:29 PM, Chuck Hill wrote:
On Jan 8, 2008, at 10:15 AM, Florijan Stamenkovic wrote:
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.
Probably more of a history lesson, than anything of practical use
to you.
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.
It is. NeXT and YellowBox apps used the full, server side EOF of
WebObjects. JC appears to me to be an add on to WO that had a lot
of work done on it at some point and then work was stopped before
it was complete.
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???
Maybe it never got finished. Maybe they had some different
architecture in mind, using EOAssociation. I have never done a JC
app, so I really don't know.
Chuck
--
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:
40avendasora.com
This email sent to email@hidden
--
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