tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Howard M. Lewis Ship (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (TAP5-2391) Field-specific error not shown when AJAX used
Date Tue, 07 Apr 2015 22:54:13 GMT

    [ https://issues.apache.org/jira/browse/TAP5-2391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14484274#comment-14484274
] 

Howard M. Lewis Ship commented on TAP5-2391:
--------------------------------------------

Ok, I've found a way that is much more palatable to make this work.

Basically, it comes down to this: it was hard to coordinate the form submission with the re-rendering,
largely because of complex ids (ids with a random suffix, to ensure that there are no id clashes
across Ajax requests).

The client id is used as the basis of the control name; the end result is that during the
render, a different client id is used, and so a different control name.

My latest take on the fix is to base the control name of the component's simple component
id, not its dynamically allocated id (itself based on the component id).

This immediately gets the desired behavior for simple forms, and probably for complex forms
(with loops and conditionals) as long as there is not too much (any?) change in the structure
of the data (number of iterations, selection of conditional portions) between the submit and
the re-render.

Ultimately, complex client-side forms by Ajax are a bit of a intractible problem, which is
why I've moved more towards client solutions such as AngularJS, Backbone, or React.

> Field-specific error not shown when AJAX used
> ---------------------------------------------
>
>                 Key: TAP5-2391
>                 URL: https://issues.apache.org/jira/browse/TAP5-2391
>             Project: Tapestry 5
>          Issue Type: Bug
>          Components: tapestry-core
>    Affects Versions: 5.4
>            Reporter: Geoff Callender
>            Assignee: Howard M. Lewis Ship
>            Priority: Blocker
>              Labels: 54_release_prerequisite
>             Fix For: 5.4
>
>
> Found this bug in 5.4-beta-22. I've confirmed that the bug was not present in 5.4-beta-6.
> When an error is recorded with Form.recordError(Field field, String errorMessage) or
ValidationTracker.recordError(Field field, String errorMessage) it normally is shown in the
UI by decorating the field in error and displaying the errorMessage below it.
> In 5.4-beta-6 and every release ever before that, that was the behaviour regardless of
whether the request is non-AJAX or AJAX.  
> In 5.4-beta-22, the behaviour changes when the request is AJAX: the field does not display
an error. That is, the field is *not* decorated and the errorMessage is *not* shown with it.
If your Errors component has globalOnly="true", which is the norm these days, then you won't
even see the error message there! If you set globalOnly="false" then the message *is* shown,
but who would want to set globalOnly="false"???  
> Comparing the HTTP responses of beta-22 with beta-6, I see that beta-6 had an extra entry
in the inits, like this:  
> ["t5/core/fields:showValidationError", "firstName_8cf3108fe0ece9", "First Name must not
be Acme."]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message