Hello,
Are there a well known pattern for seaside to deal with the browser scrolled page when using sub-component and callback? When using a lot sub-components, each time the work-flow returns, the browser scrolls back to the top of the html canvas. Once Randall suggested Anchor. I am not sure how it can be generalized for lot of sub-components Lukkas explains about how to do it with two components: http://lists.squeakfoundation.org/pipermail/seaside/2007-February/010572.html In the other hand, is it possible to generalize the use of the scriptaculous inPlaceEdit for any component? Or may be just keep the html canvas to reside in one screen height when there is user editing taking place? Thanks for any additional tips. Hilaire _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside signature.asc (196 bytes) Download Attachment |
I try to see the difference facet of the problem regarding mix use of
composition and the scroll problem. May be my view is partial because I don't know much javascript, but here it goes: So far, I see mainly 3 concomitant issues: 1. when you call a sub component, the canvas scrolls back to the top 2. when you return from a sub component, the canvas scrolls back to the top 3. when you click a link with a callback changing the state of the canvas, it scrolls back to the top Regarding the history of the comments in this mailing list, I see the problem can be solved using anchor. But the problem is far to be optimal as it breaks reusability of the component. For issue #1, I try with a special Anchor decoration, with this render method: renderContentOn: html html anchor name: anchor; script: (SUScript new goto: '#', anchor). html text: ''. self renderOwnerOn: html. Don't ask me why the html text: '', otherwise the anchor is rendered toward the end of the component (is it because the component has the Form decoration?). The decoration does not solve entirely reusability because the #answer message in the sub component is out of the reach of the decoration. So you still need to subclass component to get the scroll back issue #2 fixed, for example I sub-class WAChoiceDialog to override method ok: ok self session jumpToAnchor: anchor . super ok Not nice For issue #3, it is quite simple: html anchor callback: [attribute pushVersion: 'votre texte'. self session jumpToAnchor: self hash asString]; with: '( + )'. Any comments or additional ideas? Hilaire Le mardi 24 mars 2009 à 14:31 +0100, Hilaire Fernandes a écrit : > Hello, > > Are there a well known pattern for seaside to deal with the browser > scrolled page when using sub-component and callback? _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside signature.asc (196 bytes) Download Attachment |
What I've used for this kind of problem is save the scroll position to
the cookie(not the anchor label but the "real scrollbar position" using Javascript). On Mar 25, 2009, at 6:25 PM, Hilaire Fernandes wrote: > I try to see the difference facet of the problem regarding mix use of > composition and the scroll problem. May be my view is partial > because I > don't know much javascript, but here it goes: > > So far, I see mainly 3 concomitant issues: > > 1. when you call a sub component, the canvas scrolls back to the top > > 2. when you return from a sub component, the canvas scrolls back to > the > top > > 3. when you click a link with a callback changing the state of the > canvas, it scrolls back to the top > > Regarding the history of the comments in this mailing list, I see the > problem can be solved using anchor. > > But the problem is far to be optimal as it breaks reusability of the > component. > > For issue #1, I try with a special Anchor decoration, with this render > method: > renderContentOn: html > html anchor > name: anchor; > script: (SUScript new goto: '#', anchor). > html text: ''. > self renderOwnerOn: html. > > Don't ask me why the html text: '', otherwise the anchor is rendered > toward the end of the component (is it because the component has the > Form decoration?). > > The decoration does not solve entirely reusability because the #answer > message in the sub component is out of the reach of the decoration. So > you still need to subclass component to get the scroll back issue #2 > fixed, for example I sub-class WAChoiceDialog to override method ok: > ok > self session jumpToAnchor: anchor . > super ok > > Not nice > > > For issue #3, it is quite simple: > html anchor > callback: [attribute pushVersion: 'votre texte'. > self session jumpToAnchor: self hash asString]; > with: '( + )'. > > Any comments or additional ideas? > > Hilaire > > > > Le mardi 24 mars 2009 à 14:31 +0100, Hilaire Fernandes a écrit : >> Hello, >> >> Are there a well known pattern for seaside to deal with the browser >> scrolled page when using sub-component and callback? > > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
You might take a look at http://www.lukas-renggli.ch/blog/ajaxification?_s=jMUTD9qfTpGmftem&_k=06VFYynf&_n&47 I haven't tried it yet but it comes from a reliable source. There is an FAQ about it here
On Wed, Mar 25, 2009 at 9:43 AM, Chun, Sungjin <[hidden email]> wrote: What I've used for this kind of problem is save the scroll position to the cookie(not the _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Free forum by Nabble | Edit this page |