Why can't we wrap every commandLink/commandButton in its own dummy
form if it doesn't have a parent form? This would mean writing out a
lot more dummy forms, but then we wouldn't have to worry about writing
it in the endDocument() method. As for autoscroll, I'm not really
sure about the proper place for that to go, but it definitely needs to
be inside the <html /> tag and preferably inside the <body /> tag. It
seems like a bit much to parse the stream, but that might be the only
way to go.
Another option would be to have a tag that writes out the autoscroll
javascript. This would mean that people would have to put that tag on
every page they want to have the autoscrolling on (or they could just
use Tiles).
On Apr 1, 2005 2:28 AM, Manfred Geiler <[EMAIL PROTECTED]> wrote:
> Hi Adam,
> Thanks for your valuable feedback.
> see inline
>
> On Mar 29, 2005 12:54 AM, Adam Winer <[EMAIL PROTECTED]> wrote:
> > To introduce myself, name's Adam Winer: long standing member of the
> > JSF EG(actually, essentially the only member still standing from the
> > original JSF kickoff meeting), and currently the architect of Oracle's
> > ADF Faces.
> Yes, and a hard working EG member too. You are out of reach with your
> extensive and precise analyses. High time to mention that. Thanks.
>
> > I've been shown some problems lately with MyFaces 1.0.9 and ADF Faces.
> > The problems specifically trace to MyFaces's use of
> > ResponseWriter.endDocument() to output Javascript. Since ADF Faces
> > runs with its own RenderKit (and therefore its own ResponseWriter),
> > this Javascript is getting dropped and not written.
> > I'd recommend (both as JSF EG guy and ADF Faces guy) that this MyFaces
> > code be moved *out* of ResponseWriter.endDocument(). Specifically:
> > - ResponseWriter.endDocument() is not guaranteed to be called before
> > the close of <body> or even the close of <html>, and therefore this
> > script cannot be safely output at this point. It's quite likely that
> > changes in JSF 1.2 will essentially guarantee that endDocument() is
> > not called until the close of all output.
> > - This is not really the intent of ResponseWriter.endDocument(). In
> > HTML, it should be a no-op. It's there for more bizarre scenarios
> > like a ResponseWriter outputting a SOAP envelope around a response.
> You are right and I fully agree with that.
>
> > - It's breaking ADF Faces. :)
> What exactly is it, that is broken?
> MyFaces RenderKit specific features (like the autoscroll feature) will
> not work, when someone uses another RenderKit. That is expected
> behaviour and no issue, IMHO.
> Regarding the dummyForm feature. This is a RenderKit specific
> *feature* as well, BUT since I remember that I payed extra attention
> to design it alien-ResponseWriter-friendly ;-), I would like to dig
> deeper. Basic idea was to *wrap* the current ResponseWriter in a
> transparent manner whenever a component would need a parent form, but
> is not nested in one (see DummyFormResponseWriterWrapper).
> Please give me more details on your problems.
>
> > A significantly cleaner way to output needed Javascript is to add it
> > as needed from the Renderers that require it (using a request-scoped
> > attribute to track if its been added already).
> Unfortunately it's not that easy:
> We cannot output the dummyForm javascript at once, because first the
> needed dummy request parameters have to be collected. The javascript
> must be rendered at the end of the page.
> The same applies to the autoscroll feature. What, if you have a page
> without MyFaces components? Who should render the necessary script?
> IMHO, this can only be done by the ResponseWriter. And since these
> things are all custom RenderKit features, it must be done by out
> special ResponseWriter!
>
> The endDocument() method is in fact not the proper place for this kind
> of things, you are right. An alternative would be to parse the written
> stream on the fly for the </body> ot </html> String an insert the
> script output there.
> WDYT?
>
>
> > BTW, glancing through the ResponseWriter code, some ideas for other
> > improvements:
> >
> > - Refactor the ResponseWriter to use a separate instance for HTML and
> > XHTML (e.g, output <br> in HTML but <br/> in XHTML - take advantage of
> > this abstraction!)
> We do not have a XHTML-Renderkit yet, but thanks for the hint.
>
> > - The line of code that reads:
> > String strValue = value.toString(); //TODO: Use converter for value
> > .. well, no: Converters are not applicable here.
> > - Remove any code that tries to output <!-- --> around Javascript, and
> > move that functionality into ResponseWriter.startElement("script") and
> > ResponseWriter.endElement("script") so it can be globally enabled and
> > disabled if needed.
> ok, added jira issue - in your name ;-)
>
> > Thanks,
> > Adam Winer
> > [EMAIL PROTECTED]
> gmail rulez :-)
>
> Thanks Adam,
> -Manfred
>
--
-Heath Borders-Wing
[EMAIL PROTECTED]
