Hi Leslie and Ian,
Thank you both for your clarifications.
It seems then, that the crucial advantage is that one can write a bunch of
simple widgets and use the continuation code to keep track of how the user walks
through them**. This frees up the programmer from having to create a super
widget (what I did) that stores the state in the class instance and the render
methods get complex.
Now, one of the things I needed to figure out, is how to refresh the widget tree
when one widget changes something like login state in an AJAX call. The login
widget I wrote seemed to be fine regarding AJAX as the navigation was already
built.
Just for your information, the GBBopen "blackboard" thinking regarding dynamic
reordering of execution is very powerful in complex problem solving. It seems to
me that the weblocks approach is that applied to user interfaces while
maintaining continuity.
Ian, I have followed Elephant on the side, so many features of it are similar to
a persistent blackboard. So many collisions even in the name space of libraries.
It seems that a cross pollination of the two projects would be wonderful and
result in DRY amongst some very talented lisp programmers.
** Is there an example of this somewhere? So then the continuation parameter
that is passed on in the continuation is the previous widget?
Weblocks (and Elephant) are tightly coupled to the data and data on disk. I
intend to break this model - the software should run just fine of a CDrom boot.
The UI is a view into the data, the real meat of the program will not even have
a view. What I mean by that is, that its like the entire suite of software that
makes email (or X Windows desktop) possible. You have the Thunderbird email
client as the UI - thats Weblocks. There is an IMAP server it talks to, and SMTP
that talks to others, etc. The richness of that environment is greater than
anything that MVC tied to an SQL db provides, although obviously this can be
approximated as it has by so many webmail applications that have become an email
universe unto themselves.
Cheers,
---Venkat.
On 12/14/09 19:49, Ian Eslick wrote:
> To throw in my two cents on the utility of continuations... :)
>
> 1) They are a compact way of representing complex, stateful control flow
> (page-to-page) that otherwise would be represented in explicit state
> variables and generalized functions, as Leslie observed.
>
> 2) I've come to the conclusion that they are nice theoretically, but that
> they are overkill for most operations you tend to perform in web pages. In
> dialogs and do-widget you are basically modeling a stack and when something
> goes wrong, peering through the continuation structures to make sense of what
> is going on is difficult. It took me awhile to get the knack of this. Now I
> pretty much only use it for trivial cases like dialogs.
>
> 3) Apps with state are tough in general to make robust and user-friendly. I
> tend to use a semi-stateless, REST style approach where my urls define a
> general page context (like editor/document) but then use server side state
> via AJAX/closures to represent what's going on within the editor for that
> document. If you hit the back button, you go back to the prior document, if
> you go forward again, you are returned to the same editor state so people
> quickly get that back/forward navigates documents, and that local
> links/buttons manipulate your view of that document.
>
> For me the biggest asset of weblocks has been the excellent infrastructure
> for supporting AJAX via server side modification of client widget, the widget
> architecture (now that the navigation has been cleaned up). Except for
> prototyping or rare cases where it worked out, I don't use the generic
> widgets and views but should probably revisit that now that the team has
> spent the better part of the last year improving them!
>
> Best, Ian
>
> On Dec 14, 2009, at 2:36 PM, Leslie P. Polzer wrote:
>
>>
>> Rayservers wrote:
>>
>>> A continuation system is, at the bottom of it, a way of persisting and
>>> maintaining state in an inherently stateless protocol. The continuation
>>> parameter serves as that. I've put my understanding down in my own words
>>> here.
>>
>> Yes. That's a quite abstract definition but I can't find anything wrong
>> with it.
>>
>>
>>> How would you distinguish this from maintaining state in the widget (what
>>> I did) or a database?
>>
>> Continuations maintain the state of the code execution flow. They come in
>> handy when your state is best modelled by a continuation function ("what
>> code will I execute next").
>>
>> Often an alternative is easier to comprehend and use. Let's take a
>> "Wizard" page flow as example. If there's a linear relationship between
>> pages then we can just model them with a list of widgets and a pointer to
>> the current. However if we have a tree relationship where a page can be
>> reached by multiple predecessor it's way easier to just call the
>> continuation from the "Back" link that restores the previous widget.
>>
>> Of course you could also directly store the widget here, but keep in mind
>> that this is a simplified case; you might want to do other things
>> programmatically besides restoring the previous widget, and we all know
>> that functions do that best. Without continuations you could only store the
>> old data and let a generalized function interpret that while with
>> continuations you just keep old of the rest of the computation.
>>
>> Leslie
>>
>> --
--
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.
