myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Kienenberger (JIRA)" <...@myfaces.apache.org>
Subject [jira] Commented: (TOMAHAWK-498) detailStamp facet is decoded improperly if not all rows render the same components
Date Wed, 13 Sep 2006 15:24:24 GMT
    [ http://issues.apache.org/jira/browse/TOMAHAWK-498?page=comments#action_12434467 ] 
            
Mike Kienenberger commented on TOMAHAWK-498:
--------------------------------------------

It will be easier for us to commit this if someone will create a patch, and attach it as a
file to the issue, checking the grant-ASF-rights-to-the-code box.

> detailStamp facet is decoded improperly if not all rows render the same components
> ----------------------------------------------------------------------------------
>
>                 Key: TOMAHAWK-498
>                 URL: http://issues.apache.org/jira/browse/TOMAHAWK-498
>             Project: MyFaces Tomahawk
>          Issue Type: Bug
>    Affects Versions: 1.1.2
>            Reporter: Val Blant
>
> If the detailStamp facet contains some input fields which are conditionally rendered,
the fields which are not rendered in at least one row will cause the rest of the rows to render
incorrect values in the facet. Please read the comments below for more detail.
> This can be fixed by adding the code below to HtmlDataTable.processDetails() method right
before the call to
>  "process(context,facet,processAction);"
> 	            // If we are in the decode phase, the values restored into our
> 	            // facet in setRowIndex() may be incorrect. This will happen
> 	            // if some input fields are rendered in some rows, but not 
> 	            // rendered in others. In this case the input field components
> 	            // will still contain the _submittedValue from the previous row
> 	            // that had that input field and _submittedValue will not be set to 
> 	            // null by the process() method if there was no value submitted.
> 	            // Thus, an invalid component state for that row will be saved in
> 	            // _detailRowStates. The validation phase will not put a null into 
> 	            // _sumbittedValue either, b/c the component is not rendered, so
> 	            // validation code doesn't run. This erroneous value will propagate all
the way
> 	            // to the render phase, and result in all rows on the current page being
> 	            // rendered with the "stuck" _submittedValue, rather than evaluating the
> 	            // value to render for every row.
> 	            //
> 	            // We can fix this by initializing _submittedValue of all input fields in
the facet
> 	            // to null before calling the process() method below during the decode phase.
> 	            //
> 	            if ( PROCESS_DECODES == processAction ) {
> 	            	resetAllSubmittedValues(facet);
> 	            }
> 	private void resetAllSubmittedValues(UIComponent component) {
>            if ( component instanceof UIInput ) {
>         	((UIInput)component).setSubmittedValue(null);
>            }
>            for (Iterator it = component.getFacetsAndChildren(); it.hasNext(); ) {
>                resetAllSubmittedValues((UIComponent)it.next());
>            }
> 	}

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message