>>>>> On Tue, 12 Mar 2013 13:29:51 -0400, Andy Schwartz <andy.schwartz_at_oracle.com> said:
AS> Gang -
AS> I am reviewing the new TagDecorator javadoc, which basically specifies
AS> the requirements for pass through elements.
[...]
AS> Overall I think that the TagDecorator approach is very clever. (Nice
AS> work Frank and Ed!) However, one disappointment is that we are
AS> hardcoding mappings to h:* tags without any way to customize these
AS> mappings. [...]
AS> Perhaps this is an enhancement that we should considerin 2.3?
>>>>> On Tue, 12 Mar 2013 14:11:54 -0400, Andy Schwartz <andy.schwartz_at_oracle.com> said:
AS> I'll need to keep reading, but very much wondering now whether there is
AS> any way to manually map a pass through element to a non-standard (eg.
AS> ADF/Prime/Ice/Rich) tag.
>>>>> On Tue, 12 Mar 2013 20:00:28 +0100, Frank Caputo <frank_at_frankcaputo.de> said:
FC> We decided to do this only for the standard h:* tags, because
FC> usually the generated markup of component libraries is more than one
FC> HTML tag for a facelets tag. So there is not really a one to one
FC> mapping. Maybe we should introduce a factory in 2.3.
Yes, we can consider that. Please log it with fixVersion 2.3.
AS> As part of our pass through element transformation process, it might be
AS> nice to have the ability to define rules for filtering out certain
AS> 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"
AS> Would come in handy.
AS> This would allow the page to contain html markup that helps make the
AS> page designer friendly (for folks using HTML editors), while avoiding
AS> conflicts with developer-specified additions.
AS> Another enhancement for 2.3? :-)
That one seems like too much flexibility.
Ed