Well, another option would be to analyze the responseWriter as things are beng written.
I have to do this with a re-rendering framework I made. I catch all javascript that is written and save it to be written out at a specific point. However, this framework requires control over the <html> and <body> tags, so this strategy might not be applicable to us. With regards to the performance hit, I'm more afraid of memory usage than actual performance time. Over-buffering could result in a decrease in potential concurrent users due to more garbage collecting. On Apr 1, 2005 3:22 PM, Sylvain Vieujot <[EMAIL PROTECTED]> wrote: > Yes, it requires to buffer the all request, and that's what's done today. > 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 javascripts, 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="foo.faces"> </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 > > > -- -Heath Borders-Wing [EMAIL PROTECTED]
