[Seaside] Redirect to the previous page

Lorenzo Schiavina lorenzo at edor.it
Sun Jan 23 09:33:43 UTC 2011


Hi Tony,

I read your very interesting evaluation of ST, and I agree completelly with your point of view.

I have been working with ST for about 30 year (with a previous exerience of programming of 15 year with COBOL, Fortran RPG and other languages) and I am sure you are right; I endorse every word of your presentation.

I will forward your analisys to my students at Università Cattolica del Sacro Cuore di Brescia, where I organized, some years ago, an ESUG event.

Thank you very much for your valuable work!

Lorenzo

----- Original Message ----- 
  From: Tony Fleig 
  To: Seaside - general discussion 
  Sent: Saturday, January 22, 2011 10:40 PM
  Subject: Re: [Seaside] Redirect to the previous page


  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
  >>
  >




------------------------------------------------------------------------------


  _______________________________________________
  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/20110123/5f69b7b0/attachment-0001.htm


More information about the seaside mailing list