Hi!

> Yes, making it work like Seaside, and to work with Seaside, would be
> great!

Hehe, right, but we don't want to "copy" Seaside in general - that is not
interesting - Seaside is still King in its area (complex web apps). HV2 is
simple and straight, and yes, if you try to build complex web UIs with it,
it will demand more "manual tricks" (url params, hidden fields etc).

I have been wondering if we could move it forward a notch regarding forms
and state handling. First of all I want to make views *able* to be
"persistent". A persistent view would be created just like now but would
"stick" to the user session and have a lifespan of the whole session
(today in HV2 views are created for each request and then thrown away).

Thus a view - if persistent - would have a similar lifespan as a
WAComponent in Seaside. User sessions are done using a session cookie.

Ok, this would then let us take a different approach regarding Forms. In
Seaside callbacks are registered on uniquely identified renderings of
buttons and fields etc. But the buttons and fields are not kept around,
they are only created and used on the fly when generating HTML.

In HV2 (today) we rebuild the same Form twice - once for the GET and then
a second time (with the *same* fields in the *same* order) when we handle
the POST. Thus we can populate the objects representing buttons and fields
with their posted values when we recreate them the second time. It is a
dirty trick, but works amazingly good in practice if you don't get too
hung up on following the patterns it demands.

If we had *persistent* views then the view could simply hold onto the
fields and buttons in instvars when we build the form for the GET and when
we get the POST HV2 can simply lookup those buttons and fields by id (in
say a weak dictionary in the user session) and stuff the values into them.
So we don't need to rebuild the form the second time (when the POST
arrives) and we don't need to rely on ordering for matching.

All you web-framework-implementors out there - does this sound
interesting? Viable?

It would of course demand a session cookie as soon as you want to use
Forms - but wouldn't such a requirement be ok to live with? And yes, it
would only handle "one such Form per session" but that seems ok.

>> Finally - the name HttpView2 really sucks. :) If/when we get these
>> improvements on the road (cleanup, Giovanni-canvas,
>> Seaside-piggyback-canvas) we should probably rename it.
>
> Lakeside, Seaview, Beachview, Beachcomber, Beachbum, ...

Beachbum. I like that one! Seaside is the advanced, neat and polished
fella sitting in the yacht. Beachbum is the loose and flippy dude surfin
the waves.

regards, Göran