As for the performance hit, this is the problem Oliver raised some weeks ago, and to my surprise, a quick benchmark shows that there is no performance hit. In fact, my results even showed a slight performance gain. I have no clear explanation for this, but I think it's due to the buffering.
This doesn't mean we shouldn't be careful with performances issues if we use this feature extensively, but this can be dealt with and isn't a show stopper.
The fact to buffer the all response opens a all lot of possibilities like the ones Kalle talked about.
It makes also everything dead simple from the user (programmer) point of view. If you're designing complex pages, with many components using _javascript_, this is a real bonus. The pages contain less errors because you can't forget to include the component's _javascript_s, and and is often smaller, as only the code related to the rendered components is included.
As for the autoscroll, I prefer the way it's handled now via a parameter in the web.xml.
By the way, I'll need to find some time to include a document explaining how to configure this filter, and why you need it.
On Fri, 2005-04-01 at 15:04 -0600, Heath Borders wrote:
I'm not too familiar with filters, but won't that require us to buffer the whole request? That seems like quite a bit of a performance hit just for extensions. It seems like it would be better to provide a custom tag for the autoscroll: <x:autoscroll /> Then, then we can guarantee that it will get inserted before the end of the body tag, and the user can use/not use it based on its presence. On Apr 1, 2005 1:43 PM, Sylvain Vieujot <[EMAIL PROTECTED]> wrote: > No, I think Kalle is right. > As the extensions filter is ... a filter, you store some string processings > that will be performed on the generated html. > As this processing is performed after the all JSF response has been > completed, I don't think you have such problems. > It works exactly the same way SiteMesh works. > > Sylvain. > > > On Fri, 2005-04-01 at 13:25 -0600, Heath Borders wrote: > We would have to parse the response then, and add it properly. The issue is > that you cannot guarantee that the <html /> tag will be closed after the > <f:view /> tag is. When the <f:view /> is closed, that's when the > endDocument() method is called. So, if a user has the following > JSP: <f:view> <f:verbatim> <html> </f:verbatim> <%-- more JSF content > --%> <f:verbatim> </html> </f:verbatim> </f:view> This could result in the > following html: <html> <!-- rendered JSF content --> </html> <form > name="dummyForm" action=""> </form> <script > language="_javascript_"> // autoscroll _javascript_ </script> On Apr 1, 2005 > 12:36 PM, Korhonen, Kalle <[EMAIL PROTECTED]> wrote: > > -----Original > Message----- > > From: Heath Borders [mailto:[EMAIL PROTECTED]] > > > Subject: Re: ResponseWriter.endDocument() vs. ADF Faces (and, hello) > > Why > can't we wrap every commandLink/commandButton in its own > > dummy form if > it doesn't have a parent form? This would mean > > See the JIRA on this > http://issues.apache.org/jira/browse/MYFACES-152?page=comments#action_61924. > I suggested to use ExtensionsFilter for this à la SiteMesh, what do you > think? > > Kalle > >
