> We should probably be able to plug it in somewhere, yes.
>
> The essence... Hmmm, something like this I think:
>
> 1. Very simple url mapping logic. Each "directory" in a url maps
> directly to a selector in the View classes. I came to the conclusion
> that setting up mappings etc is just "silly work" - for me, 99% works
> just fine with selector names. Actually - I haven't felt the need yet to
> NOT have this 1-1 mapping. Just create the method - and bam, immediately
> addressable from the browser.
>
> 2. HVHtmlBuilder with the "Form smartness". It relies on the fact that
> most Forms are statically built (=don't suddenly have other fields
> depending on context) and that most POSTs will return more or less the
> same page again (with the same form in it, but typically with entered
> values in the fields etc). These two things can be taken advantage of to
> avoid having to deal with ids on fields (autogenerated) and to get
> "widgets" that you can send #value/#value: to.
>
> >  Or is the essence of HttpView that it has very few
> > dependencies? ;)
>
> Hehe! Well... currently it just needs a Comanche of some kind. I just
> got it working with Stephen's new KomHttpServer.
>
> > Avi
>
> regards, Göran
>
> PS. Since I am cleaning it up now and writing some samples etc, and will
> also write an article - this is a good time to start thinking about
> "connecting" with Seaside. Though I am not sure "how".


Sounds alot like the framework twistedmatrix provides.

www.twistedmatrix.com. It's python, yes, but supports just about every 
protocol, and it has a nice framework for supporting more protocols...

I wrote a IRC bot, and about 5 calls to the framework to get it up and 
running...

Woven is very sweet too, applying the MVC paradigm to webforms and apps. It 
uses the same idea of dirs associated with objects and methods.


-- 

The Meek shall inherit the Earth,
for the Brave are among the Stars!