Re: Updating Nested To-Many Relationship *NOT SOLVED*
Re: Updating Nested To-Many Relationship *NOT SOLVED*
- Subject: Re: Updating Nested To-Many Relationship *NOT SOLVED*
- From: Chuck Hill <email@hidden>
- Date: Wed, 11 Apr 2007 09:07:53 -0700
Paging Mr. Walker, Mr. Jerry Walker. Mr. Jerry Walker, please come
to the WO List. :-)
This is one of Jerry's most favored rants. I am pretty sure that
what is happening is that you are modifying the structure of the page
while it is processing the takeValues phase. Search for some of
Jerry's past postings on this for the cause and solution.
Chuck
On Apr 10, 2007, at 8:42 PM, David Avendasora wrote:
Okay, I spoke too soon.
It works to change SOME relationships, but not others. Here's what
it does:
For example, if I change the relationship of a RSComponent from
RoutingStep 4 to RoutingStep 3, it works as expected, simply
changing both sides of the RoutingStep<-->>RSComponent
relationship. BUT, if I then change the same RSComponent
relationship back from RoutingStep 3 to RoutingStep 4, it also
updates the relationship as expected, and then it continues on to
set all the attributes and relationships of the RSComponent to null!
What is causing it to do this extra step of nullifying everything?!
I have also seen it "hijack" the values of an existing RSComponent
in the target RoutingStep, then nullify all attributes of the
RSComponent that it hijacked. This effectively makes it look like
the RSComponent that I was moving from one RoutingStep to another
disappears, but in fact it's there, just having been updated to
look exactly like an existing RSComponent.
Very strange.
Dave
On Apr 10, 2007, at 1:29 PM, David Avendasora wrote:
Thanks Ken!
Once I read your message it seems SO obvious. I had to modify my
EOGenerator template to add the new getter method, but once I did
that and changed the binding, it works perfectly!
Dave
On Apr 10, 2007, at 1:08 PM, Ken Anderson wrote:
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@hidden)
Help/Unsubscribe/Update your Subscription:
@avendasora.com
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40anderhome.com
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40avendasora.com
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40global-village.net
This email sent to email@hidden
--
Practical WebObjects - for developers who want to increase their
overall knowledge of WebObjects or who are trying to solve specific
problems.
http://www.global-village.net/products/practical_webobjects
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden