users@javaserverfaces-spec-public.java.net

[jsr344-experts mirror] [jsr344-experts] Re: PRD Review and pending issues ( HTML passthrough TagDecorator )

From: Michael Müller <michael.mueller_at_mueller-bruehl.de>
Date: Thu, 31 Jan 2013 23:33:08 +0100

Am 31.01.2013 02:00, schrieb Leonardo Uribe:
> Hi
>
> Checking the spec of TagDecorator, I notice that it could be a good idea allow
> the following syntax:
>
> <a jsf:outcome="..."> --> <h:link outcome="...">
>
> <button jsf:outcome="..." --> <h:button outcome="...">
>
> Since h:commandLink and h:commandButton does not have outcome property, there
> is no problem and it help simplify code writing.

Really need outcome?
I guess, it can be mapped by TagDecorator this way too:

<a jsf:id="..." href="..."> --> <h:link outcome="..." id="...">


But additional attributes may answer my former question:

> But what happens, if a new element is invented for HTML5?
> <newElement jsf:id="myId"...>
> Because of jsf:id it will be added to the tree.
> Again my questions: Can we add an action to it? Or a value? Or whatever?

<newElement jsf:input ...>
might add as PT to the tree, and internally handle as an input element,
even though there is no mapping in TagDecorator

<newElement jsf:output ...>
treat PT as output

<newElement jsf:action="..." ...>
add action to PT

I'm not an implementor, these are just some raw ideas.
>
> As another comment, according to the spec:
>
> <input type="email" ...>
>
> becomes:
>
> <h:inputText ...>
>
> but since the inputText Renderer doesn't know type property
> it renders this:
>
> <input type="text" ...
>
> The RenderKit javadoc of javax.faces.Input/javax.faces.Text must be changed
> to reflect that use case, and probably
> javax.faces.component.html.HtmlInputText must be changed too.
>
> I'll keep trying to find issues in the spec.
>
> regards
>
> Leonardo Uribe
>
Michael