Hi
2013/1/31 Michael Müller <michael.mueller_at_mueller-bruehl.de>:
> 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="...">
>
In theory "outcome" is different from "href", because href points to
a very specific resource, but outcome refers to a page, and this value
is passed to NavigationHandler to derive the final href. Note that
h:link does not have "href" property defined.
>
> 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.
>
In the proposed spec there is a <jsf:element elementName="..."> tag that do
the trick. You can set passthrough values but not action-actionListener or
value-valueChangeListener.
regards,
Leonardo Uribe
>>
>> 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