2009/9/3 Leonardo Uribe <[email protected]> > > > 2009/9/3 Curtiss Howard <[email protected]> > > Hi, >> >> I've got a bug I need to fix related to composite component attribute >> handling and I think this might be a possible issue to raise for the >> EG. Here's the background: >> >> We've got a page defined roughly as such: >> >> <h:form id="form1" prependId="false"> >> <ez:spinner value="#{number.number}" increment="10"/><br/> >> <h:outputText value="Last number submitted: #{number.number}" /><br/> >> <h:commandButton value="reload" type="submit"/><br/> >> <h:messages/> >> </h:form> >> >> The composite component implementation for <ez:spinner> is essentially >> a text field with some buttons. The value it references is >> #{cc.attrs.value}. >> >> The problem I'm seeing is that when I submit a value the text field >> updates with the new value, but the <h:outputText> will always output >> the original value (0 in this case). What's happening is that the >> composite component attribute map's "value" attribute is getting >> updated, but #{number.number}, what #{cc.attrs.value} _really_ points >> to, does not. The reason for this discrepancy is what makes me think >> this is something in the spec that needs to be addressed. >> >> According to the spec, the CC attributes EL resolver's setValue() >> method needs to retrieve the component's attributes map and call >> getValue(). If the result is a ValueExpression, call setValue(), >> which will in turn update the underlying bean property. Otherwise, do >> the default, which is to simply update the CC attributes map. The >> problem is that the component's getAttributes().get() method will >> auto-evaluate all ValueExpressions, so the CC attributes EL resolver >> never gets a _chance_ to see a ValueExpression. This is by design in >> the spec, so I'm confused as to how this is supposed to work. So far, >> I'm thinking that _ComponentAttributesMap() should have an alternate >> form of get() that will not evaluate ValueExpressions. What does >> everyone else think? >> >> Hi > > It seems when _ComponentAttributesMap().get is called, the resolution order > is this: > > - getter on component class > - attribute map > - ValueExpression (or binding) map > > Note that setValueExpression put a value expression on a binding map. > > I think we can avoid the hacks committed _ComponentAttributeMap, adding > some code on CompositeComponentAttributesMapWrapper.put() method that call > setValueExpression instead _originalMap.put. The problems starts from here, > and that is the reason why the ValueExpression is hidden. > > Looking the code again, maybe we are doing something wrong on CompositeComponentAttributesMapWrapper.put() method in CompositeComponentELResolver. Call _originalMap.put() is only valid if getAsValueExpression() is null or not ValueExpression. Otherwise, _originalMap.put() should not be called because it reverts the intention of call ValueExpression.setValue().
regards Leonardo Uribe > regards > > Leonardo Uribe > > >> Thanks, >> >> >> Curtiss Howard >> > >
