Jumping to named Anchors

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Jumping to named Anchors

Sebastian Nozzi-2
Hi People,

I'm trying to jump to named-anchors (after processing a request) like this:

1) Generating the anchor

html anchor name: someId.

2) Generating another link with a callback:

html callback:[...]; fragment: someId; with:[...].

Unfortunately when clicking on the second link, after processing the
request, the anchor-name gets lost (there is a redirect in-between
right?).
I know I should re-enter in inside of updateUrl:, but how do I access
the named #anchor in the original request?

And: why doesn't it get passed automatically?

Thanks in advance!

Sebastian

P.S. Do I have to subclass some other classes like the render-loop, or
something like that? I don't have muchi idea of Seaside internal
workings... where can I read more about them?
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: Jumping to named Anchors

Ramon Leon-5


On Thu, Mar 12, 2009 at 9:26 AM, Sebastian Nozzi <[hidden email]> wrote:
Hi People,

I'm trying to jump to named-anchors (after processing a request) like this:

1) Generating the anchor

html anchor name: someId.

2) Generating another link with a callback:

html callback:[...]; fragment: someId; with:[...].

Unfortunately when clicking on the second link, after processing the
request, the anchor-name gets lost (there is a redirect in-between
right?).
I know I should re-enter in inside of updateUrl:, but how do I access
the named #anchor in the original request?

And: why doesn't it get passed automatically?

Thanks in advance!

Sebastian

Try this instead.  In your callback method, as the last line, say

self session jumpToAnchor: #anchorName

I believe that's what you're looking for.

Ramon Leon
http://onsmalltalk.com

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: Jumping to named Anchors

Julian Fitzell-2
On Thu, Mar 12, 2009 at 5:30 PM, Ramon Leon <[hidden email]> wrote:
> Try this instead.  In your callback method, as the last line, say
>
> self session jumpToAnchor: #anchorName

Which is one of the remaining things on WASession in the bleeding edge
code that I still wish we could get rid of. If anyone has any
suggestions for how else to implement it in the context of 2.9 I would
be very happy to hear them. (this should really be a seaside-dev post
but since the thread started here...)

Julian
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: Jumping to named Anchors

Ramon Leon-5

On Thu, Mar 12, 2009 at 2:42 PM, Julian Fitzell <[hidden email]> wrote:
On Thu, Mar 12, 2009 at 5:30 PM, Ramon Leon <[hidden email]> wrote:
> Try this instead.  In your callback method, as the last line, say
>
> self session jumpToAnchor: #anchorName

Which is one of the remaining things on WASession in the bleeding edge
code that I still wish we could get rid of. If anyone has any
suggestions for how else to implement it in the context of 2.9 I would
be very happy to hear them. (this should really be a seaside-dev post
but since the thread started here...)

Julian

Well, start by saying what's wrong with it?  I use it, it fits well with the page centric view of things.  Or is it just because it's on the session and you guys have been cleaning that up?  Conceptually, to me anyway, this is something that belongs on the response.  It's a command I'd be giving to the current response so that the user see's what I want when the response renders.

Ramon Leon
http://onsmalltalk.com


_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: Jumping to named Anchors

Julian Fitzell-2
On Thu, Mar 12, 2009 at 11:25 PM, Ramon Leon <[hidden email]> wrote:

>
> On Thu, Mar 12, 2009 at 2:42 PM, Julian Fitzell <[hidden email]> wrote:
>>
>> On Thu, Mar 12, 2009 at 5:30 PM, Ramon Leon <[hidden email]>
>> wrote:
>> > Try this instead.  In your callback method, as the last line, say
>> >
>> > self session jumpToAnchor: #anchorName
>>
>> Which is one of the remaining things on WASession in the bleeding edge
>> code that I still wish we could get rid of. If anyone has any
>> suggestions for how else to implement it in the context of 2.9 I would
>> be very happy to hear them. (this should really be a seaside-dev post
>> but since the thread started here...)
>>
>> Julian
>
> Well, start by saying what's wrong with it?  I use it, it fits well with the
> page centric view of things.  Or is it just because it's on the session and
> you guys have been cleaning that up?  Conceptually, to me anyway, this is
> something that belongs on the response.  It's a command I'd be giving to the
> current response so that the user see's what I want when the response
> renders.

Yes, exactly. It has nothing really to do with the Session. If it was
backtracked you could make an argument but then it gets reset in the
render phase and the render phase shouldn't be changing state.

I guess if I picture the render loop written out in pseudo code, a new
loop iteration is started at the end of the callback so to implement
it there you'd need a variable outside the scope of the loop. Which I
guess is an argument for it being on Session. :) Still feels ugly
though...

Julian
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside