Roger Kitain wrote:
> Comments interspersed...
> Feedback appreciated....
>
> Craig R. McClanahan wrote:
>
>> Roger Kitain wrote:
>>
>>>
>>> So, somewhere we need to keep track of what's been rendered.. This
>>> isn't in the
>>> spec, but, can the FormRenderer take on that responsiblity?
>>
>>
>>
>> Not without creating a dependency between the two renderers.
>>
>>> The FormRenderer would need to only render a *one* hidden field
>>> pertaining to its commandLink children...
>>> So, commandLinkRenderer would just simply do it's rendering.... You
>>> would need
>>> to implement *some* logic in your struts-faces form renderer to meet
>>> this requirement...
>>>
>> And ***that*** is precisely the problem. If the specification
>> described exactly what attribute you were using to store the map, and
>> exactly what to do with it, everything would be fine -- I could just
>> implement the required behavior. Without that, the only way to know
>> what to do is spelunk the RI's source code -- and even that won't
>> help me support any other implementation's version of FormRenderer,
>> because there is no guarantee they will use the same generic
>> attribute in the same way.
>>
>>> Comments?
>>>
>> It would seem there needs to be a way for CommandLinkRenderer
>> *itself* to both keep track of what has been generated and do it's
>> own generating if need be, so that it is self contained. Relying on
>> FormRenderer to do it (without a spec change to define the semantics
>> more precisely) cannot be portable.
>
>
> I thought of the idea of having CommandLinkRenderer render it's
> associated hidden field for the current form - but only do it once
> per form (it would know this via a stored
> map of already rendered hidden fields - stored as a form component
> attr)..
> However....
> Then FormRenderer would not be rendering these hidden fields - which
> is in
> violation of the spec.... And... it's also *not* spec'd that
> CommandLinkRenderer
> should render the hidden field....
> The only other thought that comes to mind at the moment is to have
> FormRenderer
> use some logic (without relying on anything from CommandLinkRenderer)
> to render only one hidden field per form (for one or more commandLink
> children)...
> This logic would be self contained in FormRenderer... The spec says
> to only
> render *one* hidden field per page - it would be up to other FormRenderer
> implementations to devise their own workable scheme...
>
> From the spec (FormRenderer):
> /Render all the necessary hidden fields for all commandLink instances
> in the page just before the close of the "form" element.\
> /From the spec (CommandLinkRenderer):
> /Allow the form renderer to output a single "input" element (for the
> entire page,
> regardless of how many command link components are in the page) of
> "type" "hidden" whose "name" is the value of hiddenFieldName, and
> which must not have a "value" attribute. Multiple occurrences of
> command link components in the tree should not cause multiple
> hiddenFieldName hidden fields. Allow the form renderer to output
> an "input" element of "type" "hidden" for each of the nested
> UIParameter children, taking the name property (but not the value)
> from each one in turn./
>
>
>
In other words, the spec *requires* a mutual dependence, without
specifying a portable mechanism for how "allow" is supposed to work?
Yuck -- that is badly broken.
It sounds like the only alternative I have (in the absence of a spec
errata) is to completely re-implement what CommandLinkRenderer does, and
tell people not to use the standard <h:commandLink> tag inside a Struts
form.
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_javaserverfaces.dev.java.net
For additional commands, e-mail: dev-help_at_javaserverfaces.dev.java.net