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. (Note: #renderContentOn: instead of #renderOn: is meant??)

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

-- 

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

   - Andreas

-- 

Basically, since Seaside is component based anyway, many people build a 
root component to contain header, footer, menus, etc, and then a component 
for body.  You can then set the body component to any component you like and 
it'll render, no need for call.  As Goran said, the component model is what 
makes Seaside rock so much, it's just like programming a desktop application, 
no fussing with state.

--

I think it might be worth pointing out that Pier may be an option and is used 
by many, such as Lukas for their personal websites.

Looking at the components of a web site.

Content: text, files, images can all be entered and uploaded using the website 
itself. Style: At present the stylesheet is stored in a class, served as a set 
of files, and can be edited directly. (I have done an 'edit style via website' 
experiment too.) 

Layout: The layout is defined as an assembly of other 
embedded components or pages and can be edited via the website at: 
/seaside/pier/environment. For example I replaced the header component with my 
own picture, this is trivially easy to do. 

Nice urls: Pier supports sensible bookmarking

This is just the starting point, for any more complex stuff, seaside 
components can be embedded, magritte is part of the base package, and there 
are many other plugins such as rss, blog, two security models etc.

Keith

--

This is an interesting point. But I'm not sure I understand Magritte enough to 
be able to make a good decision. First, I think Magritte isn't being used to 
define application control flow, is this correct? If not, how does one define 
control flow in Magritte (data flow I can see by having editors on editors on 
editors but control flow seems different).  Second, Magritte is effectively an 
extension to Seaside, no? Therefore, any decision about Magritte would imply 
to go with Seaside too (incl. the good and the bad of it).

Thanks for any insight you can provide.

--

Workflow can be accomplished by subclassing WATask instead of WAComponent. 
Tasks are components with no UI, that mediate child components.  They are one 
of the most unique things about seaside and use continuations to allow you to 
model the entire workflow as a single clear method.

--

Magritte is orthogonal to seaside, it is not really related conceptually apart 
from the fact that seaside can be used with Magritte.

From what I understand, which is very little, Magritte enables you to describe 
your data types in such a way that forms for editing those data types can be 
built automatically. So Magritte is at a different more fundamental level, it 
supports the data modelling.

Seaside components as editors onto the underlying model are only one possible 
emitter/front-end from Magritte. Magritte can equally well be used to emit a 
morphic ui for editing the same data. As web interfaces are becoming richer 
with AJax and XUL front ends. Magritte seems equally well positioned to keep 
up with the latest fads, to generate XUL interfaces onto its model, rather 
than going through the inconvenience of HTML.

Since Pier is built on Magritte, this has the practical benefit that the data 
in Pier is fully accessible outside of html, via alternative front-end 
frameworks. It is possible to use a morphic browser onto the same model 
without any extra work.

Keith

--

No, Magritte is a meta model on top of classes.  It's a stand alone package 
that can be used from Seaside, Morphic, or just plain Smalltalk.  The package 
for Magritte enabled Seaside views is separate.

In practice, Magritte is mostly used in Seaside, but the model is useful by 
itself.  For example, I've used Magritte's meta model to generate Glorp 
descriptions dynamically.  It contains everything I need, types, required 
fields, relationships to other classes, etc.

Actually, Magritte is metadata for an object, it really has nothing to do with 
views at all.  The metamodel describes selectors and their relationships to 
other objects, predicates for validating potential values, constraints on 
fields like length, or type, datasources for potential valid data like a state 
list, etc.

Magritte is similar to pragmas except done with ordinary Smalltalk code which 
allows more than just literal metadata.  Magritte metadata is executable and 
can include expressions.

The metadata happens to be quite useful in generating views, but that's not 
all its useful for.  It can generate db schemas, db queries, object graph 
traversals, visual representations of the model, charts, graphs, anything 
really.  It's just metadata, its purpose is in the eye of the developer. Like 
pragmas, that metadata could be useful in a number of circumstances unrelated 
to the UI.

In case you're interested, I have a screencast where I build a simple blog 
using Seaside and Magritte in about 15 minutes.  Something to look at if 
you've never used either.

http://onsmalltalk.com/programming/smalltalk/screencast-how-to-build-a-blog- 
in-15-minutes-with-seaside/

Ramon Leon