HV2 revival

Hi folks!

I am taking a new look at HV2, my interest rekindled by both Andreas
recent interest but also especially from Giovannis new work on it.

Some things I want to be true for HV2:

- Very simple to learn and use. This means small codebase, clean of junk
and made easy for YOU to enhance it at will. And good comments, examples
and tests.

- Made for RESTish (not as fundamental as REST-*ful*) apps but also being
a good image citizen playing along with both Seaside and other packages.

- A friendly place to help out. I gladly hand out write access to the
repository to people that show interest in it.

Personally I think it is quite messy right now, I want to go through it
all and clean out old junk and go through comments and make some more
examples.

Currently Giovanni is working on a new Canvas/Painter model similar but
independent of the one in Seaside. While the old model in HV2 "works" it
of course suffers from the same combinatorial explosion problem that
Seaside experienced with is old model (btw, HV2 and Seaside share the same
DOM model for that).

I started writing a HV2 layer on top of Pier, for fun. First I thought of
using Giovannis canvas stuff - but it is not there yet. Then I started
experimenting last night with a "piggy backing on Seaside" approach - I am
subclassing selected classes in Seaside in order to reuse most of the
Canvas model in there. It looks quite promising, but I haven't decided yet
how to deal with Forms etc, any ideas welcome.

Another thing mentioned before is that I would like to add "persistency"
to the Views. Currently the HV2 "view-chains" are created per request. But
if we use a session cookie we can keep them around and use instvars to
keep track of "view state" - much like Seaside does.

And oh, I have also decided to publish two apps I have written using it as
open source - my Homepage Builder and the World Cup betting site. At least
they will serve as examples to look at and adapt for your own needs.

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.

regards, Göran

PS. And while doing this I also intend to squeeze out some improvements to
KomHttpServer, it's long due.

El 4/13/07 4:54 AM, "Göran Krampe" <[hidden email]> escribió:

I always was a HV2 fan.
Hope Giovanni and you give us a super killer 3.10 ready as soon is possible.


Edgar

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

Il giorno ven, 13/04/2007 alle 14.30 +0200, Göran Krampe ha scritto:
> >> 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.

Or maybe for once we could choose a metaphor not related to a beach ;-)

        Giovanni

Indeed. I would choose something that's both, related and yet
independent. Say something like ... "Sunshine".

Cheers,
   - Andreas

Giovanni Corriga wrote:

how about Drift Wood.




--
Jason Rogers

"I am crucified with Christ: nevertheless I live;
yet not I, but Christ liveth in me: and the life
which I now live in the flesh I live by the faith of
the Son of God, who loved me, and gave
himself for me."
    Galatians 2:20

>From: Göran Krampe <[hidden email]>
>Reply-To: [hidden email], The general-purpose Squeak developers
>list<[hidden email]>
>To: [hidden email]
>Subject: HV2 revival
>Date: Fri, 13 Apr 2007 09:54:25 +0200 (CEST)
>
>PS. And while doing this I also intend to squeeze out some improvements to
>KomHttpServer, it's long due.

Ausome!  Glad to hear.  I hope Kom can get in league with Yaws and co. some
day. :)

_________________________________________________________________
MSN is giving away a trip to Vegas to see Elton John.  Enter to win today.
http://msnconcertcontest.com?icid-nceltontagline

Il giorno ven, 13/04/2007 alle 06.51 -0300, Edgar J. De Cleene ha
scritto:
>
> I always was a HV2 fan.
> Hope Giovanni and you give us a super killer 3.10 ready as soon is possible.

Hi Edgar,

I don't know if the new Painter system will be ready when 3.10 is
released. Nonetheless, you can use HV2 on 3.10a already.
I'll also be using 3.10a to continue Painter's development.

        Giovanni

gio I wanted to know if this would not be possible to reuse the  
canvas of seaside.

Indeed.

>
> regards, Göran
>
> PS. And while doing this I also intend to squeeze out some  
> improvements to
> KomHttpServer, it's long due.

We are working on visualization to nderstand packages and we are  
planning to refactor
a bit network. We will were we will arrive.

Stef

El 4/13/07 3:15 PM, "Giovanni Corriga" <[hidden email]> escribió:

> Hi Edgar,
>
> I don't know if the new Painter system will be ready when 3.10 is
> released. Nonetheless, you can use HV2 on 3.10a already.
> I'll also be using 3.10a to continue Painter's development.
>
> Giovanni

I using my own modification for having our eternal TEG game in 3.10.
So I really wants a HV2 in Universe way.
For names of beach , what about one of the many beautiful Italy ones ?
He in Rosario we have La Florida, but is a river beach :=)

Edgar

On 4/13/07, Göran Krampe <[hidden email]> wrote:

> 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.

I like this idea.  It may end up as an interesting and useful
simplification of what Seaside does.  From a Seaside point of view,
this sounds like having a separate, independent Session (in the sense
of a stateful collection of components and callbacks) for each
combination of URL and session cookie.  So each time you navigate to a
new URL you get a new session (and thus links are still GOTOs :), but
within a single URL/form you get Seaside-like convenience.

Avi

Sounds like Giovanni wants the metaphor drydocked.

On Fri, 13 Apr 2007 09:22:50 -0700, Andreas Raab <[hidden email]>  
wrote:

Il giorno ven, 13/04/2007 alle 20.41 +0200, stephane ducasse ha scritto:
I looked at it. From what I saw it looks like the callbacks part is so
intertwined with the rest of Seaside that adapting it to HV2 would take
almost the same time as rebuilding it from scratch. But I'm using the
Seaside Canvas system as a reference for my Canvas/Painter system.

        Giovanni

On 4/14/07, Giovanni Corriga <[hidden email]> wrote:

> I looked at it. From what I saw it looks like the callbacks part is so
> intertwined with the rest of Seaside that adapting it to HV2 would take
> almost the same time as rebuilding it from scratch. But I'm using the
> Seaside Canvas system as a reference for my Canvas/Painter system.

That surprises me - the Canvas hierarchy looks like this:

WACanvas
   WAHtmlCanvas
      WARenderCanvas

WACanvas knows nothing about HTML (and we have some private subclasses
for other XML dialects).  WAHtmlCanvas knows about HTML but nothing
about callbacks (we use it for generating static/RESTful HTML pages).
Only WARenderCanvas should be at all intertwined with the rest of the
framework.

However, if you end up with a cleaner system, I'd love to take a look
at it, maybe we can go the other way and adopt it into Seaside.

Cheers,
Avi

Il giorno sab, 14/04/2007 alle 16.33 -0700, Avi Bryant ha scritto:
It might as well be a problem of DUH (doesn't understand here). I'll
give it another look.

> WACanvas knows nothing about HTML (and we have some private subclasses
> for other XML dialects).  WAHtmlCanvas knows about HTML but nothing
> about callbacks (we use it for generating static/RESTful HTML pages).
> Only WARenderCanvas should be at all intertwined with the rest of the
> framework.

This looks similar to what I have in mind. HV2's Canvas maps to
WAHtmlCanvas, and HV2's Painter maps to WARenderCanvas. The only
difference is that I use delegation between the Painter and the Canvas
instead of subclassing.

        Giovanni

Hi!

"Avi Bryant" <[hidden email]> wrote:
Right, this was/is also my understanding. Which also btw is the reason I
am testing my "piggy backing approach" (since it is so clearly
separated) and it seems to work fine "so far". :)

> However, if you end up with a cleaner system, I'd love to take a look
> at it, maybe we can go the other way and adopt it into Seaside.

One nice thing Giovanni does is using an XML parser and build unit tests
for the canvas/painter through that.

> Cheers,
> Avi

regards, Göran