2007/3/28, Göran Krampe <goran at krampe.se>:
> Hi!
>
> > Hi Goran -
> >
> > As someone who had exposure to both HV2 and Seaside I am particularly
> > interested in your opinion. Looking at HV2 and Seaside it seems clear
> > that HV2 is a much more straightforward approach that is actually very
> > nice and understandable (I like it a lot).
>
> Glad to hear! And feel free to improve it too, right now Giovanni is the
> one maintaining it - I haven't had the time to look at his snapshots yet.
>
> > Seaside on the other hand,
> > seems much more complex in its control flow (even trying to follow the
> > store example quickly gets you into call/cc and at that point all bets
> > are off).
>
> I actually haven't looked at the store example. ;)
>
> > Given that, what made you use Seaside for Gjallar? What are the
> > characteristics for applications that would be better off with Seaside
> > compared to HV2? I'm more interested in technical areas here btw;
> > clearly there is community and all that where Seaside is strong but I'm
> > just curious how someone like who has used both would characterize when
> > to use which framework.
> >
> > Oh, and what are the prospects for RESTful urls in Seaside these days?
> > Last time I asked about it there wasn't really a good answer - is there
> > one these days? I'm not really into the whole auto-magic URLs myself;
> > I'd rather have it say http://foo.bar.com/users/andreas if I want to
> > refer to a user page.
> >
> > Cheers,
> >    - Andreas
>
> Ok, let's see if I can sum this up. My decision for using Seaside in
> Gjallar was mainly based on the fact that I anticipated rather complex
> user interfaces in Gjallar. The fact that it also has a Scriptaculous
> integration was also a factor IIRC - we do want to use a teeny bit of Ajax
> here and there. I am satisfied with that decision btw.
>
> 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.
>
> 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.
>
> 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.
>
> In Seaside you get a builder sent into renderOn: - in HV2 you create it
> yourself. Then both build its respective HTML. HV2 builds a full page, in
> Seaside the component only builds its own HTML since it can be embedded.

I'm sure you wanted to write #renderContentOn:, implementing
#renderOn: in components is almost always the wrong thing to do and
causes a lot of problems and bugs unless you frigging exactly know
what you are doing.

> In HV2 it is trivial to follow what happens next - the builder simply gets
> returned up the view chain and then gets told to produce its HTML that
> gets sent back in the response. What Seaside does I am not quite sure,
> haven't bothered to dwelve into it. ;)
>
> Personally I would pick Seaside if I can suspect the UI to grow complex OR
> if I want to use Scriptaculous or any of the other Seaside based
> components like say Magritte or Pier. HV2 has no such components that I am
> aware of. :) You can also use HV2 alongside with Seaside, no problem.
>
> 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.
>
> 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 templat engine if that suits.
>
> 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. :)
>
> 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.
>
> 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.

It can be done have a look at: http://www.lukas-renggli.ch/blog/
It's just that you have to create and consume them "by hand", there is
almost nothing to help you with this.
On a component you can implement #initialRequest: to parse the url and
set it up once a new session is created. It's still tricky though
because you can't do #call s in there so you might end up using tasks.
For anchors you can use #addToPath:.

Philippe

> 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.
>
> Hope this sheds some light on it all. Feel free to ask more.
>
> regards, Göran
>
> PS. Cees once built a thingy using HV2 and had some nice words to say on
> his blog:
> http://www.cdegroot.com/blog/2005/12/06/kilauea-magma-server-manager/
>
>
>