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.
With your example, I put a (format t "test~%") at the end of dataform- submit-action (after the apply #'update-object-view-from-request) and saw that this prints out before the user takes an action on the widget presented in the do-page. Thus, the form validates successfully before the user even has a chance to click Yes or No. When I think about this some more, based on my very basic understanding of continuations, this makes sense to me, but I want to check my logic. What is actually happening is that the lambda/cc specified in the :satisfies slot of the formview creates a widget in whose continuation slot it stores the current state of the app. It then displays this widget (which has the stored continuation) and returns. The method that called this lambda/cc (update-object-view-from-request, which was called from dataform-submit-action) then just finishes execution, because do-page doesn't actually block execution. Then, when the user makes an action on this do-page (after dataform-submit-action has already finished executing), the continuation stored in the new widget is called with the answer, and either yup or no gets printed. Is my understanding correct here? Nandan, I could indeed start the flow with a link, but I want to make the UI such that it is as easy as possible for a user to pledge (with as little clicking as possible). I think the way I may have to end up doing this is some kind of flow that breaks up the form action - perhaps by redefining dataform-submit-action? Thanks, Saikat On Feb 27, 1:46 am, "Leslie P. Polzer" <[email protected]> wrote: > On Feb 26, 7:29 pm, Nandan Bagchee <[email protected]> wrote: > > > Why not do it the other way around? Have a "make a pledge" link that > > starts a continuation flow? > > I think he wants to defer this until later to get non-registered users > interested in his app. > > > I can post two examples of where I use continuations .. in the login > > and in a login-guarded settings page. I'll roust them up shortly. > > Yes, please. > > This and other things make me think that it's better for small > snippets and patterns to go into a Wiki instead of contrib. > > We could collect useful recipes this way. > > > However, others have mentioned on this group that continuations can be > > hard to work with, and someone posted a "wizard" type form that at > > first used continuations, and the later version didn't, because it > > turned out easier to program and understand. > > Sneak preview:http://paste.lisp.org/display/76229 > > :) > > > Besides, deep continuation flow may perhaps be memory-intensive? > > Yes, but I don't think that it's enough to worry about. > The most expensive stuff happens at compile-time. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
