[Seaside] Re: Any design pattern for scroll issue when using call/answer?

[John McKeon]

You might take a look at
http://www.lukas-renggli.ch/blog/ajaxification?_s=jMUTD9qfTpGmftem&_k=06VFYynf&_n&47I
haven't tried it yet but it comes from a reliable source. There is an
FAQ
about it here<http://www.lukas-renggli.ch/blog?_s=jMUTD9qfTpGmftem&_k=kR5-V9Ie>

On Wed, Mar 25, 2009 at 9:43 AM, Chun, Sungjin <chunsj at embian.com> wrote:

> 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
>> seaside at lists.squeakfoundation.org
>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>>
>
> _______________________________________________
> seaside mailing list
> seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/seaside/attachments/20090325/bc18470e/attachment.htm