Gang -
I am reviewing the new TagDecorator javadoc, which basically specifies
the requirements for pass through elements.
Index: javax/faces/view/facelets/TagDecorator.java
===================================================================
--- javax/faces/view/facelets/TagDecorator.java (revision 8845)
+++ javax/faces/view/facelets/TagDecorator.java (revision 11719)
+ * <li><p>Let <strong>localName</strong> be the return from {_at_link
+ * Tag#getLocalName}. Use <strong>localName</strong> to identify an
+ * entry in a data structure based on the following table. Once an
+ * entry has been identified, let <strong>targetTag</strong> be the
+ * value of the "target tag" column for that entry.</p>
+ * <p>If no matching entry is found, let
+ * {_at_code jsf:element} be the value of <strong>targetTag</strong></p>
This seems backwards to me.
If jsf:element is explicitly specified, this should win over any
implicit mappings. Otherwise, there is no way to do this:
<button jsf:element="af:commandButton">
If the mappings specified in the TagDecorator javadoc take precedence
over jsf:element, the above sample which create an h:commandButton
rather than an ADF Faces commandButton, which is clearly not the intention.
Overall I think that the TagDecorator approach is very clever. (Nice
work Frank and Ed!) However, one disappointment is that we are
hardcoding mappings to h:* tags without any way to customize these
mappings. So, for example, it would be way more powerful if there was a
way to specify that <button> should map to af:commandButton or to the
Prime/Ice/RichFaces buttons, rather than require page authors to
explicitly specify a jsf:element when working with these component sets.
Perhaps this is an enhancement that we should considerin 2.3?
One other thing I am wondering about is whether page authors will hit
frustrations with conflicts between html and JSF attributes. For
example, a web designer might produce the following content:
<input type="text" value="Some dummy value"/>
The JSF developer would then come in and do:
<input type="text" value="Some dummy value" jsf:value="#{bean.value}"/>
I believe that we specified that the pass through attribute ("Some dummy
value") would win, which I still think is the right decision.
As part of our pass through element transformation process, it might be
nice to have the ability to define rules for filtering out certain
attributes. So, for example, a rule that says:
> when transforming an <input> element into an <h:inputText> element,
> supress
> the "value" attribute if "jsf:value" is present"
Would come in handy.
This would allow the page to contain html markup that helps make the
page designer friendly (for folks using HTML editors), while avoiding
conflicts with developer-specified additions.
Another enhancement for 2.3? :-)
Andy