Sigh, I was hoping I would get to bed before anyone would reply to this.
I'll respond quickly now, more fully after I've had some sleep.

Goran writes:

>My next improvements move a bit in this direction but my motivation for
>those improvements is not so much that I want to separate the webtech
>from Smalltalk in order to have different programmers working on them. I
>just don't really think that is feasible.

Whether or not it's feasible to have different programmers working on them
from the start, it was a major design goal for me that you should be able
to tweak your templates with Dreamweaver or some such tool at any point in
development - so that you can at least have the designers work on the
HTML once the basic skeleton is there without any conflicts.  We take this
fairly far - for example, the only addition to HTML the framework requires
is that every dynamic element must be assigned an id, and the simplest way
to do that looks like, for example

<input iowa:id="firstName">

but the parser also treats any attribute starting with an @ sign as the
id attribute, so

<input name="@firstName">

would also work.  This is to take advantage of the way WYSIWYG editors
provide dedicated edit boxes for certain attributes of certain elements -
just stick the ID wherever it's convenient.  (This isn't actually built
into the parser, btw, but it's one of the standard macro expansions that
gets run - and yes, you can add your own).

>Another thing - you have bindings, Swiki (at least the old one) had
>something called UrlMaps, the Java Tomcat world
>has these things too. I decided to NOT have any bindings (simpler and
>less places to change) of urls onto methods
>and instead equalize the url path with the method names on the View
>instances. Jury will tell.

The urls are actually all generated by the framework, so the mapping
isn't as simple as between urls and method names.  However, I think the
default bindings provides something similar to your direct method mapping.
For example,

<a href="@delete:">Delete Item</a>

will create a link with an ID of "delete:" - this will default to being
bound to the #delete: method.  However, if for some reason you need to
change the default, you can specify in the bindings

(template elementNamed: 'delete:')
  set: #action toMethod: #remove:

One major reason you might want to do this is if the method it should be
bound to changes depending on context.  This is less common for method
bindings than for most others, however, and I think I almost always just
specify the name of the method in the html.

>> removeItem: anItem
>> (self confirm: 'Are you sure you want to remove the item ', anItem)
>> ifTrue: [items remove: anItem. self inform: 'Item removed']

>Now, this is cool. I think Stephen Pair described a similar feature to
>me at the last OOPSLA.
>Hmmm. This can have both positive and negative sides, no?

>+ Cool. And neat. Hides the Http flow of requests from the developer.
>- Sneaky. Hides the Http flow of requests from the developer.

I don't think of it as hiding the http flow - who *cares* about the http
flow?  What it does is brings the actual *program* flow to the fore,
which is much more important.  (In case it wasn't obvious, I've long since
given up any idea of being lightweight/bare metal anyway.  HTTP is just
too low level to be interesting).

>> - pages or entire applications can be embedded as subcomponents within
>> another page, or wrapped around them. This allows complex widgets like
>> trees, tabs, navbars, etc to be built and reused. Subcomponents use the
>> same transparent bindings system as form elements to sync data with  their
>> parent page.

>Ah, yes, a bit like what I was aiming for. Do you have this part working
>today?

All of what I described works today.  If you want to know what'll work a
month from now, that'll be a whole other list... ;-)

Ok, time to sleep.

Avi