I just realized that I completely misunderstood this:
> + * <p>If no matching entry is found, let
> + * {_at_code jsf:element} be the value of <strong>targetTag</strong></p>
The "jsf:element" bit doesn't refer to an attribute like:
> <button jsf:element="af:commandButton">
But the tag name, eg:
<jsf:element id="foo"/>
Hrm.
I'll need to keep reading, but very much wondering now whether there is
any way to manually map a pass through element to a non-standard (eg.
ADF/Prime/Ice/Rich) tag.
Andy
On 3/12/13 1:29 PM, Andy Schwartz wrote:
> 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
>
>