On Feb 27, 10:57 am, Saikat Chakrabarti <[email protected]> wrote:
> Leslie, your example works, though not entirely as I had hoped. The
> control does get passed to the do-page, but it seems like the
> satisfies function itself does not block. In other words, the rest of
> update-object-view-from-request runs before the do-page returns. What
> I would have liked to happen is that the do-page causes the satisfies
> function te block until either the user logs in or cancels logging
> in. If he logs in, the formview validates (the satisfies lambda
> returns true), and the object gets persisted. Otherwise, the formview
> does not validate, and the object does not get persisted.
Ah. Try some hook trickery to insert the login page after
the action handling:
(push (f_% (do-page (let ((comp (make-instance 'composite)))
(setf (composite-widgets comp)
(list (f_% (render-link (f_% (answer
comp :yes)) "Yes :)"))
(f_% (render-link (f_% (answer
comp :no)) "No :("))))
comp)))
(request-hook :request :pre-render))
You can then decide freely on the return value of your satisfies fun.
Works for me.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
