Hi Frank
2013/1/31 Frank Caputo <frank_at_frankcaputo.de>:
> Hi Leonardo,
>
> Am 31.01.2013 um 02:00 schrieb Leonardo Uribe <lu4242_at_gmail.com>:
>
>> 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="…">
>
> +1
>
>>
>> Since h:commandLink and h:commandButton does not have outcome property, there
>> is no problem and it help simplify code writing.
>>
>> 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.
>
> type becomes a passthrough attribute. So it supersedes the type attribute written by the original renderer.
>
Ok, now I get it. I was thinking on the opposite, but now it has more
sense. Thanks
for the clarification.
There are some additional inconsistencies in the renderkit javadoc of
component-family: javax.faces.Panel renderer-type:
javax.faces.passthrough.Element :
- At start it says something like this:
"... This renderer is intended to be used with an arbitrary markup
element that has
no decoding. ..."
But later says this:
"... If the component has a manually declared, not auto-generated
clientId, or if the
component has behaviors attached to it, render the clientId as the
value of the "id"
attribute. ..."
In few words, first it suggest that it has no decoding, but later it
says that the
component has behaviors (or client behaviors) attached to it. By definition,
client behaviors has decode behavior, so the first line is incorrect.
How to identify if a property has a related client behavior? In theory
we can define an
specific set of properties (onclick, onmousedown, ....) that are
related to the renderkit,
and maybe that will work for the current spec, but the question that
still is on the air
is if we need a more general way to define such kind of contracts
(ActionSource2,
value change, client behaviors ...). I have a component and I want
that the component
implements ActionSource2 contract, but in a dynamic way, without the
need to write
a component class.
The documentation also says this:
"... This renderer is not responsible for rendering its children. ..."
But I suppose it should be responsible for rendering its children, in
the same way
h:panelGroup or h:panelGrid does (set getRendersChildren() to true and override
encodeEnd()).
regards,
Leonardo Uribe
> Ciao Frank
>
>>
>> I'll keep trying to find issues in the spec.
>>
>> regards
>>
>> Leonardo Uribe
>>
>
>