>>>>> On Thu, 31 Jan 2013 23:33:08 +0100, Michael Müller <michael.mueller_at_mueller-bruehl.de> said:
MM> 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.
MM> Really need outcome?
MM> I guess, it can be mapped by TagDecorator this way too:
MM> <a jsf:id="..." href="..."> --> <h:link outcome="..." id="...">
>>>>> On Thu, 31 Jan 2013 18:44:16 -0500, Leonardo Uribe <lu4242_at_gmail.com> said:
LU> In theory "outcome" is different from "href", because href points to
LU> a very specific resource, but outcome refers to a page, and this value
LU> is passed to NavigationHandler to derive the final href. Note that
LU> h:link does not have "href" property defined.
Not just that, but also, it simply not work because the <h:link>
renderer must use the href attribute to get its job done, but if it is
specified in the Facelet page, then the value from the facelet page will
take priority.
MM> But additional attributes may answer my former question:
MM> But what happens, if a new element is invented for HTML5?
MM> <newElement jsf:id="myId"...> Because of jsf:id it will be added to
MM> the tree. Again my questions: Can we add an action to it? Or a
MM> value? Or whatever?
MM> <newElement jsf:input ...>
MM> might add as PT to the tree, and internally handle as an input element,
MM> even though there is no mapping in TagDecorator
TagDecorator says, "if no matching entry is found, let jsf:element be
the value of targetTag. Looking at the VDLDoc for jsf:element, you can
see what that means. It's a javax.faces.Panel
javax.faces.passthrough.Element.
Obviously this does not help if the element is semantically an
javax.faces.component.ActionSource2, for example. This is where the
existing ViewHandler.FACELETS_DECORATORS_PARAM_NAME comes in. If you
provide one of those, you can give a TagDecorator impl that will first
get a chance to handle the tag.
MM> I'm not an implementor, these are just some raw ideas.
MM>
MM> As another comment, according to the spec:
MM>
MM> <input type="email" ...>
MM>
MM> becomes:
MM>
MM> <h:inputText ...>
MM>
MM> but since the inputText Renderer doesn't know type property
MM> it renders this:
MM>
MM> <input type="text" ...
MM>
MM> The RenderKit javadoc of javax.faces.Input/javax.faces.Text must be changed
MM> to reflect that use case, and probably
MM> javax.faces.component.html.HtmlInputText must be changed too.
You would think so, but the example app we have does indeed let the
type="email" pass through. This is because attributes specified in the
markup are given priority to those the renderer would have liked to have
generated.
The spec text that covers this is in the standard renderkit
overview. The section is "rendering pass through attributes".
I will add a pointer to this text to the non-normative overview in
section (10.1.4.1).
Ed
--
| edward.burns_at_oracle.com | office: +1 407 458 0017
| homepage: | http://ridingthecrest.com/