[jsr-314-open-mirror] [jsr-314-open] composite:attribute "targets" property does not match with ViewDeclarationLanguage.retargetMethodExpressions
Leonardo Uribe
lu4242 at gmail.com
Mon Oct 18 21:36:06 EDT 2010
Hi
Some days ago, it was mentioned on myfaces dev list that "targets"
attribute does not seem to work as expected. After review the available
documentation and doing some test, my conclusion was the spec is good,
but this part needs a little bit more documentation (and fix some
bugs), because there are use cases that are causing problems to users.
Some of these problems has been already mentioned (spec issue 755) but
my intention here is do a full and detailed analysis.
The property "targets" is used for these tags:
composite:actionSource
composite:editableValueHolder
composite:valueHolder
composite:clientBehavior
composite:attribute
For the first four cases, this property is used by :
ViewDeclarationLanguage.retargetAttachedObjects(FacesContext context,
UIComponent topLevelComponent,
List<AttachedObjectHandler> handlers)
In JSF 2.0 rev A it was made explicit the need to handle nested
composite component with this lines:
"... The implementation must support retargeting attached objects from
the top level compsite component to targets that are composite and
non-composite components ...."
This is ok ;-).
The problem is the description about how composite:attribute "targets"
property works does not match with the algorithm for:
ViewDeclarationLanguage.retargetMethodExpressions(FacesContext context,
UIComponent topLevelComponent)
Here is the documentation about composite:attribute "targets":
"... If this element has a method-signature attribute,
the value of the targets attribute must be interpreted as a space
(not tab) separated list of client ids (relative to the top level
component) of components within the <composite:implementation> section.
Space is used as the delimiter for compatibility with the IDREFS and
NMTOKENS data types from the XML Schema.
Each entry in the list must be interpreted as the id of an inner
component to which the MethodExpression from the composite component
tag in the using page must be applied.
If this element has a method-signature attribute, but no targets
attribute, the value of the name attribute is used as the single entry
in the list.
If the value of the name attribute is not one of the special values
listed in the description of the name attribute, targets (or its
derived value) need not correspond to the id of an inner component ...".
At this point everything seems to be ok. But look this documentation
(I'll put the important points):
".....
# Get the value of the targets attribute. If the value is a ValueExpression
evaluate it. If there is no targets attribute, let the name of the
metadata element be the evaluated value of the targets attribute.
# Interpret targets as a space (not tab) separated list of ids. For each
entry
in the list:
......
# If name is equal to the string "action" without the quotes, call
ActionSource2.setActionExpression(javax.el.MethodExpression) on
target,
passing attributeMethodExpression.
# If name is equal to the string "actionListener" without the quotes,
call
ActionSource.addActionListener(javax.faces.event.ActionListener) on
target,
passing attributeMethodExpression wrapped in a
MethodExpressionActionListener.
# If name is equal to the string "validator" without the quotes, call
EditableValueHolder.addValidator(javax.faces.validator.Validator) on
target,
passing attributeMethodExpression wrapped in a
MethodExpressionValidator.
# If name is equal to the string "valueChangeListener" without the
quotes, call
EditableValueHolder.addValueChangeListener(javax.faces.event.ValueChangeListener)
on target, passing attributeMethodExpression wrapped in a
MethodExpressionValueChangeListener.
# Otherwise, assume that the MethodExpression should be placed in the
components attribute set. The runtme must create the MethodExpression
instance based on the value of the "method-signature" attribute.
....."
My first interpretation of this javadoc was that "targets" only has sense
for "action",
"actionListener", "validator" and "valueChangeListener". But note if that's
true,
someone could expect something like the description on
retargetAttachedObjects, right?
The current behavior (Mojarra 2.0.3 and Myfaces 2.0.2) is the same, if we
have two
nested composite components, that will throw a ClassCastException. There is
a issue already
open for this one:
https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=755
There are two possible alternatives here:
1. Implement the algorithm proposed for retargetMethodExpressions and
ignore
composite:attribute "targets" property says.
2. Implement the expected behavior of composite:attribute "targets"
property and make
some changes to retargetMethodExpressions algorithm.
The intention is take option 2 and include it for JSF 2.0, because in theory
should be
handled as an implementation detail of the algorithm (anyway it could be
good to update
the documentation with the same advice used for retargetAttachedObjects).
For "action", "actionListener", "validator" and "valueChangeListener" it is
clear that
the action to take is something like this:
- If target is a composite component and that one "retarget" to other
components and
additionally does not implements [ActionSource2/EditableValueHolder],
call:
targetComponent.getAttributes().put(attributeName,
attributeNameValueExpression);
and call retargetMethodExpressions recursively. Take care of apply the
method twice
and if the property pointed by "attributeName" was already set, revert
its effects.
The tricky part is how to handle generic method expression properties. The
javadoc says:
"....
# Otherwise, assume that the MethodExpression should be placed in the
components attribute set. The runtme must create the MethodExpression
instance based on the value of the "method-signature" attribute.
....."
But I have identified three valid cases:
1. testSimpleAttributeMethodExpressionEmpty.xhtml (Using an EL #{cc}
reference)
<testComposite:simpleAttributeMethodExpressionEmpty id="cc1"
customMethod="#{methodExpressionBean.doSomethingFunny}">
</testComposite:simpleAttributeMethodExpressionEmpty>
simpleAttributeMethodExpressionEmpty.xhtml
<composite:interface>
<composite:attribute
name="customMethod"
method-signature="String doSomething(String)"/>
</composite:interface>
<composite:implementation>
<tc:testComponent id="testComponent"
customMethod="#{cc.attrs.customMethod}"/>
</composite:implementation>
2. testSimpleAttributeMethodExpressionTarget.xhtml (Using "targets" to call
a property setter directly)
<testComposite:simpleAttributeMethodExpressionTarget id="cc1"
customMethod="#{methodExpressionBean.doSomethingFunny}">
</testComposite:simpleAttributeMethodExpressionTarget>
simpleAttributeMethodExpressionTarget.xhtml
<composite:interface>
<composite:attribute
name="customMethod"
method-signature="String doSomething(String)"
targets="testComponent"/>
</composite:interface>
<composite:implementation>
<tc:testComponent id="testComponent"/>
</composite:implementation>
3. testCompositeAttributeMethodExpressionTarget.xhtml (Using "targets",
but the target component is a composite one)
<testComposite:compositeAttributeMethodExpressionTarget id="cc1"
customMethod="#{methodExpressionBean.doSomethingFunny}">
</testComposite:compositeAttributeMethodExpressionTarget>
compositeAttributeMethodExpressionTarget.xhtml
<composite:interface>
<composite:attribute
name="customMethod"
method-signature="String doSomething(String)"
targets="simpleAttributeMethodExpressionTarget"/>
</composite:interface>
<composite:implementation>
<testComposite:simpleAttributeMethodExpressionTarget
id="simpleAttributeMethodExpressionTarget"/>
</composite:implementation>
simpleAttributeMethodExpressionTarget.xhtml (could be like in 1 or 2)
The case (1) actually works but the case (2) and (3) does not work on both
MyFaces 2.0.2 and Mojarra 2.0.3 .
I have created an issue on MyFaces here:
https://issues.apache.org/jira/browse/MYFACES-2946
a attached a working patch too if you want to take a look at it:
https://issues.apache.org/jira/secure/attachment/12457512/MYFACES-2946-1.patch
Suggestions are welcome
regards,
Leonardo Uribe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jsr-314-open-mirror/attachments/20101018/b05e0499/attachment-0002.html
More information about the jsr-314-open-mirror
mailing list