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
