Fastest way to mock up web UI?

Göran Krampe goran at krampe.se
Wed Mar 28 10:50:07 UTC 2007


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.

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.

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/




More information about the Squeak-dev mailing list