Roger Kitain wrote:
> Craig R. McClanahan wrote:
>
>> 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
>>
> From the CommandLinkRenderer spec:
> /Allow the form renderer to output a single "input" element (for the
> entire page, ...
> /I'm not sure what the word "Allow" means here - does it really imply
> a dependency on Form Renderer?
>
> Can't we just implement an isolated scheme in FormRenderer that does what
> the spec says - to render *one* hidden field per form (for one or more
> command
> link children)? Thinking out loud here.... Couldn't FormRenderer
> determine this
>
> from the commandLink children in the tree?
Remember what *my* problem is ... I want *your* CommandLinkRenderer to
work inside *my* FormRenderer. Without a spec requirement that tells me
*how* to do the "allow" thing, there is no way for *my* FormRenderer to
know what to do in a manner that will also work with MyFaces (just as an
example), or any other JSF implementation that does not use the RI's code.
Where in the spec does it tell the person implementing a renderer for
UIForm what attribute to look at, or what to do with it? The "allow"
language is not specific enough.
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_javaserverfaces.dev.java.net
For additional commands, e-mail: dev-help_at_javaserverfaces.dev.java.net