You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by raulmt <ra...@gmail.com> on 2010/12/21 21:46:43 UTC
Re: Ajax and Validation
Today I found the same problem: persist flash doesn't behave well for an Ajax
request, because the error can be shown two times if you refresh the page
(first one with the form ajax response and second one if you refresh the
page). Maybe when processing the request, if it is an Ajax request, the
validation tracker should not be saved in a persist flash field but in a
regular field?
If any commiter agrees with this, could I file an issue about this?
Regards,
Raul.
--
View this message in context: http://tapestry-users.832.n2.nabble.com/Ajax-and-Validation-tp2678846p5855924.html
Sent from the Tapestry Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Ajax and Validation
Posted by Dmitry Gusev <dm...@gmail.com>.
I know this thread is too old, but I still have this same issue in T5.3.7.
Since @PageDetached is no longer works, here is how I managed to fix this
for my form:
@Inject private Heartbeat heartbeat;
public void onSubmit()
{
if (request.isXHR())
{
// ...
ajaxResponseRenderer.addCallback(new JavaScriptCallback()
{
@Override
public void run(JavaScriptSupport javascriptSupport)
{
// ...
heartbeat.defer(new Runnable()
{
@Override
public void run()
{
form.clearErrors();
}
});
}
});
}
}
On Mon, Jun 13, 2011 at 10:07 PM, Kartweel <rh...@exemail.com.au> wrote:
> It still gave me issues when submitting a form with an error then
> submitting
> it valid, then it would bring up the old values and clobber the real values
> (after saving I default back to different data in the form).
>
> So I ammended it to
>
>
> @PageDetached
> void clearValidationTracker() {
> if (request.isXHR()) {
> if (workItemsForm.getDefaultTracker() != null)
> workItemsForm.getDefaultTracker().clear();
> workItemsForm.setDefaultTracker(null);
> }
> }
>
>
> --
> View this message in context:
> http://tapestry.1045711.n5.nabble.com/Ajax-and-Validation-tp2431706p4485240.html
> Sent from the Tapestry - User mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
Dmitry Gusev
AnjLab Team
http://anjlab.com
Re: Ajax and Validation
Posted by Kartweel <rh...@exemail.com.au>.
It still gave me issues when submitting a form with an error then submitting
it valid, then it would bring up the old values and clobber the real values
(after saving I default back to different data in the form).
So I ammended it to
@PageDetached
void clearValidationTracker() {
if (request.isXHR()) {
if (workItemsForm.getDefaultTracker() != null)
workItemsForm.getDefaultTracker().clear();
workItemsForm.setDefaultTracker(null);
}
}
--
View this message in context: http://tapestry.1045711.n5.nabble.com/Ajax-and-Validation-tp2431706p4485240.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Ajax and Validation
Posted by Kartweel <rh...@exemail.com.au>.
Hi,
I've had major issues with this because the ValidationTracker also reloads
old field values which in a non-ajax scenario is great, but in an ajax
scenario has caused it to clobber the proper field values. It has caused
many headaches and I think it really should be handled [better] by default
in tapestry.
I think I just came across a simple solution to the issue (that i was
specifically having anyway)
@PageDetached
void clearValidationTracker() {
if (request.isXHR()) {
if (form.getDefaultTracker() != null) form.getDefaultTracker().clear();
}
}
In early testing it seems to do what I want.
I also wrote a dummy validation tracker which doesn't persist. But it means
there is no fallback on non-ajax (which was fine for me because my objects
were persisted anyway).
Side note: I've done quite a bit of Ajax and forms in tapestry and found in
general they are nasty together. Almost to the point where I want to dump
tapestry and just code it with javascript and something a lot dumber on the
server side. Then forms and loops and ajax and wowzers!.
--
View this message in context: http://tapestry.1045711.n5.nabble.com/Ajax-and-Validation-tp2431706p4485141.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Ajax and Validation
Posted by raulmt <ra...@gmail.com>.
Thiago, I'm not saying to change the behaviour of the flash persistence. What
I mean is to change the way the Form uses this. For example, the Form could
have two properties: one with @Persist(PersistenceConstants.FLASH) and one
without it, and access the correct one through a private method. If the
request is a traditional request, then this method should return the value
holded by the persistent property, but if the request is an Ajax one, then
this method should return a ValidationTracker saved in the property without
persistence.
If I didn't explain this well enough please tell me (I'm not a native
english speaker).
Regards,
Raul.
--
View this message in context: http://tapestry-users.832.n2.nabble.com/Ajax-and-Validation-tp2678846p5860647.html
Sent from the Tapestry Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Ajax and Validation
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Changing the current behavior of the flash persistence can lead to many
hard-to-detect backward compatibility problems. I think a good solution
for this specific scenario is to set the message property to null in a
@PageDetached method.
Maybe a better solution is to create other persistence strategy similar to
flash which clears the info from the session after a request is finished.
On Tue, 21 Dec 2010 18:46:43 -0200, raulmt <ra...@gmail.com> wrote:
>
> Today I found the same problem: persist flash doesn't behave well for an
> Ajax
> request, because the error can be shown two times if you refresh the page
> (first one with the form ajax response and second one if you refresh the
> page). Maybe when processing the request, if it is an Ajax request, the
> validation tracker should not be saved in a persist flash field but in a
> regular field?
>
> If any commiter agrees with this, could I file an issue about this?
>
> Regards,
> Raul.
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, Ars Machina Tecnologia da Informação Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org