Hi<br><br><div class="gmail_quote">2010/10/26 Martin Marinschek <span dir="ltr"><<a href="mailto:mmarinschek@apache.org">mmarinschek@apache.org</a>></span><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">
> G> Martin, I like your proposal on deprecating "targets". But how would<br>
> G> you then handle this case: Using a cc I nest <f:actionListener<br>
> G> "for=a" ... /> and inside the cc there is a <cc:actionSource name="a"<br>
> G> targets="b, c" /> where b and c are buttons? The logic of the "for"<br>
> G> attributes only includes this: "If present, this attribute refers to<br>
> G> the value of *one* of the exposed attached objects within the<br>
> G> composite component inside of which this tag is nested." IMO<br>
> G> deprecating "targets" would require opening "for" to refer to<br>
> G> *multiple* exposed attached objects within the composite component<br>
> G> inside of which this tag is nested just the way targets is doing this<br>
> G> right now. "targets" kind of bundles them right now.<br>
><br>
> Yes, exactly. There was a lot of back and forth between David Geary,<br>
> Ken Paulsen, Kito Mann, Andy Schwartz, and myself on this.<br>
<br>
</div><br>I don't understand why this is necessary. Multiple component within<br>
the composite could always use the same expression that is available<br>
in cc.attrs?<br>
<div class="im"><br></div></blockquote><div><br>In theory, it is possible (and very easy) to put the method expression on <br>the composite component attribute map for action, actionListener, <br>validator, valueChangeListener and methodExpression attributes. But <br>
things are different for other cases where "targets" attribute is used <br>(cc:actionSource, cc:valueHolder, cc:editableValueHolder, <br>cc:clientBehavior), because "for" attribute is used to find the cc:attribute <br>
declaration and then use "targets" attribute to attach correctly the objects.<br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">
> G> To make this more convenient omitting "for" could simply be a synonym<br>
> G> representing a "for" for *all* nested actionSources, actionSource2s<br>
> G> and CCs.<br>
><br>
> I prefer to be explicit here.<br>
<br>
</div>+1!<br>
<div><div></div><div class="h5"><br>
> G> Please follow Jakob's proposal on adding action, actionListener,<br>
> G> valueChangeListener and validator the attributes map<br>
> G> (#{cc.attrs.action}, #{cc.attrs.actionListener},<br>
> G> #{cc.attrs.valueChangeListener}, #{cc.attrs.validator}). This is what<br>
> G> a developer would expect to happen (at least I did so) and one could<br>
> G> easily pass them on to nested components.<br>
><br>
> JK> I think we should do this a little differently:<br>
><br>
> JK> 1) try to add the e.g. ActionListener to the component specified in<br>
> JK> the targets attribute, if possible. If it is not possible, log a<br>
> JK> warning.<br>
><br>
> JK> 2) also expose the "well-known" attributes ("action",<br>
> JK> "actionListener", ...) on the composite component attribute map, this<br>
> JK> means being able to access the action attribute via #{cc.attrs.action}<br>
> JK> (currently not possible, because those attributes are not put on the<br>
> JK> attribute map).<br>
><br>
> JK> Thus the user can use the targets attribute if he/she wants to (and of<br>
> JK> course, if it is possible) and also use #{cc.attrs.action} to refer to<br>
> JK> the action attribute (like to any other attribute).<br>
><br>
> JK> Frankly I really don't understand why this was separated in the first<br>
> JK> place. Of course, the targets attribute is neat, but IMHO it is also<br>
> JK> kinda confusing. I find it a lot easier to access _every_ attribute<br>
> JK> (regardless if well-known or custom) via #{cc.attrs.attributeName}.<br>
> JK> Furthermore using this approach you can support nesting normal<br>
> JK> components and also nesting composite components.<br>
><br>
> JK> In addition the targets attribute can't solve a scenario in which the<br>
> JK> action attribute of the inner component is required (most likely the<br>
> JK> attribute from a composite component), because you need to enter a<br>
> JK> value for the attribute, but you currently can't use<br>
> JK> #{cc.attrs.action}, because this one points "nowhere".<br>
><br>
> I'd like to see a prototype of this. Can anyone step up?<br>
<br>
</div></div>@Leonardo: do you have some time to invest in this? Make it so that<br>
the targets attribute works better, but also make it such that the<br>
whole thing can be used without the targets attribute.<br>
<br></blockquote><div><br>Yes, sure!. I'll create a patch for Mojarra. <br><br>best regards <br></div></div><br>Leonardo Uribe<br>