Re: Problem with form values, using WOConditional with action within it
Re: Problem with form values, using WOConditional with action within it
- Subject: Re: Problem with form values, using WOConditional with action within it
- From: "Jerry W. Walker" <email@hidden>
- Date: Mon, 23 Jan 2006 08:48:50 -0500
Hi, Peter,
On Jan 23, 2006, at 6:54 AM, Peteris Krisjanis wrote:
I have rather interesting situation here. I have one simple form
with couple of text fields, popup fields, etc. Everything was so
far so good - I click submit, every value binds properly. So,
nothing wrong here.
Next level was that I create optional fields for user to fill, but
first user could turn them visible/invisible by using action trough
link and WOConditional. Again, so far so good - values was saved,
so I turned on/off WOConditional - values was still there.
BUT now I fail to recreate such effect in newly created page.
Whatever I choose link with action to change value of
WOConditional, I got all field ?values nullified. Actions is the
same, t.i. in both versions I just change value of Boolean and
return null, t.i. don't change the page. In fact, code was coppied
and pasted and just applied to new style of the form.
What I could be doing wrong and what should be done to achieve
desired effect, using WOConditional and action to turn it on/off
within form?
It sounds like your page structure may be changing between the end of
your appendToResponse and the end of your invokeAction methods. If
so, you should not allow this. One of the more pernicious problems in
WebObjects results from such a change.
If the value on which your WOConditional depends is being set
directly from within the form, then the structure of the page is
changing during the takeValuesFromRequest. The problem is that WO
builds a template at the beginning of each of these methods
(appendToResponse, takeValuesFromRequest and invokeAction) to
properly identify each of the WOComponents and WOElements on the page.
The structure is established by the appendToResponse and creates a
context within which these values are identified by the next two
methods (takeValuesFromRequest and invokeAction) on the subsequent
request from that page. If the structure changes before both of these
subsequent methods complete, then they get confused as to which
values go into which variables and which action method should be
triggered by the request.
The easiest way around this is to provide variables on which the page
structure depends that will ONLY be updated in the appendToResponse.
So, for instance, you provide two variables, userSeesOptions and
showOptions. The first, userSeesOptions, is bound to a reveal
triangle (or a check box or whatever) on your page, but your
WOConditional DOES NOT depend on that variable directly. Rather, the
WOConditional is bound to showOptions which is set to the value of
userSeesOptions in your overridden appendToResponse method, which
could look like this:
public void appendToResponse(WOResponse r, WOContext c)
{
showOptions = userSeesOptions;
super.appendToResponse(r, c);
}
Note that the showOptions variable changes just before the call to
super. Now you're guaranteed that your page structure will only
change upon sending out the new response.
If you do this with any variables on which WOConditionals depend and
any variables that set the sizes of arrays used by WORepetitions,
then you should be able to avoid this problem.
I've been thinking recently that WO ought to be able to identify this
problem and raise an exception whenever it occurs. All it would
require is some sort of checksum based on the page's structure when
the page is created in the appendToResponse that is maintained in
WOContext. When the template is rebuilt in takeValuesFromRequest and
invokeAction, the checksum could be recreated and compared to that in
the WOContext. If the two values differ, WO should throw a
PageStructureChangedException.
The two worst aspects of this particular problem are:
1) that it causes problems intermittently (often working OK until
you're in production)
2) it manifests itself in different ways (tends to cause WO to
behave schizophrenically on that page)
Regards,
Jerry
--
__ Jerry W. Walker,
WebObjects Developer/Instructor for High Performance Industrial
Strength Internet Enabled Systems
email@hidden
203 278-4085 office
_______________________________________________
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