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

[Dan Allen]

On Wed, Apr 8, 2009 at 1:07 PM, Ken Paulsen <Ken.Paulsen at sun.com> wrote:

> While perhaps it can be simplified to a shorter name, or one that doesn't
> build off "compositeComponent", I feel strongly that all EL should be given
> the opportunity to be specified explicitly.  For example: #{foo} vs.
> #{requestScope.foo} vs. #{sessionScope.foo}, vs.
> #{compositeComponent.attrs.foo}.  So, not only is there a performance
> penalty for being a lazy developer and not being explicit (requiring a
> search of all scopes until found), but there is also a name-space problem.
>  I also argue that it hurts readability of your code to not be explicit.  I
> discourage all implicit EL references -- IMO, it's simply bad practice.


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.

While the performance argument doesn't really apply here, there is another
problem. The Facelets vars shadow all other EL attributes, so the more
attributes you have the more likely that will happen. For instance, say you
have an attribute named "view" and in the implementation you were trying to
use the implicit object "view". Now you have a problem.

-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/09664ea6/attachment.html