Re: Inner Classes & EOF
Re: Inner Classes & EOF
- Subject: Re: Inner Classes & EOF
- From: David Avendasora <email@hidden>
- Date: Wed, 21 May 2008 09:45:38 -0400
On May 14, 2008, at 10:40 AM, Florijan Stamenkovic wrote:
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!?" :)
Yes, correct. Inner classes are not EOs, but they do implement some of
the niceties like key-value coding. Figured that one out myself. Me so
proud. (Yes, I know it is a simple thing to do. Let me have my moment!)
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...
Hmmm. Wouldn't be the first time I did things the hard way, right
Chuck? Hey, stop laughing. I'm not that bad. Okay. Fine. I am.
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.
Yes, this is correct. This is one of the biggest issues with JC. When
you start doing more complicated things and trying to do some on the
server and some on the client, you can end up with complicated
dependencies that are not at all apparent. Having to go to the server
to recalculate summary data when you are simply updating or deleting a
relationship can make simple actions much more complicated and make
tracking down issues that much more difficult.
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.
I only have a couple clients so, if I could make it work on the server
it would be much faster. I'm talking about literally hundreds of EOs
that need to be brought down to the client to run the calculation, and
my application runs across the internet for the most important client
(me). Now, the nice thing is that if I don't specifically ask for the
value, it doesn't run the calculation, so it does only run if you
really need the info - this also impacts how the UI is laid-out to
keep that value from being on the default editing screen or the
listing views.
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.
This is what I do in a couple places to avoid copying down the EOs,
but then I end up with the logic on both the server and the client to
calculate these values. I can't wait for Mike's Commen Entity Class
support.... I see he just emailed saying he's just committed some
changes for it! Yipee!
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.
You know, this is a good point. I may have been trying to transfer the
EO instead of the global ID. I took the error to be complaining about
the Inner Class... I'll have to check this some more.
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.
I'm really looking forward to WOWODC to begin transforming my app from
D2JC to JBND. D2JC is just so _easy_ most of the time...
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...
You don't shout it way too much. You just remind me of Chuck, Mike and
all the others that shout Wonder all the time. They do it because it
is truly a better way to develop.
As I transition from D2JC to regular JC, I'll certainly be using JBND.
Without a doubt.
Dave
_______________________________________________
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