Dave, Chuck,
I was out of town (and computerless, it hurt) for a few days, good to
see you guys are still having fun :)
OK, everything I write here is based on the assumption that your
inner class will NOT be an EO. Did I get that right? If I
misunderstood, it does not apply... If you want your EOs to have
inner EOs, then my reply indeed would be "are you bleepin' nuts!?" :)
Sounds like a good idea, what you are doing, but is there a reason
you want to isolate the "summarizedComponents" cache into an inner
class? Why not just use a List? As for the inner class idea, I can
not see anything against it, since your inner class will not be an
EO. If it was, well, that could hurt, and I am not sure if you could
get EOF to play along.
The reason why I would use a List in the EO, is because it would make
KVC simpler. Well, it would make everything simpler... You could just
define a Java-only property and voila...
Well, that does not sound so back. JavaClient may throw a spanner
into it.
Can't see why. From what I understand, EOF would be ignorant of this
construction built on top of it, it should be OK.
Biggest issue is that you can't do the work on the server, then
send the EOs containing the Inner Class down to the client because
EOF doesn't know how to encode the Inner Class as part of the
Client-Server EOF Sync, assumably because the Inner Classes aren't
in the Model.
Hm... Also, on the client the users expect to see the changes they do
to data immediately reflected in all their aspects (if there is a
change somewhere along the line, users want the
"summarizedComponents" to reflect that). So, if somebody was modify
one of the relationships along the way (on the client), and the
summarizing work was being done on the server, the client would
either not have the changes updated in your "summarizedComponents"
property, OR you would have to do some painfully fancy server-client
comm. Either way, since your caches are not EOs, I believe you are
better off doing the work on the client.
And it is good performancewise. Well, you spend more bandwidth on
transferring the EOs, but your server has it's work offloaded to
clients. This might or it might not be a benefit in your scenario,
but it is worth considering.
Or you can define a custom property that is statefull RMI based.
Essentially say that the getter for your relationship invokes an RMI
method on the server that returns what you need. Heck, you could even
do some caching of *that* value. This might work... More on this
thought below.
So I end up doing all the work on the client which means bringing a
lot of EOs down to the client just to build the summary data there
instead of doing the work on the server, right "next to" the DB
then copying just the summary data down. With a couple more years
experience, maybe I'd figure out how to massage the EODistribution
classes into doing what I want (serialize the Inner Classes myself,
etc). WOnder<Java Client> here we come.
Uhm. Well, yes, AFAIK EOF will not allow you to serialize any non
foundation class. BUT. If you used an NSArray of global IDs (note
that you should not transfer EOs manually), you could do it through
conventional EOF means. RMI. Even if you are not willing to give up
your inner class, you could simply update the embedded cache of EOs
it would contain, this way.
What you are doing in caching expensive values in an EO. I do
that, it works. You just need to be careful to invalidate the
cache at the right time. This can be even tricker when multiple
EOs are involved.
Yeah. I think I'm running into this exact problem as I'm ending up
with bad data at times. It seems random, but I'm sure it's not.
JBND can do this for you, along countless relationship paths and EOs,
with very little effort on your part! I do it all the time! :P
http://web.mac.com/flor385/JBND/api/org/jbnd/support/
KeyPathChangeManager.html
You could use this class without most of JBND (uhm, I think, but if
not it can be tweaked), but it relies on your EOs firing
DataObjectEvents. Time to switch... I know, not what anyone who is
busy wants to hear. Well, look at it this way. If you plan to switch
eventually, then the sooner you do it, the more you will benefit from
the productivity benefits it is meant to provide for us JC folk.
To summarize how I see it...
If you insist on keeping the work on the server: Have a Java only
property defined in the "Part" EOs. On the server that property does
the actual work of arranging the array. On the client, it only asks
for the server to do the work and send it over in the form of
KeyGlobalIDs. On the client, cache the value, and use JBND to find
out when there are modifications in the relationships involved. When
that happens, empty your cache, and deal with your GUI the way you
normally would (in JBND this would entail firing an event saying that
for a Part the "summarizedComponents" property changed). This will
hurt your performance if you have the server doing Web app work as
well, since the caching is only done on the client (because JBND
invalidates the caches, and it is client only).
If you prefer doing the work on the client: Have a lazily initialized
property, have JBND watch the relationship tree that produces it, on
detected change empty your cache and update your GUI. Done.
I know I shout JBND way too much, but this kind of stuff is exactly
why it was made, for a big part... If you are doing HTML web apps,
you can just use the RR loop to get the latest values. On the client,
you have the object graph being changed directly on the client, and
if you want to keep the user informed of it, you need good change
notifications going. I can't see this being done properly any other
way...
F
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
