Hi Avi,

sounds very interesting!! At work we are using WebObjects and I learned 
to appreciate the strict separation of html and code. I once thought of 
implementing a WebObjects-like framework in Smalltalk but the lack of 
time ....

Can't wait to see it. If you need any help, feel free to contact me (on 
or off the list).

Cheers,

felix


Avi Bryant 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
> 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
> less simple than what you describe.
> 
> 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).
> 
> - 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).
> 
> - 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']
> 
> - 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.
> 
> - 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.
> 
> - 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.
> 
> 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
> 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.
> 
> 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. ;-)
> 
> Cheers,
> Avi
> 
> 
> 
> 
> 
>