Paul, On 21.4.2006, at 21:22, Paul Suh wrote:
You should probably go back and re-think your design, so that you are no longer trying to save the single EO -- instead, your natural flow will be to save the entire state of the object graph tracked by the EC.
My archetypal wanna-save-part-of-graph situation is a simulated document-like environment.
For example, one of my projects allows the user to edit a number of "volumes" (they contain "pages", and the user places "ads" and "articles" to the "pages"). All the information is stored in one central database, and there are relationships which intertwine all the objects into a network without clean-cut bounds (for example, all "pages" and also "ads" link to the same list of "colour spaces"; the "user" who can edit different parts of the network has its own entity, too, and there are relationships between "users" and objects of all kinds they are editing, and so forth).
Now, the user assumes that (a) he can open more "volumes" at once, (b) he can save changes made inside each of them independent on the others.
Possibly I am overlooking something very obvious, but I do not see a general, clean, and easy solution: either I use one EC, in which case I cannot save separately (without some real hackery :)), or I use more EC's, but then there are relationships which cross the EC boundaries. Also, I do not see (perhaps just caused by my blindness of course!) any obvious design error in the above.
--- Ondra Čada OCSoftware: [EMAIL PROTECTED] http://www.ocs.cz private [EMAIL PROTECTED] http://www.ocs.cz/oc
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ 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 archive@mail-archive.com
