[jsr-314-open] #{compositeComponent.attrs....}

[Dan Allen]

On Wed, Apr 8, 2009 at 2:23 PM, Andy Schwartz <andy.schwartz at oracle.com>wrote:

> Dan Allen wrote On 4/8/2009 1:59 PM ET:
>
>> In general I agree with Ken. I have been able to measure considerable
>> performance degradation from not qualifying any EL expression. However, in
>> this particular case, Facelets always checks its own context first before it
>> even delegates to an EL resolver (since it has control over the template and
>> hence the initial EL lookup.
>>
>
> Though if the attribute in question isn't actually set by the user of the
> composite component, then we won't find the attribute in the component's
> attribute map, which presumably means that we end up going through normal
> EL/managed bean resolving, which gets us back to the performance hit.


Yes, very true. In fact, that brings up a very important point. Can we
expose the facelets variable map as an implicit variable so that we can look
in the map and stop looking if it doesn't not exist?? This would be relevant
in the case that David cited, when we are accessing attribute values in a
composition.

<h:graphicImage style="border: none" value="#{faceletsContext.image}"/>

This satisfies Ken's best practice in this use case.

-Dan

-- 
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action

http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://in.relation.to/Bloggers/Dan

NOTE: While I make a strong effort to keep up with my email on a daily
basis, personal or other work matters can sometimes keep me away
from my email. If you contact me, but don't hear back for more than a week,
it is very likely that I am excessively backlogged or the message was
caught in the spam filters.  Please don't hesitate to resend a message if
you feel that it did not reach my attention.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jsr-314-open-mirror/attachments/20090408/3850a3c9/attachment.html