Re: propagate primary key and owns destination (Java Client and EOF)

I can't say for sure if a nested ec is a technically correct way to think 
of a client side editing context, but my experience has shown that just 
about everything in EOF works on the client side very nicely; you treat the 
ec just as you would if it were your main ec on the server side.. I have 
found some bugs in the past but have always found workarounds; for all I 
know they may have been fixed by Apple but my logged JC bugs just vanished 
from their bug logger system some time ago - only one ever got answered 
(with a workaround) when Max Muller took up the cause for me.

So I wouldn't say I've found limitations, other than issues with efficiency 
which can be resolved by careful app design, model design and use of cached 
relationships and prefetching where appropriate. The most important thing 
to avoid is large numbers of client/server round trips to fetch in objects 
one at a time as faults are fired.

The fact that JC EOF may be broken in 5.2.3 is of great concern to me. So 
few people seem to use JC, I worry about Apple's commitment to supporting 
it. Yet it seems like a fantastic technology which works at quite 
acceptable speed when used over internet broadband connections.

John

At 16:32 12/06/2004 +0800, Ashley Aitken wrote:

>Howdy All,
>
>On 12/06/2004, at 12:23 AM, John Pollard wrote:
>>Oh boy, many apologies, this does work on Java Client, Owns Destination + 
>>Propagate Primary Key, I really can't explain how I messed up, it works a 
>>treat, sorry
>
>Excluding the partitioning (of business logic and data) that Java Client 
>allows and the transport mechanism between client and server, and only 
>considering the editing context aspects of the Java Client application (ie 
>EOF not the Java GUI) is it not ok to consider the Java Client EC simply 
>as a nested editing context?  Or is this too simplistic?
>
>If the above is correct then I would see little reason why any of the EOF 
>aspects would not work for a JavaClient application (again, excluding 
>complications brought into being by the extra functionality associated 
>with the business logic and data partitioning and the transport 
>mechanism.  I would be interested in any limitations have people seen?
>
>Cheers,
>Ashley.
>
>--
>Ashley Aitken
>Perth, Western Australia
>mrhatken at mac dot com
>
>_______________________________________________
>WebObjects-dev mailing list
>[email protected]
>http://www.omnigroup.com/mailman/listinfo/webobjects-dev
>
>

John Pollard
020 889 22143
077 422 10024

_______________________________________________
WebObjects-dev mailing list
[email protected]
http://www.omnigroup.com/mailman/listinfo/webobjects-dev