2010/10/26 Martin Marinschek
<mmarinschek@apache.org>
> 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.
I don't understand why this is necessary. Multiple component within
the composite could always use the same expression that is available
in cc.attrs?
In theory, it is possible (and very easy) to put the method expression on
the composite component attribute map for action, actionListener,
validator, valueChangeListener and methodExpression attributes. But
things are different for other cases where "targets" attribute is used
(cc:actionSource, cc:valueHolder, cc:editableValueHolder,
cc:clientBehavior), because "for" attribute is used to find the cc:attribute
declaration and then use "targets" attribute to attach correctly the objects.
> 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.
+1!
> 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?
the targets attribute works better, but also make it such that the
whole thing can be used without the targets attribute.
Yes, sure!. I'll create a patch for Mojarra.
best regards