detailStamp facet is decoded/validated/updated twice
----------------------------------------------------
Key: TOMAHAWK-494
URL: http://issues.apache.org/jira/browse/TOMAHAWK-494
Project: MyFaces Tomahawk
Type: Bug
Versions: 1.1.2
Reporter: Val Blant
All input fields in detailStamp facet will be processed twice.
The first time they will be processed from UIData.processFacets() without the
proper context set up! (i.e. setRowIndex()) is not executed at all.
The second time the facet will be processed with proper context from
org.apache.myfaces.component.html.ext.HtmlDataTable.processDetails()
Even though the facet is eventually processed correctly, this behavior is not
harmless as it has serious repercussions for valueChangeListeners or any
backing bean methods that are executed b/c they are attached to some attributes
(ex. the 'rendered') attribute.
This can be fixed by removing the facet from the JSF tree before calling the
superclass functionality and putting it back when you are ready to process it.
This means that a change is required to these methods in
org.apache.myfaces.component.html.ext.HtmlDataTable:
public void processDecodes(FacesContext context)
public void processValidators(FacesContext context)
public void processUpdates(FacesContext context)
For example, in processDecodes() the change would look like this:
// We must remove and then replace the facet so that
// it is not processed by default facet handling code
//
Object facet =
getFacets().remove(HtmlTableRenderer.DETAIL_STAMP_FACET_NAME);
super.processDecodes(context);
if ( facet != null )
getFacets().put(HtmlTableRenderer.DETAIL_STAMP_FACET_NAME, facet);
--
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