10:45 a.m.
Is it possible to dispense with having to type "#compositeComponent.attrs."
in the implementation sections of composite components? It's cumbersome.
Besides, Facelets custom tags let you access attribute values with their
simple names, for example you could use a Facelets tag like this:
<mytags:planet name="mercury"
image="#{resource['images:Mercury.gif']}"/>
and in the implementation of the planet tag, you can do this:
<h:graphicImage style="border: none"
value="#{image}"/>
With a JSF composite component, you have to do
..value="#{compositeComponent.attrs.image}". Maybe I'm missing something,
but it doesn't seem to be too much of a technical feat to remove the need to
type compositeComponent.attrs (a variable resolver that searches
compositeComponents.attrs, as necessary?)
It seems weird that we're taking a step backwards in this respect, even as
we move forward from Facelets tags to more feature-rich composite
components.
david
12:07 p.m.
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.
That said, we support implicit references (in addition to their explicit
alternatives) in many places, what's one more. :P
Ken
David Geary wrote:
Is it possible to dispense with having to type
"#compositeComponent.attrs." in the implementation sections of
composite components? It's cumbersome. Besides, Facelets custom tags
let you access attribute values with their simple names, for example
you could use a Facelets tag like this:
<mytags:planet name="mercury"
image="#{resource['images:Mercury.gif']}"/>
and in the implementation of the planet tag, you can do this:
<h:graphicImage style="border: none"
value="#{image}"/>
With a JSF composite component, you have to do
...value="#{compositeComponent.attrs.image}". Maybe I'm missing
something, but it doesn't seem to be too much of a technical feat to
remove the need to type compositeComponent.attrs (a variable resolver
that searches compositeComponents.attrs, as necessary?)
It seems weird that we're taking a step backwards in this respect,
even as we move forward from Facelets tags to more feature-rich
composite components.
david
12:59 p.m.
On Wed, Apr 8, 2009 at 1:07 PM, Ken Paulsen <Ken.Paulsen(a)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.
1:23 p.m.
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.
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.
Right. For me the potential for collision between attribute names and
other named objects (eg. implicit objects, managed beans) is the more
serious issue. I prefer a solution where the composite component
attributes are partitioned off into their own name space. However, I
completely agree with David's point that "compositeComponent.attrs" is
annoyingly verbose. As I've mentioned when this has come up in the
past, my preferred solution would be to give the composite component
author the ability to define their own name/alias for
"compositeComponent.attrs" object (similar to the h:dataTable "var"
attribute). So, something like:
<composite:implementation attributesVar="a">
<h:graphicImage style="border: none" value="#{a.image}"/>
</composite:implementation>
Andy
3:13 p.m.
On Wed, Apr 8, 2009 at 2:23 PM, Andy Schwartz <andy.schwartz(a)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.
12:09 a.m.
<h:graphicImage style="border: none"
value="#{faceletsContext.image}"/>
This satisfies Ken's best practice in this use case.
this also seems reasonable to me, however, Andy's approach would make
it possible to be even more concise in the naming. Also, I would
expect the scope should rather be named something like:
#{compositeScope.image}
actually, that looks pretty likable, too.
In the end, I wouldn't worry too much about having a few (not too many
of course - the current syntax is probably hard to remember)
boilerplate characters - I would only worry about these chars if we
have to transfer all attributes of a component in the main view
definition to the composite component, and for this, I think we should
really add an <f:insertAttributes except="..."/> element at some
(later) point of time.
regards,
Martin
midnight
Hi,
As I've mentioned when this has come up in the
past, my preferred solution would be to give the composite component
author the ability to define their own name/alias for
"compositeComponent.attrs" object (similar to the h:dataTable "var"
attribute). So, something like:
<composite:implementation attributesVar="a">
<h:graphicImage style="border: none" value="#{a.image}"/>
</composite:implementation>
I second Andy's suggestion. My +1 for this approach.
regards,
Martin
9:33 a.m.
Hey Ken -
Ken Paulsen wrote On 4/13/2009 2:34 AM ET:
My 2 cents....
I'd rather see us pick a *standard value* for "a" ("ezcomp",
"compositeComponent" too long??, etc.).
I would be okay with picking a standard value, though if we do this, the
name should include something to indicate that this refers to an
attribute map and not to the component. So, "attrs" (or something like
that) - not "ezcomp" or "compositeComponent", since this should refer
to
the composite component itself.
This is less confusing. Less to worry about in the ezcomp
declaration.
Hmm... Personally I don't find the use of a "var" attribute especially
confusing, though perhaps I am not the typical user. :-) Anyone who
has used c:forEach or h:dataTable is already familiar with this
concept, so there is precedent for this approach in the platform. I
keep thinking about c:forEach and h:dataTable and wondering whether
these tags would have been better if the designers had just said:
"Forget the var and varStatus attributes - let's just spec 'item' and
'status' implicit variables." Personally I don't think this would have
been an improvement.
BTW, we've been using the "var" approach for the ADF Faces page template
component for years. I don't remember our clients ever raising this as
a point of confusion. Actually, if composite component authors do find
this confusing, they can of course always stick with good old
compositeComponent.attrs.
Page author won't have to worry about the EZComp author masking
their values.
Unless I am missing something here, the same is true if we go with a
"var" approach.
And if scoping is done correctly, this value won't exist
automatically outside the component which consumes it... so there's no
name-space collision issue here.
I don't think we have namespace collision problems if we allow the
composite component author to define their own attribute var name.
If a mapping *is* desired to make it shorter in later references, I'd
suggest solving it more generically. For example, in JSFTemplating an
event handler can set a request attribute:
<event type="beforeCreate">
setAttribute(key="a" value="#{compositeComponent.attributes}");
</event>
The above is not a proposal. I am trying to point out that there are
more generic easy solutions for this. I don't like the complexity
involved in a dynamic variable name -- it'll just confuse people.
Keep it simple.
To me the "var" approach seems much simpler than, say, requiring the
composite component author to manually move the attributes map to a
request-scoped variable. Also, a solution where we shove the attributes
map into some other scope (eg. request scope) has the downside of
raising the name collision problem again, since now we need to compete
with managed beans names that occupy that scope.
I guess the bottom line is that I can live with picking a standard name,
but the "var" approach seems more elegant to me, and not especially
confusing/complex, since this approach should already be familiar to
JSTL/JSF users. I can also live with not doing anything of course,
though it would be nice to provide a more concise syntax so that
composite component authors can tighten up their implementations.
Andy
10:43 a.m.
Hey Ken -
Ken Paulsen wrote On 4/13/2009 12:22 PM ET:
>
>> Page author won't have to worry about the EZComp author masking
>> their values.
>
> Unless I am missing something here, the same is true if we go with a
> "var" approach.
I think you mean "without" the var approach? The difference is the
page author can expect what the reserved word will be vs. every
component being different.
I am still confused about how the choice of the var name within a
composite component implementation impacts page authors. I was thinking
that the page author would not be exposed to this in any way. I would
expect that the page author wouldn't necessarily be able to distinguish
between a composite component an a plain old Java component. So, yeah,
I think I am missing something here.
>
> To me the "var" approach seems much simpler than, say, requiring the
> composite component author to manually move the attributes map to a
> request-scoped variable. Also, a solution where we shove the
> attributes map into some other scope (eg. request scope) has the
> downside of raising the name collision problem again, since now we
> need to compete with managed beans names that occupy that scope.
The above was not a suggested syntax, it's just one that works today.
If I had to pick a syntax on the fly, perhaps:
<f:alias var="foo" target="#{some.el}" />
Ah, okay - makes sense. Another naming option might be:
<f:var name="foo" target="#{some.el}">
BTW, would this tag wrap other tags/components so that the variable was
only active while descendents are being processed (like f:ajax)?
> I guess the bottom line is that I can live with picking a standard
> name, but the "var" approach seems more elegant to me, and not
> especially confusing/complex, since this approach should already be
> familiar to JSTL/JSF users. I can also live with not doing anything
> of course, though it would be nice to provide a more concise syntax
> so that composite component authors can tighten up their implementations.
I'm for it if its generalized (i.e. <f:alias /> type of solution)), I
don't see the rationale for making a special case here.
Sure, I am okay with a generalized solution as well. FWIW, I do see
benefit in providing a convenience API as well for the composite
component attributes map case, since this is going to be an amazingly
common case. If we did provide both solutions (where the
composite:implementation attribute was just shorthand for
f:alias/f:var), personally I would just use the attribute every time. :-)
Andy
2:30 p.m.
Ken Paulsen wrote On 4/15/2009 12:14 PM ET:
Page author does:
<my:echoComp value="#{foo.bar}">
Suppose in echoComp def they map "compositeComponent.attributes" to
"foo". Then if the component attempts to evaluate the #{foo.value}
property, it (correctly, I assume) resolves to #{foo.bar}. However,
if the component author then attempts to evaluate that value and
display it, manipulate it, etc.... then it will incorrectly evaluate
to (null) (there is no "bar" attribute for this component). The
managed bean "foo" gets masked.
Hmm... I always thought that the VariableMapper for a ValueExpression is
determined when the ValueExpression is created, not when when the
ValueExpression is evaluated. So, in the above example, when the
ValueExpression for "#{foo.bar}" is created, it obtains a reference to
the current VariableMapper. This VariableMapper would not include the
compositeComponent's "foo" variable since that is not yet in scope.
Even if the "#{foo.bar}" ValueExpression is later evaluated within the
context of a composite component, it still uses its original
VariableMapper, and thus is not impacted by the presence of the "foo"
variable in the VariableMapper used by the composite component.
In any case, seems like this will shortly be a moot point - I believe
that Ed will be sending out an alternate suggestion soon.
Andy
5729
days inactive
5736
days old
jsr-314-open-mirror@lists.jboss.org
13 comments
5 participants
participants (5)
-
Andy Schwartz -
Dan Allen -
David Geary -
Ken Paulsen -
Martin Marinschek