[TOMAHAWK-494] detailStamp facet is decoded/validated/updated twice

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 1.1.2
• Fix Version/s: 1.1.4-SNAPSHOT
• Assignee: Martin Marinschek
• Reporter: Val Blant
• Created: 14/Jun/06 23:13
• Updated: 25/Jun/11 19:34
• Resolved: 19/Sep/06 06:04

Description

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