You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by "Val Blant (JIRA)" <de...@myfaces.apache.org> on 2006/06/14 18:14:29 UTC

[jira] Created: (TOMAHAWK-494) detailStamp facet is decoded/validated/updated twice

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


[jira] Resolved: (TOMAHAWK-494) detailStamp facet is decoded/validated/updated twice

Posted by "Martin Marinschek (JIRA)" <de...@myfaces.apache.org>.
     [ http://issues.apache.org/jira/browse/TOMAHAWK-494?page=all ]

Martin Marinschek resolved TOMAHAWK-494.
----------------------------------------

    Fix Version/s: 1.1.4-SNAPSHOT
       Resolution: Fixed
         Assignee: Martin Marinschek

Thanks to Val Blant.

> detailStamp facet is decoded/validated/updated twice
> ----------------------------------------------------
>
>                 Key: TOMAHAWK-494
>                 URL: http://issues.apache.org/jira/browse/TOMAHAWK-494
>             Project: MyFaces Tomahawk
>          Issue Type: Bug
>    Affects Versions: 1.1.2
>            Reporter: Val Blant
>         Assigned To: Martin Marinschek
>             Fix For: 1.1.4-SNAPSHOT
>
>
> 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

        

[jira] Commented: (TOMAHAWK-494) detailStamp facet is decoded/validated/updated twice

Posted by "Simon Middleton (JIRA)" <de...@myfaces.apache.org>.
    [ http://issues.apache.org/jira/browse/TOMAHAWK-494?page=comments#action_12434424 ] 
            
Simon Middleton commented on TOMAHAWK-494:
------------------------------------------

Could a committer have a look at this please. The code change provided works fine.

> detailStamp facet is decoded/validated/updated twice
> ----------------------------------------------------
>
>                 Key: TOMAHAWK-494
>                 URL: http://issues.apache.org/jira/browse/TOMAHAWK-494
>             Project: MyFaces Tomahawk
>          Issue Type: Bug
>    Affects 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