The following

11/30/05, Reggie Chan <reggie (AT) tnc (DOT) hkwrote:
After further reading the source code of tapestry, I found that it seems
my previous guess of relying browser's input ordering in approach 1 and
2 were wrong that tapestry actually uses the order in which the
components are found in the page/component template's body. And as
approach 1 and 2 set the Hidden key field as the first input in the
form's body, it becomes the first inner component in the form and thus
the first component to render/rewind, this ensure that the key is the
first formComponent to be updated in the form.

is correct, fields are processed as rendered (rewound) so if your
hidden is the first form component rendered, it will be rewound before
any others. Note that conditionals can make this tricky (unless of
course you use If components instead of Conditionals).

Could someone tell if the above understanding of the source code is
correct? Thanks!

Reggie Chan wrote:
I'm using tapestry 4 and hibernate in our application, we are using
ognl to update the domain object's properties like user.login,
user.email etc However, we are unable to load the user object before
these properties being set during the rewind stage.

After looking at mailing list archive and forum, I've found the
following approaches to deal with the problems

1. Adding a hidden field as the first input in the form and use
IActionListener to load the domain object from hibernate. This relies
on the fact that I.E. passes first fields up in the order of they are
shown in the form. However, does it have to happen for other browsers
and for I.E. 7 for future extensibility? I've found that firefox use
the order that the input nodes created instead of the order that they
are shown in the html. Although in this case, most likely, the hidden
key input would still be the first input to be passed to the server,
this does show the possibility that different browser could have
different behavior in that aspect.

2. Using DataSqueezer to load the domain object. I haven't tried this
yet, but does it always have to ensure that the hidden key field is
passed as the first input?

3. Using a "fake" domain object and then copy all properties over to
the real domain object before save.

4. Temporarily save the properties to the page object then copy all to
the real domain object before save.

5. Use http session to persist the domain object, but the user will
not be able to open muiltiple tags in firefox or clone a new browser
instance by "Ctrl-n" in I.E. as they will share the same session.

6. Use http session as 5., but add a sychronization token in all form
to avoid mis-updating.

I think this problem is pretty much a common problem to many users,
could someone share how they deal with this issue and give us some
advice on the issue. We're afraid that we've missed out some better
ways to deal with the issue in tapestry, as we are new to tapestry
e.g. we can tell tapestry to set certain properties first and the
others after instead of relying on browser's behavior, etc
development team has struggled in this issue pretty badly.

Thanks in advance!

To unsubscribe, e-mail: tapestry-user-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: tapestry-user-help (AT) jakarta (DOT) apache.org
>
>
>

To unsubscribe, e-mail: tapestry-user-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: tapestry-user-help (AT) jakarta (DOT) apache.org
--