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