Hi Imre,
Am 19.07.2012 um 02:00 schrieb Imre Oßwald:
> Hi Ed,
>
> sorry for the late reply.
> First: I am not sure i get:
>
> EB> We make sure to throw a FaceletException if we have an element that
> EB> has attributes namespaced with the pass through element namespace that
> EB> is not, itself valid as a pass through element.
>
> EB> I need to add tests for conflicting attributes, such as "required".
>
> So, this would not be possible <input type="text" jsf:required="true" required="required" /> ?
> If so, how would one set the html5 required-attribute?
> Especially in case of the required-attribute I do not see a problem, as jsf:required does (if it wasn't changed) take part in the rendering.
Good point. It's hard to determine which case is problematic and which not. Maybe we should allow things like jsf:required="true" required="required" and hope the developer knows what she does.
>
> Frank Caputo wrote:
>
>> Hi Ed,
>>
>> Am 11.07.2012 um 18:18 schrieb Edward Burns:
>>
>>> SECTION: API Changes
>>
>> The spec feels clear so far. But there remain some questions:
>>
>> If Html5 gets a new element (like button for example) we can't support it out of the box because we have this mapping. I would like to give the developer a simple way to extend JsfPassthroughElementLibrary. Maybe we can have something like Application.addPassthroughElement(String tagName, String componentFamily, String rendererType).
>>
>> How can we distinguish between <input type="text"> and <input type="submit"> (which have different decode behaviors), if the mapping relies only on the element name?
>
> Maybe, we should work with "callbacks". Kind of like the TagDecorators, that are part of Facelets - which are already sufficient to make this work, but are not as easy to be used, as I would like to see it for a PassthroughElements mapping.
> Still, calling a method and passing the Tag, which will return the mapping to a JSF-component is probably a solution that is flexible enough. It could for example inspect the attributes like type="text" or type="submit".
> We could then probably leave the implementation of less "complicated" solutions (like text base mappings) to 3rd-parties.
Sounds great. So if TagDecorator is sufficient, we could simply add an annotation FaceletsTagDecorator to easily add new TagDecorators. And we should have a default implementation (e.g. PassThroughElementsDecorator), which could be extended. If we do so, we should think about simplifying the use of TagAttribute(s) and give them a default implementation.
>> How do we handle select/option/optgroup (maybe http://java.net/nonav/projects/javaserverfaces-spec-public/lists/users/archive/2012-06/message/43 helps)?
>>
>> I'd like to have a wildcard mapping: For all non mapped element names, we create componentFamily javax.faces.Panel and rendererType javax.faces.passthrough.Element.
>
> +1 for wildcard mapping ( + we need to provide the original tagname )
Ciao Frank