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./
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_javaserverfaces.dev.java.net
For additional commands, e-mail: dev-help_at_javaserverfaces.dev.java.net