Yeah, that would be a pretty simple solution. Ideally, though you want the javascript to be executed at the last possible moment (actually onLoad would be perfect) because if you have it execute on the first time the renderkit is hit, the client won't yet have the page properly sized, and scrolling may not have an effect.
On Apr 1, 2005 3:32 PM, Adam Winer <[EMAIL PROTECTED]> wrote: > Can someone explain to me why it wouldn't work perfectly > well to output the autoscroll Javascript when: > - A Renderer that might take advantage of autoscroll is rendered > - The autoscroll Javascript hasn't already been written > > Everyone keeps jumping to filters and custom tags; I can imagine > that for the dummy form code, but I can't imagine why either is > necessary for custom Javascript. > > -- Adam > > > On Apr 1, 2005 1:04 PM, Heath Borders <[EMAIL PROTECTED]> 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] > > > -- -Heath Borders-Wing [EMAIL PROTECTED]
