>>>>> On Mon, 17 Sep 2012 10:23:52 +0200, Frank Caputo <frank_at_frankcaputo.de> said:
FC> Hi Experts,
FC> I have some additional information.
[... please prune appropriately before replying ...]
EB> Encode Behavior
EB> Look in the component's attribute map for an entry under the key
EB> given by the value of the constant
EB> Renderer.PASSTHROUGH_RENDERER_LOCALNAME_KEY. The value of this key
EB> is the element name to render. If the component has a manually
EB> declared, not auto-generated clientId, or if the component has
EB> behaviors attached to it, render the clientId as the value of the
EB> "id" attribute. Render the "name" attribute with the value coming
EB> from the clientId. Note that markup authors may set this value
EB> directly on the markup and the VDL processing must guarantee that
EB> the "name" attribute is set as the component's clientId. If the data
EB> structure has an entry for the localName, and the value of the
EB> renderCurrentValue is true, or the data structure has no entry for
EB> the localName, render the current value of the component as the
EB> value of the "value" attribute. Otherwise do not render the value
EB> of the component.
FC> Can we have it implement ActionSource2 to make it also act like an
FC> action component (e.g. for the button tag) and handle it differently
FC> depending on the attributes (jsf:action or jsf:value)?
Sure, we can do that. But I need to understand that you want this to
replace what you already have in the Mapper. You already have an entry
that maps "button" to "h:commandButton". Are you saying we should get
rid of that in favor of your new suggestion?
I suggest we create a new element jsf:commandElement with component-type
javax.faces.Command and renderer-type javax.faces.passthrough.Command.
I suggest that if none of the existing mappings match, we look for the
action or value attribute to determine if we should map it to
jsf:element or jsf:commandElement.
[...]
EB> Frank's code gets the elementName and stores it as a TagAttribute
EB> instance in the tag's TagAttributes impl in the passThrough
EB> attribute namespace. The HtmlResponseWriter knows to look in the
EB> passThrough attribute set for a specially named attribute called
EB> "elementName".
FC> This was a trick to get the button tag work quickly ;-) I thought
FC> passthrough attributes let us override attributes of the renderer,
FC> so why not override the element name?
FC> We can also use it for keygen, if we map it to h:inputTextarea.
I'd rather not.
[...]
FC> In the prototype the user defined tag decorators don't see any jsf:
FC> attributes. Because my tag decorator applies first, they only see
FC> the converted tags.
That's a nice benefit.
Ed
--
| edward.burns_at_oracle.com | office: +1 407 458 0017
| homepage: | http://ridingthecrest.com/