On Apr 1, 2005 12:28 AM, Manfred Geiler <[EMAIL PROTECTED]> wrote: > > On Mar 29, 2005 12:54 AM, Adam Winer <[EMAIL PROTECTED]> wrote: > > 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.
It's a bit more complicated than that. We create our own RenderKit, but we aggregate in the BASIC_HTML (or is that HTML_BASIC, can never remember) render kit - in other words, that we take all of our renderers, and then also support everything in the default RenderKit. We do this for a collection of reasons; most specifically, while we can support a large majority of renderers without problem, we do need to replace <h:commandLink> and <h:form> (the latter to enable client-side validation). But if we didn't support the renderers in the basic HTML RenderKit, no third party components would function at all. So, this leads to the problem: it's our RenderKit, hence our ResponseWriter, but your Renderers. I agree that this is outside of the area covered by normal spec behavior, but that's frankly because the spec is crud when it comes to combining component libraries, and we need to improvise today. If there's no solution, then ah well, but I think we can find solutions without too much trouble. > 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. Dummy forms are frankly a tricky thing; I could live without support for dummy forms in this scenario (though Heath's suggestion is worth following up). It's the autoscroll, etc., that I find important, because the only user workaround is manually copying MyFaces-specific Javascript into the page (whereas for dummy forms, they can just put 'em in an <h:form> like everyone else). > > 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. DummyForm, I can imagine, though you might use something like the IBM "script collector" concept. Ugly, but practical. > The same applies to the autoscroll feature. What, if you have a page > without MyFaces components? Who should render the necessary script? The Renderer for the component(s). ADF Faces does this all over the place; a renderer says "hey, I need Javascript function foo()". We call a generic bit of Java code that knows how to make sure that foo() is available, and writes it out right at that point (or does nothing if foo() has already been incorporated). > 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! I sure think it can be done just as easily - and much less hack-ily - by the Renderers. > 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? Obviously, any way to avoid a post-processing parse would be a good thing, but a filter could be a way to address the dummy form issue. Still, I don't think dummy forms and the other Javascript need to have the same solution. Cheers, Adam
