Ondra,
This is a situation that cries out for nested and peer editing
contexts. Each Volume should have its own peer EC. Each Page then has
an EC whose object store is the Volume's EC. Remember that different
EC's can each have their own copy of the same EO, each of which has
the same EOGlobalID and refers to the same database, but which are
different instances. You always build relationships between EO's
within the same EC, such as connecting up an Ad to a ColorSpace. If
the objects are in different EC's then use
EOUtilities.localInstanceOfObject() to get an instance of the EO that
is in the right EC. Be careful in your EOModel design so that you
have accounted for all of the places where you really need a many-to-
many relationship. When a user saves a Page object, the Page's EC
flushes changes to its parent, the Volume's EC. When the user is
satisfied with the entire Volume, he or she hits save and the
Volume's EC flushes to the database.
I hope I'm making this clearer for you, not murkier.
--Paul
Paul Suh
http://www.ps-enable.com/
[EMAIL PROTECTED] (301) 643-1516
On Apr 21, 2006, at 3:53 PM, Ondra Cada wrote:
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
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [email protected]
