[jira] [Comment Edited] (TAP5-2391) Field-specific error not shown when AJAX used

["Geoff Callender (JIRA)" <ji...@apache.org>]

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

Geoff Callender edited comment on TAP5-2391 at 3/22/15 2:30 AM:
----------------------------------------------------------------

I can confirm that the original issue has been fixed in beta-26, and the new symptom that George has reported affects is not confined to AJAX calls. It affects Grid and Loop. It breaks all 6 of these examples which worked correctly in beta-22:

    http://jumpstart.doublenegative.com.au/jumpstart7/examples/tables/editablegrid1
    http://jumpstart.doublenegative.com.au/jumpstart7/examples/tables/editablegridforupdate1
    http://jumpstart.doublenegative.com.au/jumpstart7/examples/tables/gridwithdeletecolumn1
    http://jumpstart.doublenegative.com.au/jumpstart7/examples/tables/editableloop1
    http://jumpstart.doublenegative.com.au/jumpstart7/examples/tables/editableloopforupdate1
    http://jumpstart.doublenegative.com.au/jumpstart7/examples/tables/loopwithdeletecolumn1

The symptom is that when the server-side records an error and returns the page, every input-capable field of the Grid or Loop shows the same value as its counterpart in the last row. Field level error messages do not show.

Some of the above examples use formstate="ITERATION", while others use a ValueEncoder.

Like Felix, I see that each Field has null clientId. In these examples, when each field bubbles up VALIDATE we have an event handler that copies the Field to a FieldCopy, but the Field's clientId is null, so that's a problem when we try to use it later in Form#recordError.


was (Author: geoffcallender):
I can confirm that the original issue has been fixed in beta-26, and the new symptom that George has reported affects is not confined to AJAX calls. It affects Grid and Loop. It breaks all 6 of these examples which worked correctly in beta-22:

    http://jumpstart.doublenegative.com.au/jumpstart7/examples/tables/editablegrid1
    http://jumpstart.doublenegative.com.au/jumpstart7/examples/tables/editablegridforupdate1
    http://jumpstart.doublenegative.com.au/jumpstart7/examples/tables/gridwithdeletecolumn1
    http://jumpstart.doublenegative.com.au/jumpstart7/examples/tables/editableloop1
    http://jumpstart.doublenegative.com.au/jumpstart7/examples/tables/editableloopforupdate1
    http://jumpstart.doublenegative.com.au/jumpstart7/examples/tables/loopwithdeletecolumn1

The symptom is that when the page returns a server-side detected error, every input-capable field of the Grid or Loop shows the same value as its counterpart in the last row. Field level error messages do not show.

Some of the above examples use formstate="ITERATION", while others use a ValueEncoder.

Like Felix, I see that each Field has null clientId. In these examples, when each field bubbles up VALIDATE we have an event handler that copies the Field to a FieldCopy, but the Field's clientId is null, so that's a problem when we try to use it later in Form#recordError.

> 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)