Re: Updating EOObjects
Re: Updating EOObjects
- Subject: Re: Updating EOObjects
- From: "Jerry W. Walker" <email@hidden>
- Date: Fri, 19 Aug 2005 00:16:03 -0400
I have two things to add to Arturo's advice below:
First, Arturo described a means to an end. The means he described is:
"to follow a style of doing most of your work in the
appendToResponse() and to never mutate any
on-page data through the key values that WOBuilder
can see"
The end that he's trying to accomplish is to avoid one of the more
pernicious problems in WO applications, that is the effects of
changing a WOComponent's template (or structure) between the time
that a page is first rendered (using appendToResponse to send out the
response in which the page is defined) and the time that the next
request from that page is processed (all the way through invoking the
page's action method by invokeAction()).
You can actually mutate much of the page's data through the key
values that WOBuilder can see, but you must absolutely avoid mutating
any data on which the page's template (or structure) depends between
the two times mentioned above.
Chuck and Sacha's book, Practical WebObjects, goes over the process
of building a component template in some detail in Chapter 6 and
discusses this problem directly in Chapter 7 in which they state
their "Golden Rule":
Don't modify anything that the component or dynamic elements depend
on while in the sequence appendToResponse, takeValuesFromRequest,
and invokeAction.
If you violate this rule, the page starts acting in a schizophrenic
manner to all kinds of user actions. The user clicks the submit
button and instead the page deletes some data. Fields of data get
lost or their values end up in other fields.
This problem has been discussed a few times on the list and can
probably be found by Googling the mailing lists for "changing
component template" or some variation on that.
The second thing I wanted to add goes back to more directly address
Jonathon Miller's original questions about updating EOs; that is, the
EOF Commandments or what to do and what not to do when working with
Enterprise Objects. These commandments can be found here and should
be followed:
http://wodev.spearway.com/cgi-bin/WebObjects/WODev.woa/2/wa/
Main?wosid=false&wikiPage=EOFCommandments
Regards,
Jerry
On Aug 18, 2005, at 10:47 PM, Arturo Pérez wrote:
On Aug 18, 2005, at 9:47 PM, Owen McKerrow wrote:
On 19/08/2005, at 11:15 AM, Arturo Pérez wrote:
Hi Jon,
That's a fine way to start. I know a bunch of the luminaries on
the list prefer a different style but simple will get you started.
The other big thing is to follow a style of doing most of your
work in the appendToResponse() and to never mutate any on-page
data through the key values that WOBuilder can see.
Using the above then your createAndInsertInstance would be used
like this
public void appendToResponse(....) {
if (aLicense == null) aLicense = ...createAndInsert...;
if (aPrincipal == null) aPrincipal = ...createAndInsert...;
super.appendToResponse(...);
}
Are you saying that you do all your object manipulation in the
appendToresponse ? Or I maybe Im mis-understanding.
Hmm I have never heard of this before. Can you explain your
reasoning here Arturo ?
Kinda. It's what some Apple field engineers told me to do once
upon a time.
One runs into problems if the getters/setters mutate their values,
especially if they are used as conditionals. One way to avoid this
to do save those mutating things for the appendToResponse(),
takeValues() and invokeAction phases of the RR.
I've been burned tons of times because I forgot about the mutating
rule.
--
__ Jerry W. Walker, Partner
C o d e F a b, LLC - "High Performance Industrial Strength
Internet Enabled Systems"
email@hidden
212 465 8484 X-102 office
212 465 9178 fax
_______________________________________________
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