Hi, Why not simply NOT support a PropertyKey for the id attribute? I know it isn't consistent with the other properties, but id is a very special case not supporting EL anyway. In all the project I ever did, I never used FacesBean.getProperty(ID_PROPERTY_KEY). The only drawback I would see is if the component's id actually need to be read in a property getter method in a renderer which receive only the FacesBean instance and not the component itself. That would be much faster than a custom ValueExpression and the memory footprint would also be better.
Regards, ~ Simon On Tue, Jan 5, 2010 at 1:49 PM, Matthias Wessendorf <[email protected]>wrote: > On Thu, Dec 31, 2009 at 11:12 PM, Blake Sullivan > <[email protected]> wrote: > > UIComponent.getId() is by far the most requested component attribute. > There > > are a number of reasons for this: > > 1) The JSF RI has an issue in the JSP-JSF integration which causes > getId() > > to be called n^2 times where n is the number of children a component has > > I guess this is true for MyFaces as well, right? > > > 2) getClientId() calls getId() > > 3) FindComponent calls getId() > > 4) The tree visiting code trades off calls to getClientId() for calls to > > getId() > > > > FacesBean optimizes attribute Map access at the expense of access > directly > > through the component. The the extent that Renderers are Components are > > accessing the attributes through the attribute Map, this is fine, however > > even the Renderers access attributes common to all UIComponents such as > id() > > through the component directly. Considering the huge number of times > that > > the the id is accessed (for some renders, this was 8% of the rendering > > time), it makes sense to optimize this path. > > > > The proposal is to: > > 1) Store the id an an instance variable on the UIXComponent > > 2) Add a new capability flag to PropertyKey indicating that the property > is > > actually stored elsewhere using a ValueExpression will be stored as the > > property's value in the PropertyMap. For access through the FacesBean, > the > > ValueExpression will be evaluated to get/set the actual value > > 3) For state saving the ValueExpression is used to retrieve the actual > value > > and for state restoration the ValueExpression (which has been > rebootstrapped > > by the UIXComponent) is used to write the value back > > 4) Instead of setting the id attribute in the FacesBean, UIXComponent > stores > > it locally and sets an ValueExpression implementation into the FacesBean > > that retrieves the value from the UIXComponent > > +1 on api/patch > > > > > API Changes: > > > > PropertyKey: > > > > add > > > > /** > > * Capability indicating that values for this property should be > > * be stored and retrieved through a ValueExpression rather than on the > > * FacesBean itself > > */ > > static public final int CAP_VALUE_EXPRESSION_IMPLEMENTATION = 16; > > > > /** > > * Returns <code>true</code> if property values for this key are set and > get > > * using a ValueExpression rather than storing the value in the > FacesBean. > > * @return <code>true</code> if properties values for this key are > retrieved > > * with a ValueExpression. > > */ > > public boolean usesValueExpressionAsImplementation() > > > > After this change id retrieval doesn't make the 1% YourKit profiler hot > spot > > cut off > > > > > > > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf >
