[ http://issues.apache.org/jira/browse/MYFACES-920?page=comments#action_12365867 ]
Simon Kitching commented on MYFACES-920: ---------------------------------------- Hmm..good point. I was only looking at the impl code at the point I wrote this. In that case, there's no problem. When impl code is used, the myfaces API code is also in use. However as you point out, UIComponentUtils is also used by tomahawk, where the myfaces API code may not be in use. A UIComponentUtils class used by Tomahawk against the RI will therefore not work correctly. The original problem is still real: getValueBinding is called on a component each time a new value is placed into a component's attribute map. Any suggestions on alternative workarounds, given that the API classes cannot have extra methods added? > Avoid invoking value-bindings during component initialisation > ------------------------------------------------------------- > > Key: MYFACES-920 > URL: http://issues.apache.org/jira/browse/MYFACES-920 > Project: MyFaces > Type: Improvement > Components: General > Reporter: Simon Kitching > Assignee: Simon Kitching > Attachments: UIComponentTagUtils.java.patch.txt, > _ComponentAttributesMap.java.patch.txt > > When a component is created by a JSP tag, calls to setStringProperty, > setBooleanProperty, etc are used to copy the JSP tag attributes onto the new > component. (NB: other view implementations will be doing something similar > I'm sure). > The setStringProperty et. al. eventually call > component.getAttributes().put(propName, value) > Unfortunately, the Map.put method is defined to return the old value of the > property. While the specs are a little vague on whether a return value is > actually required as far as I can see, both MyFaces and Sun do try to return > the old value. But this means calling the getter method on the component, > which typically calls getValueBinding(). > During component initialisation, this call to the component's getter method > and thence to getValueBinding isn't actually *too* bad; the binding will > never be found because each attribute is initially null, and is set only > once. However it's still inefficient; it's a call via reflection, a HashMap > lookup, etc. that is all completely unnecessary as the return value will (a) > always be null, and (b) is ignored. > This behaviour *is* a major pain for anyone (like me) who would like to > override the getValueBinding method for a component; it gets called once for > each attribute of the JSP tag, and during a time when the component is not > completely initialised. And there's no way to tell when component > initialisation has completed as far as I know. > Attached is a proposed solution. The UIComponent.getAttributes method returns > a custom (private) Map implementation already. It isn't possible to add any > methods to this, as it's in the API namespace. Instead I've modified the put > method so that if the provided propName has a special prefix then the method > doesn't bother to fetch and return the old value. Updating the > setStringProperty/setBooleanProperty/etc methods to add the prefix then > solves the issue. > What do people think of this? Is this ok to commit? > NB: I will be creating some unit tests to go along with this, to prove that > the patch does what it says. I don't have time just now, though, and wanted > to post this before I left for the weekend. > NB2: If this does go in (or some other solution to this problem) I've got a > rather cool use for it. A "backingBean" attribute can then be defined on a > component, and via a customised ValueBinding, any property on the component > that supports value-binding will automatically try to fetch the data from an > identically-named property on the specified backingBean for the component. > It's very useful when dealing with components with lots of bindable > properties, like a UIData - or my custom extension of that class, which has > even more properties. -- 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
