myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Simon Kitching (JIRA)" <>
Subject [jira] Commented: (MYFACES-920) Avoid invoking value-bindings during component initialisation
Date Fri, 10 Feb 2006 09:39:56 GMT
    [ ] 

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

> Avoid invoking value-bindings during component initialisation
> -------------------------------------------------------------
>          Key: MYFACES-920
>          URL:
>      Project: MyFaces
>         Type: Improvement
>   Components: General
>     Reporter: Simon Kitching
>     Assignee: Simon Kitching
>  Attachments:,
> 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:
For more information on JIRA, see:

View raw message