Scrolling & live stuff (was Re: [Seaside] Re: [ShoreComponents] WebTree, SVG demo and dynamic files)

Julian Fitzell julian at beta4.com
Thu Jul 21 20:47:08 CEST 2005


radoslav hodnicak wrote:
> 
> On Fri, 15 Jul 2005, [ISO-8859-2] Jan B. Krej�� wrote:
> 
>>>> 3) a decorator allowing to preserve page scrolling coordinates between
>>>> submits, so if you have scrolled 5 feet down to find the button you
>>>> want to click, you will see the same page location after the response
>>>> is loaded from server. I saw this in .NET and I like it very much.
> 
> 
> Ok I created such decoration today. The code is trivial. It
> 
> 1) uses onUnload handler to invoke xmlHttpRequest which saves the scroll 
> coordinates
> 2) uses those saved coordinates in onLoad handler next time the 
> component is displayed
> 
> However, there are two issues.
> 
> I have found no way to make this decoration "fork safe". The typical use 
> is like this
> 
> page 1: ScrollDecoration + Component A
> 
> component A calls component B, decoration saves coordinates
> 
> page 2: Component B
> 
> B answers
> 
> page 3: ScrollDecoration + Component A, decoration restores coordinates
> 
> 
> So if you fork page 1, and call component B from each, only the scroll 
> coordinates for the last one are saved. Backtracking doesn't help here 
> because on page 3 we don't go back, we display the old components in new 
> step/context.

Well, there must be a cleaner solution, but without the code in front of 
me and just thinking off the top of my head for a proof of concept, 
couldn't you have, for example, another call method 
(#callKeepingScrollPosition: ?) that noted the scroll position from the 
decoration, made the actual call, and then restored the position after 
the call?  Obviously we'd want to come up with something that looked 
nicer than that to the user, but I'm just wondering if hooking in at 
that point works...

It's also entirely possible I'm wrong on that though; I haven't really 
got my head fully back into Seaside yet and I'd much rather be doing it 
with code in front of me to tinker with.  I've been occupied enough that 
I haven't even downloaded the newest Seaside image yet... how sad is 
that?  :)  Need to get on that next week.

> The second issue is related to publishing this decoration. It simply 
> doesn't work with the liveUpdate script that comes with seaside, because 
> the script can't handle requests that return empty/no answer. In fact 
> the script is too simplistic to handle most of the interesting stuff you 
> might want to do with background requests.
> 
> Avi? Julian? This area needs attention.

This is definitely not something I can comment on at the moment.  I've 
seen liveUpdate in action but I haven't looked at the code yet.  Are you 
suggesting this is a difficult fix or just that it needs doing?  I'm 
happy to take a look at it if Avi doesn't beat me to it.

Julian

-- 
   Julian Fitzell  --  Beta4 Productions
julian at beta4.com  --  http://www.beta4.com
Seaside: http://seaside.st/


More information about the Seaside mailing list