Re: When do I use addObjectToBothSidesOfRelationshipWithKey?
Re: When do I use addObjectToBothSidesOfRelationshipWithKey?
- Subject: Re: When do I use addObjectToBothSidesOfRelationshipWithKey?
- From: Dirk Bajohr <email@hidden>
- Date: Fri, 3 Sep 2004 17:32:54 +0200
This is one way to accomplish this, another (I think the better)
approach would be to create a new Request and to insert it into an
EditingContext before the page is displayed.
Then you can bind the object's relationships directly. Your save button
only needs to call ec.saveChanges().
And if you use an EditingContext different from the session's default
one and the user doesn't click on the save button, no changes are made
to the database and the object graph of your default ec is still
"clean".
But don't forget to call the lock() and unlock() functions for the
custom ec when you save the changes.
And BTW all other objects have to be in the same ec.
The Request objects that you display in the list below will stay in the
defaultEC.
A short example?
public class MyComponent extends WOComponent {
EOEditingContext tempEC;
Request req;
... constructor etc. ...
public void appendToResponse(WOResponse aResponse, WORequest
aRequest) {
tempEC = new EOEditingContext();
req = new Request();
tempEC.insertObject(req);
super.appendToResponse(aResponse, aRequest);
}
public NSArray reqStatusList() {
return EOUtilities.ObjectsForEntityNamed(tempEC, "ReqStatus");
}
public WOComponent save() {
try {
tempEC.lock();
tempEC.saveChanges();
} catch (Exception e) {
...
} finally {
tempEC.unlock();
}
tempEC = null;
return context().page(); // or: return pageWithName("Whatever");
}
}
Am 03.09.2004 um 16:05 schrieb Tom Jones:
Thank you,
Just to clarify...
I have an app that is similar in design to the Author/Book example in
Apple's documentation. So the first row of the table the user enters
the info, and the second row is a WORepetition that shows all of the
items(in this case reqs).
In the input row, I bind everything to the various fields in a req.
req.status is bound to a WOPopup's selection. I take it from your
email that it would be better to have an object for each of the
Relationships, and bind the inputs to these objects and then make the
association. So for instance, bind aStatus to the WOPopup's selection,
and then call aStatus.addObjectToBothSidesOfRelationshipWithKey(req,
"reqs"); Right?
Thanks,
Tom
On Thu, 2 Sep 2004 14:00:38 -1000, Art Isbell <email@hidden> wrote:
On Sep 2, 2004, at 1:00 PM, Tom Jones wrote:
The code below is my attempt to preserve the following relationships
project<-->>req
reqpriority<-->>req
status<-->>req
reqtype<-->>req
a project owns its reqs
if a reqpriority, status or reqtype is deleted, the req's
corresponding value should be null.
given that is all of this code necessary?
session.defaultEditingContext().insertObject(req);
req.reqpriority().addObjectToBothSidesOfRelationshipWithKey(req,
"reqs");
req.status().addObjectToBothSidesOfRelationshipWithKey(req, "reqs");
req.reqtype().addObjectToBothSidesOfRelationshipWithKey(req, "reqs");
project.addObjectToBothSidesOfRelationshipWithKey(req,"reqs");
session.defaultEditingContext().saveChanges();
Statements 2 - 4 imply that req.reqpriority, req.status, and
req.reqtype have already been set, so there's no need to set them
again
(however, property values should in general be set after only an
object
is inserted). If they haven't been set, statements 2 - 4 should throw
a null exception.
If you have reqpriority, status, and reqtype objects,
statements 2 - 4
should be:
reqpriority.addObjectToBothSidesOfRelationshipWithKey(req, "reqs");
status.addObjectToBothSidesOfRelationshipWithKey(req, "reqs");
reqtype.addObjectToBothSidesOfRelationshipWithKey(req, "reqs");
Aloha,
Art
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.
--
Dirk Bajohr
iSOLUTION - Individuelle Software fuer moderne Kommunikation
Hauptstr. 50
53757 Sankt Augustin
T +49 2241 921567-0
F +49 2241 921567-89
http://www.isolution.de
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.