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).
Man, last thing I heard you were on a 30Mbps net connection...
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!
Uhm, why do you have that logic on both sides? If you use RMI on the
client to get the values, you only need the logic on the server
side... I am not sure we understand each other on this point. Here's
what I mean:
Server:
public NSArray<EOKeyGlobalID> getSummedRelationship() { ... } // does
the actual work
public NSArray<EOKeyGlobalID> clientSideRequestSummedRelationship()
{ return getSummedRelationship(); }
Client:
private NSArray<EO> summedRelationship;
public NSArray<KeyGlobalID> getSummedRelationship() {
if(summedRelationship != null) return summedRelationship;
NSArray<EOKeyGlobalID> summedRelationshipIDs = invokeRemoteMethod
("clientSideRequestSummedRelationship", ...);
summedRelationshp = new NSMutableArray<EO>();
for(EOKeyGlobalID id : summedRelationshipIDs)
summedRelationship.add(editingContext().objectForGlobalID(id));
return summedRelationship;
}
Anyway, I am not saying this is the best solution. All depends on how
much work is being done in this summed relationship on the client. If
there's a lot of modification going on, maybe best to keep it all on
the client at all times. Especially since you will need to save
changes first (to switch from temporary to permanent GlobalIDs) every
time this gets invoked... See what I mean?
If it were up to me, I'd most likely ditch it all to the client. I
mean, if it takes half a minute longer to load that app on startup
coz there is more EOs to transfer, blame the IT guys!
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.
Hm, either way, I would not be sure you could get anything outside of
Foundation transferred through WO's RMI. *Maybe* if you tried dealing
with NSCoder to somehow provide serialization support for your inner
class, but even that is a long shot in my eyes. Never tried it.
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...
Yeah, and so _bad_ the rest of the time :)
As I transition from D2JC to regular JC, I'll certainly be using
JBND. Without a doubt.
Truly looking forward to it :) I'm sure I'll be getting plenty of
feature requests and bug reports once that is on...
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]
