[Seaside] Redirect to the previous page

Tony Fleig tony.fleig at gmail.com
Sat Jan 22 21:45:38 UTC 2011


Oops. The URL in my previous message was wrong. (I wish I would notice these
things before I hit the Send button...)

Here's the correct one:
http://www.tonyfleig.com/smallthoughts/tflogin/deferredlogin.

Sorry for the confusion.

TF

On Sat, Jan 22, 2011 at 1:40 PM, Tony Fleig <tony.fleig at gmail.com> wrote:

> I wrote a somewhat easier-to-understand version of the TF-Login Guide
> paragraphs here:
> http://www.tonyfleig.com/smallthoughts/Seaside/deferredlogin.
>
> TF
>
>
> On Fri, Jan 21, 2011 at 6:13 PM, Tony Fleig <tony.fleig at gmail.com> wrote:
> > There is a feature in my TFLogin package that seems like it provides
> > something like what you want. Registration confirmation may happen in
> > another session, particularly if email confirmation is used. TFLogin
> > allows the application to save state in the "pending user" object.
> > When the registration is confirmed, that same user object is present
> > in the new session and can be used to restore the user's state. This
> > can also be used without email confirmation as well in which case it
> > works essentially the same way except that no new session is created.
> >
> > Maybe TFLogin or something along the same lines would work for you.
> >
> > Here is the relevant excerpt from the TFLogin documentation:
> >
> > New user initialization
> >
> > If you provide a one-argument block to the
> > TLLoginComponent>>#onRegistration: method, your block will be
> > evaluated with pending new user objects before the registration email
> > confirmation (if any) is sent. Your block should answer true to allow
> > the registration to proceed, or false to cancel the registration
> > without further interaction with the user. If you return false, you
> > should arrange to inform the user as to why their registration attempt
> > is being rejected.
> >
> > In your onRegistration block, you can populate the new user's
> > applicationProperties dictionary with initial values. This can be
> > useful if, for example, you have allowed an unregistered user to work
> > at your website and for them to save their work you require them to
> > register for an account. Since the registration confirmation will take
> > place in another session the question arises as to where to save their
> > work during the registration confirmation process (and how to dispose
> > of it if the registration is not confirmed.) Saving the user's work in
> > the pending user object's applicationProperties dictionary provides
> > the answer. When the new user logs in the first time, anything placed
> > in their applicationProperties dictionary in the onRegister block will
> > be present in their TLSession user object.
> >
> > Here is an example onRegistration block in which userObjects are saved
> > in the pending user's
> >
> > applicationProperties:
> >    loginComponent: onRegistration: [ :pendingUser |
> >        pendingUser applicationProperties
> >            at: 'userObjects'
> >            put: self userObjects.
> >        true]
> >
> > TFLogin is available at http://www.squeaksource.com/TFLogin.
> >
> > Regards,
> > TF
> >
> >
> > On Fri, Jan 21, 2011 at 12:28 PM, Sebastian Van Lacke
> > <svanlacke at caesarsystems.com> wrote:
> >>
> >> Thanks Sebastian,
> >>
> >> In my website log in is optional, so I can´t dispatch to the login or
> the application.
> >> I have a link at the top of all the pages for login, and when the user
> click it, I announce that Login was selected, and the root component render
> it. Then, once the user has logged in I want to take it back to the previous
> page, where the user has clicked login.
> >>
> >> Any idea? Has the session the navigation history?
> >>
> >> Thanks
> >>
> >> Sebastián Van Lacke
> >>
> >> _______________________________________________
> >> 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/20110122/718e2a57/attachment.htm


More information about the seaside mailing list