David,
Since you're changing a relationship and you want it to be reflected
in the model immediately, you'll have to handle the action yourself
and update the model using addObjectToBothSidesOfRelationshipWityKey
or removeObjectFromBothSidesOfRelationshipWithKey. If you're
generating your classes with EOGenerator, you probably have methods
that do this for you already.
The issue is, the pop up button just changes the value with key value
coding, without affecting the opposite side of the relationship.
What I usually do in these circumstances is add 2 new methods to the
EO - to replace the KVC normally used. Something like:
- (RoutingStep) routingStepRelationship {
return this.routingStep();
}
- (void) setRoutingStepRelationship:(RoutingStep) step {
this.addObjectToBothSidesOfRelationshipWithKey(step, "routingStep");
}
Again, these can be auto-generated for you by EOGenerator. If you
then change the 'selection' binding of the pop-up from 'routingStep'
to 'routingStepRelationship', KVC will call your set method, which
will directly manipulate the object graph.
Ken
On Apr 10, 2007, at 1:35 PM, David Avendasora wrote:
I'm going to try to clarify this a bit:
Here's the structure of my Form, the important part is in bold:
<WOForm>
aRouting
<WOTextField value=aRouting.routingDescription>
<WOPopUpButton selected=aRouting.part>
<WORepetition list=aRouting.routingSteps item=aRoutingStep>
<WOTextField value=aRoutingStep.stepNumber>
<WOTextField value=aRoutingStep.stepName>
<WOTextArea value=aRoutingStep.instructions>
<WORepetition list=aRoutingStep.rsComponents item=aRSComponent>
<WOPopUpButton selected=aRSComponent.routingStep>
<WOTextField value=aRSComponent.lineNumber>
<WOPopUpButton selected=aRSComponent.part>
<WOTextField value=aRSComponent.quantity>
</WORepetition>
</WORepitition>
<WOSubmitButton/>
</WOForm>
Here's the code for the action of the WOSubmitButton:
public WOComponent applyChangesToRouting() {
return context().page();
}
The critical portion is the relationship of RoutingStep<--
>>RSComponent
When I select a different RoutingStep for a RSComponent using the
WOPopUpButton and click the WOSubmitButton, it does update, but
when the page comes back, the aRSComponent that I changed shows
that it is now related to the new RoutingStep, but it is actually
physically drawn on the page as still being in the original
RoutingStep.
If I save the changes to the DB, and dump the session and re-enter
the app, the RSComponent will be in the right location. So it seems
to me that everything is actually being updated correctly, BUT the
data being used to draw the page immediately after the update is
_partially_ old. The original routingStep.rcComponents() array
still has the old RCComponent in it and the new
routingStep.rcComponents() array does not yet have the RCComponent
in it that it should. BUT the rcComponent.routingStep()
relationship DOES have the correct RoutingStep in it.
If I don't save it to the database and then come back in with a new
session, then I only see half of the updated relationship.
How do I get the RoutingStep.rsComponents() relationship updates to
show up?
Dave
On Apr 10, 2007, at 7:52 AM, David Avendasora wrote:
Okay, I over-simplified the problem some. On the actual component,
I'm not saving the changes to the database until the user clicks
the "save" button. They _could_ save the changes after every
change, but I want them to be able to revert, undo, and redo.
I don't really understand how I can tell a object to update,
setting relationships and such, yet when I ask WO to display the
object after the update, it shows an old version. If I had two
different EOEditingContexts I could see them getting out of sync,
but I am only using the Default EditingContext.
I've read the wiki on keeping EditingContexts fresh, but it seems
all the tips relate to data in the DB changing and making sure the
EC gets updated. I'm not even worried about what the DB says right
now, I'm wondering why the changes I just made to an object are
not reflected when I call it the next time.
Dave
On Apr 9, 2007, at 10:03 AM, Zak Burke wrote:
David Avendasora wrote on 4/5/07 2:32 PM:
I want to allow the user to move a RSComponent from one
RoutingStep to another. I present the user with a WOPopUpButton
on each rsComponent of all the RoutingSteps and they can simply
pick which one they want it in. It does update everything
properly, but when the page comes back, layout-wise the
RSComponent is still in the original RoutingStep, but in the
database it is in the new RoutingStep (right where it's supposed
to be).
Why would the update be done properly, but the page not be fully
updated with the changes?
Because EOF loves its cache. Loves it, loves it, loves it.
IMNSHO, caching should be OFF by default because it's behavior is
so confusing: you run an update, see the changes in the DB, then
run a query and ... see no changes in the UI. WTF?
At any rate, try the following:
// assuming you construct a fetch-spec "f"
EOFetchSpecification f = new EOFetchSpecification(...);
f.setRefreshesRefetchedObjects(true);
and see if your UI gets properly updated.
Don't get me wrong, WO's cache handling is top-notch. But having
values cached when you haven't explicitly asked for that behavior
is downright confusing the first time you encounter it.
zak.
_______________________________________________
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/webobjects%
40avendasora.com
This email sent to [EMAIL PROTECTED]
_______________________________________________
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/kenlists%
40anderhome.com
This email sent to [EMAIL PROTECTED]
_______________________________________________
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]
