[jsr-314-open-mirror] [jsr-314-open] [755-cc:attributesSpecialKeys] (was: Re: composite:attribute "targets" property does not match with ViewDeclarationLanguage.retargetMethodExpressions)

[Ed Burns]

https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=755

For the record, this will not make it into JSF 2.1.  Not becasue there
was feedback on it after the deadline, but because we didn't have it on
the 2.1 list to begin with.

On Friday 22 October at 18:33 EDT, Martin Marinschek wrote:

MM> Hi guys,

MM> my strong believe is that the target attribute should be immediately
MM> deprecated.

MM> It is wrongly placed where it is right now - an interface definition
MM> should never provide hooks into the implementation. It should only
MM> provide a meaningful context to which the implementation can refer.

The targets attribute is central to the entire concept of composite
components.  I assert that it does not constitute a violation of the
abstraction because the targets attribute is not intended for
consumption by the page author.  In fact, it is an implementation detail
that happens to reside within the <cc:interface> section.

MM> I am sorry I haven't voiced this objection before - but at the time
MM> this was discussed I was not very active on the EG, and then it was
MM> too late to talk about this.

Yes, I'll say!  I recall that we talked about this in December 2007.  I
know because we had the EG meeting while I was in the hotel at
JavaPolis and I remember such a unique venue.

>>>>> On Tue, 19 Oct 2010 14:30:17 -0500, Leonardo Uribe <lu4242 at gmail.com> said:

LU> I like the way it works now. For example, tomahawk t:inputHtml
LU> component was rewritten into a composite component, and it is a good
LU> example about when it could be useful that the only requerimiento
LU> for a component to be composite is implement NamingContainer:

For what it's worth, Leonardo is happy with this way it works, provided
we address his other issues.

On Sat Oct 23 03:46:13 EDT 2010 Ganesh wrote:

G> Martin, I like your proposal on deprecating "targets". But how would
G> you then handle this case: Using a cc I nest <f:actionListener
G> "for=a" ... /> and inside the cc there is a <cc:actionSource name="a"
G> targets="b, c" /> where b and c are buttons? The logic of the "for"
G> attributes only includes this: "If present, this attribute refers to
G> the value of *one* of the exposed attached objects within the
G> composite component inside of which this tag is nested." IMO
G> deprecating "targets" would require opening "for" to refer to
G> *multiple* exposed attached objects within the composite component
G> inside of which this tag is nested just the way targets is doing this
G> right now. "targets" kind of bundles them right now.

Yes, exactly.  There was a lot of back and forth between David Geary,
Ken Paulsen, Kito Mann, Andy Schwartz, and myself on this.  

G> To make this more convenient omitting "for" could simply be a synonym
G> representing a "for" for *all* nested actionSources, actionSource2s
G> and CCs.

I prefer to be explicit here.

G> Please follow Jakob's proposal on adding action, actionListener,
G> valueChangeListener and validator the attributes map
G> (#{cc.attrs.action}, #{cc.attrs.actionListener},
G> #{cc.attrs.valueChangeListener}, #{cc.attrs.validator}). This is what
G> a developer would expect to happen (at least I did so) and one could
G> easily pass them on to nested components.

JK> I think we should do this a little differently:

JK> 1) try to add the e.g. ActionListener to the component specified in
JK> the targets attribute, if possible. If it is not possible, log a
JK> warning.

JK> 2) also expose the "well-known" attributes ("action",
JK> "actionListener", ...) on the composite component attribute map, this
JK> means being able to access the action attribute via #{cc.attrs.action}
JK> (currently not possible, because those attributes are not put on the
JK> attribute map).

JK> Thus the user can use the targets attribute if he/she wants to (and of
JK> course, if it is possible) and also use #{cc.attrs.action} to refer to
JK> the action attribute (like to any other attribute).

JK> Frankly I really don't understand why this was separated in the first
JK> place. Of course, the targets attribute is neat, but IMHO it is also
JK> kinda confusing. I find it a lot easier to access _every_ attribute
JK> (regardless if well-known or custom) via #{cc.attrs.attributeName}.
JK> Furthermore using this approach you can support nesting normal
JK> components and also nesting composite components.

JK> In addition the targets attribute can't solve a scenario in which the
JK> action attribute of the inner component is required (most likely the
JK> attribute from a composite component), because you need to enter a
JK> value for the attribute, but you currently can't use
JK> #{cc.attrs.action}, because this one points "nowhere".

I'd like to see a prototype of this.  Can anyone step up?

Ed
-- 
| edward.burns at oracle.com | office: +1 407 458 0017
| homepage:               | http://ridingthecrest.com/
| 12 work days until German Oracle User's Group Conference