The autoscroll feature makes the browser page automatically jump down (and right) to the place where the user had scrolled before a page refresh. This happens regardless of which component caused the page refresh. So it's not a particular Renderer that might take advantage of autoscroll, it's the whole page. -M
On Apr 1, 2005 11: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] > > >
