myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jakob Korherr (JIRA)" <...@myfaces.apache.org>
Subject [jira] Commented: (MYFACES-2671) MYFACES-2633 regresses the ezcomp spinner example
Date Sun, 25 Apr 2010 21:25:51 GMT

    [ https://issues.apache.org/jira/browse/MYFACES-2671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12860763#action_12860763
] 

Jakob Korherr commented on MYFACES-2671:
----------------------------------------

The code committed in MYFACES-2633 also causes BeanValidation to stop working on composite
components, because the actual ValueExpression is not on the component's attribute map anymore
and thus the BeanValidator can't access it. I created a separate issue for this problem (MYFACES-2675),
but the cause for it is the same as for this issue.

> MYFACES-2633 regresses the ezcomp spinner example
> -------------------------------------------------
>
>                 Key: MYFACES-2671
>                 URL: https://issues.apache.org/jira/browse/MYFACES-2671
>             Project: MyFaces Core
>          Issue Type: Bug
>          Components: JSR-314
>    Affects Versions: 2.0.0
>            Reporter: Michael Concini
>
> The change to CompositeComponentRule committed by MYFACES-2633 actually does break the
ezcomp RI sample.  Specifically, in the spinner example it is causing the last value submitted
to not be updated when you click the reload button.  It has reverted to the same behavior
that was fixed by MYFACES-2340.  
> I did some playing around, and it seems that both adding the ValueExpression directly
to the map AND calling instance.setValueExpression() seems to resolve both cases.  
>       ((UIComponent) instance).getAttributes().put(_name, _attr.getValueExpression(ctx,
_type));  //right now this first line is commented out
>        ((UIComponent) instance).setValueExpression(_name, _attr.getValueExpression(ctx,
_type));
> As far as I can tell, I haven't seen any repercussions to leaving both calls in place,
but it feels like there should be a more elegant solution.   I'll leave this open for discussion
for a few days in case someone has another idea for a resolution before I check in the change.
  
> In the meantime, I'll do some additional testing to make sure there aren't any side affects
of making both calls.  

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message