You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by Mikaël Cluseau <nw...@nwrk.dyndns.org> on 2004/10/26 17:56:15 UTC
Question about form actions handling
Hello people,
I remember that Howard asked the list about how to make form handling
more intuitive. I think about a kind of "two-pass" rewind.
Something intuitive is something that matches what the developer thinks
of the reality when his (her) code is ran.
In the context of a form action, it means that the page's data must
reflect the form's data that the user entered. From the operational
point of view, the action takes place at the "position" of the action in
the page (for example, the 10th iteration of a ForEach).
To achieve that, I suggest to use two rewinds :
1. Rewind the form to update the data ;
2. Rewind the form to reach the component who caused the action
(i.e. Submit or LinkSubmit) and execute it as usual.
This way, we have the data reflecting the form's data and the action
executed within the right context. Side effect : any clic in the form
will update the full form, so "update" buttons may be placed anywhere,
even before the first link (without ugly hacks the action handling).
I plan to do this work in my apps and, if it works well, I'll do a patch
and (try to) port it to Tapestry 3.1. But, I have two questions :
1. People of the list : what do you think of this approach ? (real
performance issues? better ways ?)
2. I don't know enough about Tapestry 3.1 internals, is this work
relevant in this context ?
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: Question about form actions handling
Posted by Mikaël Cluseau <nw...@nwrk.dyndns.org>.
Le mercredi 27 octobre 2004 à 08:14 -0400, Howard Lewis Ship a écrit :
> The blessing and the curse of OGNL is that we don't have an easy way
> of knowing where data comes from or goes; this makes a second rewind
> phase a chancy proposition.
In guess this is when we have, for instance, a checkbox controlling a
Conditional, because then the second rewind won't recreate the same
form. Sorry, I didn't though about that (I was looking for a solution in
the ForEach case).
Then, what about the following : make the ForEach (or the generated page
subclass setters, may work) record the property changes in a
"context" (something like "set property X to value Y", in a list) which
will be recorded by the triggered Submit; after the form's rewind, the
"context" is recreated by resetting properties in the same order as they
where during the rewind process and the action method is executed.
This could be added a possible value for the "execute" parameter
(deferred, immediate, in_context).
Is it a better draft ?
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: Question about form actions handling
Posted by Howard Lewis Ship <hl...@gmail.com>.
The blessing and the curse of OGNL is that we don't have an easy way
of knowing where data comes from or goes; this makes a second rewind
phase a chancy proposition.
Where we're headed with this is that components such as Submit will
automatically defer their invocation of the listener method until the
end of the rewind. For the rare case where Tapestry 3.0 behavior is
necessary, an "execute" parameter will be added (that defaults to
"deferred" but can be set to "immediate" for 3.0 behavior).
On Tue, 26 Oct 2004 17:56:15 +0200, Mikaël Cluseau <nw...@nwrk.dyndns.org> wrote:
> Hello people,
>
> I remember that Howard asked the list about how to make form handling
> more intuitive. I think about a kind of "two-pass" rewind.
>
> Something intuitive is something that matches what the developer thinks
> of the reality when his (her) code is ran.
>
> In the context of a form action, it means that the page's data must
> reflect the form's data that the user entered. From the operational
> point of view, the action takes place at the "position" of the action in
> the page (for example, the 10th iteration of a ForEach).
>
> To achieve that, I suggest to use two rewinds :
> 1. Rewind the form to update the data ;
> 2. Rewind the form to reach the component who caused the action
> (i.e. Submit or LinkSubmit) and execute it as usual.
>
> This way, we have the data reflecting the form's data and the action
> executed within the right context. Side effect : any clic in the form
> will update the full form, so "update" buttons may be placed anywhere,
> even before the first link (without ugly hacks the action handling).
>
> I plan to do this work in my apps and, if it works well, I'll do a patch
> and (try to) port it to Tapestry 3.1. But, I have two questions :
> 1. People of the list : what do you think of this approach ? (real
> performance issues? better ways ?)
> 2. I don't know enough about Tapestry 3.1 internals, is this work
> relevant in this context ?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
>
--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind
http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org