jsr344-experts@javaserverfaces-spec-public.java.net

[jsr344-experts] Re: [jsr344-experts mirror] Re: [1111-PassThruElements] First commit complete

From: Imre Oßwald <ioss_at_pmx.jevelopers.com>
Date: Thu, 19 Jul 2012 02:00:28 +0200

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.


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.


> 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 )


Imre