Hi, thanks for this solution Paul. I just want to add that there seems to be a bug in the current stable version of weblocks that breaks the login widget, although it has been fixed in the dev branch. In order to get it all working correctly, I had to patch my installation. Here is the link to the change: http://bitbucket.org/S11001001/weblocks-dev/diff/src/widgets/login.lisp?diff2=59f9a423473d&diff1=43d945eacf07#chg-src/widgets/login.lisp
On Apr 17, 9:12 am, Baqaqi <[email protected]> wrote: > Hi, > > I don't know if this issue is already settled, but I too had problems > using the login widget. > After reading the related postings, I came up with a rather simple and > elegant solution (which is a variant of one of those posted here) > which works for me. > Here is an almost self-contained example: > > (defun init-user-session (comp) > (with-flow comp > (yield (login-page comp)) > (yield (make-main-page)))) > > (defwidget login-maybe (login) > () > (:documentation "Render login form only if not logged in.")) > > (defmethod render-widget-body ((self login-maybe) &key &allow-other- > keys) > (if (authenticatedp) > (answer self) > (call-next-method))) > > (defun login-page (k) > (make-instance > 'composite > :widgets > (list (make-instance > 'login-maybe > :on-login > (lambda (login-widget credentials-obj) > (with-slots (email password) credentials-obj > (if (check-credentials email password) > credentials-obj > (values nil "Wrong password. Try again.")))))))) > > The crucial thing seems to be to wrap the maybe-login widget into a > composite widget, without that it doesn't work. > > - Paul > > On 11 Mrz., 10:44, Robin Lee Powell <[email protected]> > wrote: > > > On Wed, Mar 04, 2009 at 06:45:48PM -0800, Benjamin Collins wrote: > > > > On Mar 4, 8:01 pm, Robin Lee Powell <[email protected]> > > > wrote: > > > > Can you post a tarball of the whole thing somewhere? > > > > Sure:http://github.com/aggieben/simple-blog/tarball/broken-maybe-login > > > Sorry, got busy. > > > It definitely wasn't working, and as far as I can tell, you hadn't > > failed to use it in any way. > > > In fact, I have no idea *how* it was working. My best guess is that > > the login widget it inherits from would re-render no matter what > > happened in :on-login. > > > I had a version in my tree that I hadn't put in the tutorial that > > would expect the child widget to always be a zero-arg lambda, and > > run that exactly once; it makes stuff nicer down the road. > > > Moving the logic for that into check-login gives this patch against > > your tarball, which seems to work, and is The Right Thing anyway. > > > Thanks for giving me chance to clean this up outside of my own work; > > I'll go put this new stuff in the tutorial too. > > > An earlier version simply set dirty in check-login; watching > > weblocks freakout was funny, and also very happy-making: style and > > error checking *GOOD*: > > > [2009-03-11 01:30:10 [WARNING]] During the rendering phase, 1 widgets were > > marked dirty, which should typically be done only during action handling > > [2009-03-11 01:30:10 [WARNING]] Warning while processing connection: During > > the rendering phase, 1 widgets were marked dirty, which should typically be > > done only during action handling > > > -Robin > > > -- > > They say: "The first AIs will be built by the military as weapons." > > And I'm thinking: "Does it even occur to you to try for something > > other than the default outcome?" > > --http://shorl.com/tydruhedufogrehttp://www.digitalkingdom.org/~rlpowel... > > > login_diffs.txt > > 2KAnzeigenHerunterladen --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "weblocks" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/weblocks?hl=en -~----------~----~----~----~------~----~------~--~---
