Just wanted to throw in some tidbits about two alternatives to SSP.

First there is Seaside (check the Swiki, I don't have the url handy) -
the rather advanced framework from Avi Bryant. I haven't looked at it
yet but I have read his postings about it. Sounds very cool, it is
designed to coexist happily with Dreamweaver etc - the only thing it
needs (I think) are ids on all form elements. A lot of cool features in
there.

Then we have my own little experiment going under the name HttpView. It
is a much smaller framework that I am harassing Bolot to include in
Comanche. I can upload what I got later today for you to play with. It
is a rather different approach altogether (compared to SSP and Seaside).

In HV you build webpages much like you build UIs programmatically - you
know - create window, add button, add field etc. Here is a small example
from some of my current code, it is a page with a form for editing a
"channel" object:

default
	"Edit a channel."

	| b resource protocol name description |
	b _ self builder.
	b start; h1: model name; postForm.
	b html: 'Type: ', model type name asString, ' Address: ', model
computeAddress printString.
	name _ b br; br; html: 'Name: '; inputTextValue: model name.
	description _ b br; html: 'Description: '; inputTextValue: model
description.
	resource _ b br; html: 'Resource: '; selectObjects: model account
resourcesWithoutTypes value: model resource.
	protocol _ b br; html: 'Protocol: '; selectObjects: model
availableProtocols value: model protocol.
	b br; submit: 'Save'; reset: 'Restore'; endForm; linkBackParent; hr;
srcLink; end.
	b ifPost: [
		model name ~= name value ifTrue:[model name: name value].
		model description: description value.
		model resource: resource value.
		model protocol: protocol value.
		^self redirectToDefault
	].
	^b
---
As in SSP one method normally maps to one url and it normally builds one
page. The method sits in a subclass of HVHttpView (which means it has
inherited the #builder method etc.).

We start with creating a builder, then we "feed" that builder with page
building instructions - almost like a stream. #start - begins the HTML
page with some standard stuff. #h1: is a simple method to add a Heading.


#postForm begins a form using the POST method - by default this form
will get posted to the same url as the method itself so the POST will
result in this method being run again - aaahhh, tricky.

So, this method could be run either as a result of a GET for the page
with the form to be displayed OR a POST when the user has hit the submit
button of the form. Either way we need to create a result page to
deliver back and most of the time that page is (or at least can be) the
same.

We continue building using #html: which is the method to use when
nothing else works - :-) it just inserts HTML.

The next line is interesting - we begin by feeding in a #br (a
linebreak), some HTML, and then #inputTextValue: which we feed a default
value as the parameter (the name of our model object that this form
modifies - a "channel" with name, description etc). The builder has a
whole bunch of methods for all available input types in Forms and with
varying amount of arguments the others are given default values.

The interesting part is that the method #inputTextValue: returns an
object of the instance HVHtmlInputText - an object representing the
"widget". All widgets respond to the methods #value and #value: and uses
Squeak "types". For example, the HVHtmlInputCheckBox (which can be
created with the builder method #inputCheckBox, uses a Boolean with
#value/#value:. Nice, don't you think?

Without goind too deep we can see that the next three lines creates one
more text field and two dropdown "select" boxes. And of course - the
select boxes uses the REAL objects and not something else.

Then we finish off the page with a break, a submit button, a reset
button, endForm, a simple link back to the parent page (convenience
thing), a horisontal ruler, a source link (to see this code above
directly in the browser) and then we end the page.

The builder has actually not yet "streamed" it all together - it holds
all the pieces in a collection so you can still call send #value: to a
textfield in order to insert the default value and so on.

Next we ask the build if this request was a POST (In the near future you
would instead ask the submit button if it was pressed - seems better).
If it was we apply the values into the model - "name value" will give us
the String for that text field and "resource value" will give us the
selected instance in that dropdown box, etc. Here we could also validate
fields etc. and if there is some form of problem or something we can
still insert message etc into the page (this example does not show that
but it is very easy).

Finally we return the builder to Comanche and since the build implements
#asHttpResponseTo: it will take care of the rest and return the page
(either for the GET or the POST) to the user.

So... we have no SSP/HTML or whatever - only Smalltalk code. Each field,
form etc are only mentioned ONCE - no ids, names or whatever. A complete
HTML page with a form fully functioning with two fields, two dropdowns,
two buttons and code to handle the POST and apply the values to the
modeul in 17 lines of Squeak code.

Well, I like it anyway. There is much more to explain - this short email
doesn't explain how the urls are mapped down to the methods or how the
HVHttpView instances are created - but it's very simple.

regards, Göran

PS. Seaside is a much more ambitious project and can connect to Apache
etc (my stuff is just a bunch of classes that works with plain
Comanche). If you are going to build something serious - look at
Seaside, if you like the ideas above and want to play with Comanche -
try out HV. DS