Hi Goran -

Thanks for the information. This is incredibly helpful.

> In retrospect the main benefit, as I see it, of Seaside in Gjallar is the
> component model. The fact that I can construct the UI using separate
> components that can be used embedded inside each other and still render
> themselves totally oblivious of the environment and the request/response
> cycle.
> 
> The reason for this is of course the fact that a WAComponent is
> "persistent"  in the user session and can hold all its state simply in
> instvars. So it erases the need for "inter request client side state
> management" using say URL params or hidden fields and so on.

Right. This is what I understood to be "special" about Seaside.

> Sidenote: Btw, I haven't thought much about it but in the beginning I
> visualized the HttpView instances to also be "persistent" in the user
> session - but then in practice it turned out (at the time) I didn't need
> them to be - and the rest is history. Perhaps it would be of use to
> reconsider that and at least make it *optional* to have "persistent"
> HttpView chains (as you may know a typical HV2 technique that at least I
> have used is to mirror the hierarchy of the domain model with view
> instances that get chained together matching the hierarchical structure of
> the URLs) that can then maintain state between requests as simple
> instvars.

Yes, and I actually had been wondering about this. It seemed you have 
basically everything in place to match an incoming request with some 
session identifier and be able to simply use the view chain 
corresponding to the request. I don't have a need for this right now but 
it doesn't seem overly hard to me.

> Now - the simplicity in usability of Seaside and HV2 are pretty similar.
> Both lets you build a small app by simply creating a subclass of a given
> base class and then implement methods for rendering. In Seaside you always
> implement #renderOn: and in HV2 you implement methods matching the first
> "directory" in the URL by name.

Right. The small conceptual distance to the HTTP request / response 
protocol make it very simple to follow the control flow in HV2. And of 
course, it's trivial to add your own custom dispatch if you have any 
kind of dynamic content.

> Also, building/handling forms in HV2 is a little bit more "hands on" - HV2
> uses a trivial trick to know which field in the POST matched the field in
> the GET. It is based on the assumption that the POST will build the same
> fields in the same order as the GET will. As long as you follow this
> "rule" it works - *or* as long as you are aware of breaking it and instead
> use explicit ids.

Thanks, that is good to know. I noticed some automatic variable 
generation in the HTML builder which I suspect is at the root of this 
technique ;-)

> HV2 is a neat pick if you want to get up running in 2 minutes *and*
> actually understand how it works - you can use the debugger to follow each
> request all the way from KomHttpServer into HV2, through the view chain
> and all the way back. This of course also makes HV2 simple to "hack" - if
> you want to meddle around with using some "common web techniques" there is
> nothing in HV2 stopping you since it is so "bare metal". The builder
> approach is also not so tightly coupled with the rest so I imagine you
> could easily instead use a template engine if that suits.

Indeed. I have a few "custom needs" in this area so the ability to back 
out a few special URLs to completely other places is really important. 
Again, this is trivial with HV2.

> Seaside is also quick to get running with IMHO, but it is definitely not
> easy to understand (under the hood) - BUT... if you can ignore that then
> you can build apps and still get away with it. I definitely don't
> understand the inner workings of Seaside BUT I have managed to build
> Gjallar nevertheless. :)

That's good to know too. But since I won't be able to understand it, 
I'll need some examples to learn from - what did you use? Given that 
WAStore doesn't seem to be the example of choice, any alternatives would 
be greatly appreciated.

> And finally, RESTful URLs. In HV2 they are the rule and IMHO the simple
> idea of dispatching on each "directory" in turn creating a chain of view
> instances is pretty darn neat. For example, all URLs beginning with
> "/account/" in SqueakMap will run through a single method called #account
> in the root view and that point is the single place where we check that
> the user is logged in and then create an AccountView and let it take over
> to dispatch on the rest of the URL. Quite nice.

Indeed. To me, the simplicity and straightforwardness of this approach 
is _the_ core strength of HV2 since it allows a very elegant overall 
structuring of the application. It is trivial to map out areas of 
interest (/users /products /support) and have HV2 pick it up and do the 
right thing. And I also suspect that some of this will come in handy for 
Apache integration.

> In Seaside I am actually not sure what the "state of the art" is regarding
> explicit URLs. We do have a mechanism in Gjallar (haven't looked closely
> at it, Magnus wrote it) where we deal with a URL having a case number in
> it, so evidently you can rather easily hack it. But this is "on the side"
> so to speak - it doesn't play along with the Seaside AFAIK. There is
> something called Bicephale (http://map.squeak.org/packagebyname/biceph)
> that is more integrated in Seaside - have no idea about it. I guess Lukas
> or Avi will have to answer this one.

That's a bummer. The ability to define accessible entry points into 
sites is one of the core strengths of the web in my understanding.

> Finally - in Gjallar we almost never use #call: btw. And we haven't
> bothered maintaining backtracking state either (which we really should
> look into because right now Gjallar is not "back button" safe). Again, the
> component model is what rocks IMHO.

So how do you build an application if you don't use #call:? The WAStore 
example seems to use #call: exclusively and it is not clear to me how 
exactly one would actually build an application in Seaside without using 
call:.

> Hope this sheds some light on it all. Feel free to ask more.

Yes, this is all very, very helpful. I think I'll stick with HV2 for the 
time being, simply because it's such a nice vehicle for experimentation. 
I'm not quite sure how some of the stuff that I'm doing actually 
integrates with HTTP (this is one of the reasons why custom request 
handling is relevant) and maybe I'll give Seaside another try later.

Ain't it nice to have some alternatives? ;-)

Cheers,
   - Andreas