[jsr-314-open-mirror] [jsr-314-open] composite:attribute "targets" property does not match with ViewDeclarationLanguage.retargetMethodExpressions

Fri Oct 22 06:33:57 EDT 2010

Hi guys,

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

It is wrongly placed where it is right now - an interface definition
should never provide hooks into the implementation. It should only
provide a meaningful context to which the implementation can refer.
Someone from the outside wants to pass stuff to someone else, the
interface defines what name this stuff receives. I have not seen
something like the target attribute anywhere else in any interface
definition language - but maybe this is just my lack of experience.

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

best regards,

Martin

On 10/22/10, Jakob Korherr <jakob.korherr at gmail.com> wrote:
> Hi,
>
> I think we should do this a little differently:
>
> 1) try to add the e.g. ActionListener to the component specified in
> the targets attribute, if possible. If it is not possible, log a
> warning.
>
> 2) also expose the "well-known" attributes ("action",
> "actionListener", ...) on the composite component attribute map, this
> means being able to access the action attribute via #{cc.attrs.action}
> (currently not possible, because those attributes are not put on the
> attribute map).
>
> Thus the user can use the targets attribute if he/she wants to (and of
> course, if it is possible) and also use #{cc.attrs.action} to refer to
> the action attribute (like to any other attribute).
>
> Frankly I really don't understand why this was separated in the first
> place. Of course, the targets attribute is neat, but IMHO it is also
> kinda confusing. I find it a lot easier to access _every_ attribute
> (regardless if well-known or custom) via #{cc.attrs.attributeName}.
> Furthermore using this approach you can support nesting normal
> components and also nesting composite components.
>
> In addition the targets attribute can't solve a scenario in which the
> action attribute of the inner component is required (most likely the
> attribute from a composite component), because you need to enter a
> value for the attribute, but you currently can't use
> #{cc.attrs.action}, because this one points "nowhere".
>
> Regards,
> Jakob
>
> 2010/10/19 Leonardo Uribe <lu4242 at gmail.com>:
>> Hi
>>
>> 2010/10/19 Ed Burns <edward.burns at oracle.com>
>>>
>>> >>>>> On Mon, 18 Oct 2010 20:36:06 -0500, Leonardo Uribe
>>> >>>>> <lu4242 at gmail.com> said:
>>>
>>> [...]
>>>
>>> LU> There are two possible alternatives here:
>>>
>>> LU>  1. Implement the algorithm proposed for retargetMethodExpressions
>>> LU> and ignore composite:attribute "targets" property says.
>>>
>>> LU>  2. Implement the expected behavior of composite:attribute "targets"
>>> LU> property and make some changes to retargetMethodExpressions
>>> LU> algorithm.
>>>
>>> LU> The intention is take option 2 and include it for JSF 2.0, because
>>> LU> in theory should be handled as an implementation detail of the
>>> LU> algorithm (anyway it could be good to update the documentation with
>>> LU> the same advice used for retargetAttachedObjects).
>>>
>>> Certainly you have identified a valid issue.  The root problem is that
>>> the top level component needs to have a Java programming way to expose
>>> its composite-ness.
>>>
>>> LU> For "action", "actionListener", "validator" and
>>> LU> "valueChangeListener" it is clear that the action to take is
>>> LU> something like this:
>>>
>>> LU>  - If target is a composite component and that one "retarget" to
>>> LU> other components and additionally does not implements
>>> LU> [ActionSource2/EditableValueHolder], call:
>>>
>>> LU>    targetComponent.getAttributes().put(attributeName,
>>> LU> attributeNameValueExpression);
>>>
>>> LU>    and call retargetMethodExpressions recursively. Take care of
>>> LU> apply the method twice and if the property pointed by
>>> LU> "attributeName" was already set, revert its effects.
>>>
>>> The solution you propose will work, but it feels a bit too
>>> implementation-ish.  Right now we declare that every compositeComponent
>>> must be a NamingContainer.  Perhaps it's time to define a new abstract
>>> sub-class of NamingContainer that is a union of all the behavioral
>>> interfaces?
>>>
>>> public abstract class javax.faces.component.CompositeComponent
>>> implements NamingContainer, ActionSource2, EditableValueHolder {
>>>  public abstract void acceptRetargetedMethodExpressions(BeanInfo
>>>    ccMetadata);
>>> }
>>>
>>
>> I like the way it works now. For example, tomahawk t:inputHtml component
>> was
>> rewritten into a composite component, and it is a good example about when
>> it
>> could
>> be useful that the only requerimiento for a component to be composite is
>> implement
>> NamingContainer:
>>
>> <composite:interface componentType="org.apache.myfaces.InputHtml">
>>
>> public class InputHtml extends HtmlInputText implements NamingContainer,
>> UniqueIdVendor {
>>
>> In my understanding, if a composite component base class implements a
>> behavioral interface,
>> (ActionSource2, EditableValueHolder, ...), "targets" behavior must not be
>> allowed, because
>> the code handling that will be on the base class. In the example shown
>> InputHtml extends
>> from HtmlInputText, so it implements EditableValueHolder.
>>
>> To decide when "targets" behavior applies I have something like this:
>>
>> if (isCompositeComponentRetarget(context, innerComponent, attributeName)
>> &&
>> !(innerComponent instanceof ActionSource2))
>> {
>>    //cc retarget
>> }
>> else
>> {
>>   //process on innerComponent
>> }
>>
>> isCompositeComponentRetarget do two things:
>>
>> - Check if the component is a composite one.
>> - Check if the attribute was defined looking on the BeanInfo.
>>
>> Leonardo
>>
>>> LU> The tricky part is how to handle generic method expression
>>> LU> properties. The javadoc says:
>>>
>>> We could specify whatever we needed in that
>>> acceptRetargetedMethodExpressions() method.
>>>
>>> Ed
>>>
>>> --
>>> | edward.burns at oracle.com | office: +1 407 458 0017
>>> | homepage:               | http://ridingthecrest.com/
>>> | 16 work days until German Oracle User's Group Conference
>>
>>
>
>
>
> --
> Jakob Korherr
>
> blog: http://www.jakobk.com
> twitter: http://twitter.com/jakobkorherr
> work: http://www.irian.at
>

-- 

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces