Avi Bryant <avi at beta4.com> wrote:
> Goran,
> 
> After reading your posts on your HttpView framework, I thought I'd say
> something about the work I've been doing, to avoid possible duplication of
> effort.  Julian Fitzell and I have a quite full featured implementation in

Goodie!

> Squeak of a WebObjects-like framework (but better, of course) for
> developing web apps.  It is emphatically *not* like JSP/Servlets/etc (I
> detest code embedded in html as much as you do), although it is certainly

Yes thanks. I actually "bounced" my little miniframework on our
"Bluefish local
java Tomcat/Struts/JSP gurus" and it was interesting to hear about all
the "duplicated code"
problems they have etc. For example, adding a field to a form required
them to change
in three places. I change it in one method and even though I today name
the field
in two places in that method I am thinking of reducing that to one
place. Somehow... :-)

> less simple than what you describe.

Well, mine is deadsimple - and don't think I don't know that. It's just
that I like to
work that way - get something working and improve on it later on.
 
> A brief sketch of the ideas behind it:
> 
> - complete separation of html from logic: each page is described by an
> html template with no code or special tags of any kind, and a class with
> no html snippets, url generation, or direct interaction with the HTTP
> request.  Let the designers do straight html and the programmers do
> straight smalltalk.  However, the html can be in the image instead of
> external files (and in fact I write most of my html in a lispy-syntax
> using array literals).

Ok. Sounds like "traditional good old values" which I agree on. In
theory.
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. But I DO want to be able to work with the HTML as
separate as possible
from the logic of the application.

> - a set of "bindings" connects the template elements to the smalltalk
> elements.  These can usually be inferred through naming conventions, but
> can also be specified explicitly.  The basic idea is that form elements
> are connected to instvars (eg, the system makes sure that a particular
> input and a particular instvar always have the same value), and
> links/buttons are connected to methods - when you click on that link, that
> method is called.  The method may take an argument giving some context
> (ie, which of a list of items was clicked on).

The same/similar architecture is actually used in 4D (yep, I have
actually messed with that tool a bit
helping out my girlfriend). The idea of "mirroring" the form fields into
variables and links/submits
to methods is nice.

I don't have the former - I am thinking about other variants on that.

The latter though is close to what I have. Ok, let me type down a short
description here:

I register an instance of TopView (inherits from HttpView which is the
abstract base class) as a Comanche
module (wrapped in a HttpSessionModule from Diego Gomez). This guys is
created once with an instvar
holding onto the server model object (top root of the domain model) and
sits there waiting for calls to his
#process: method.

When a request comes in to the TopView object it takes a look at the url
and checks that the beginning
of the url matches it's so called "prefix" (an instvar with a string
like '/squeakdot').
If it matches then it goes on - otherwise it returns nil to Comanche
which can
try another Comanche "module".

Then the TopView takes the next "directory name" in the url and calls a
method on self with that name taking
one argument (always one - the request). Note here that it doesn't care
about the rest of the url yet.

So for example (SqueakDot doesn't do this currently, I will change it
back though), the url:
http://marvin.bluefish.se:8080/squeakdot/account/addpoll

...would call the method #account: on the TopView. That method would
decide that hey - this is a call which should
be routed to a view on the logged in account. By double dispatching on
the account instance it then creates an
HttpAccountView (on the fly) which holds the Account object as it's
model and a parent pointer back to the TopView.
So the HttpView objects are created on the fly currently (might hold
onto them in the future but...) creating a chain
more or less mirroring the structure of the domain model.

It then picks out the next "directory name" and calls that method on the
HttpAccountView - that would be #addpoll:.

Other frameworks I have seen maps the complete url in one go onto some
method somewhere. I am not sure what's
"best" but one nice thing with my approach is that for example - I only
need to check if the user is logged in to an account
and look that account up (using Diegos stuff, very nice) IN ONE SINGLE
PLACE. All urls that begin with:

http://marvin.bluefish.se:8080/squeakdot/account/... will pass through
the method #account: in TopView. I like that.

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

> - pages can be called like subroutines and return values to their caller;
> ie, inside a method called from a link, a series of other pages can be
> called; the browser will be forwarded through them.  When they return, you
> will be back at the original page.  This allows complex multipage
> control flow to be specified in a single method.  As a really simple example,
> the basic Page class implements #inform:, #confirm:, and #confirm:orCancel:
> that work exactly like the MVC methods, allowing code like:
> 
> 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.

But I like it. I have been nurturing other ideas but I have to play with
them before
I can describe them. It's about "building" webpages by letting the
HttpView instances
work with a HtmlBuilder instance (which can do whatever he likes to
produce the end result
HTML, <place funky web acronyms like XSL, templating etc. here>).

Such a model would perhaps also be able to "compose" pages from multiple
"methods". Am I making sense? We will see.
 
> - sophisticated backtracking support: by using snapshots of state,
> continuations, etc, the system can be made quite transparent to the use of
> the browser back button; for example, subroutine calls to other pages may
> return multiple times to the same spot (ie, in the above example, someone
> could use the back button to choose a different branch of the #confirm:).
> This can be disabled if it isn't needed.

Tricky! I might be leaning to a simpler more direct "on the metal"
approach
in the spirit of not trying to hide the Http flow from the developer,
but it still sounds very cool.

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

> - it comes with some nice goodies like web-based inspector, profiler, and
> configuration tools.
> 
> - it currently works with PWS, Comanche, or Apache, and can be made to
> work with anything else quite easily.

Whew! You guys have been busy bees... :-) My feeble little framework
pales
in comparison. But I will of course always claim that it is "By Design"!
:-) :-) :-)

> I'm posting this even though we haven't had time to pull
> together a release yet, since there seemed to be some interest in web
> apps.  Goran, if you happen to want to coordinate, perhaps we can do so
> off-list.  I don't actually expect you to use our work instead of your

Sure, I will try to wrap my little thingy up in a first release today or
tomorrow.
It will get posted to the list.

> own framework (it's very nice to have a framework you know to the smallest
> detail, after all) but no doubt we can learn something from each others'
> experiences.

Definitely. A sortof "descriptive survey" of all available frameworks
would be nice
to compile. Damn, another thing on that loooong todo list.
 
> Oh - the name: it builds on work I did in Ruby called IOWA (Interpreted
> Objects for Web Applications - there's some info at
> http://beta4.com/iowa), but the Squeak version has advanced far
> enough beyond IOWA that we may call it something else.  The other
> alternative is SEASIDE, which has something to do with eggplants.  But
> more on that later, perhaps. ;-)

He!

> Cheers,
> Avi

Cheers, Göran
PS.
<CSOTD>
"Damn, a new day has come and Celeste is hungry for a new CSOTD.
You will have to wait for a bit..."
</CSOTD> DS