User Experience Report (WAS Re: [Seaside] Nearing 2.3)

[Nevin Pratt]

A couple of days ago I rebuilt my development image from scratch, and 
installed Seaside 2.3 instead of 2.21.  Within a few more days I expect 
to have my wife's site (http://www.bountifulbaby.com) entirely converted 
to Seaside 2.3.  A few days before before working with 2.3,  I had 
started the conversion of the site to Seaside 2.21, but fell into old 
web habits that were not optimal for Seaside, and didn't exploit Seaside 
as it should.  So, I started over, but with 2.3 this time.  Here are a 
few quick notes on what I found:

1. Seaside 2.3 seems to be quite stable.

2. Not surprisingly, some of the API has changed (I suppose in any 
upgrade this is to be expected).  However, due to my own lack of 
understanding of the Seaside internals, it wasn't immediately apparant 
what the equivalent 2.3 functionality was.  Over the last few days, you 
can find a number of my posts to this list that illustrate.

3. I find that the simple enhancement of being able to do
      html bold: 'foo'
   instead of:
      html bold: [html text: 'foo']
   to be extremely useful.  This one enhancement alone makes the switch 
from 2.21 to 2.3 worth it.

4. The lack of a pretty-printer for the html builder is annoying.  To 
me, this is probably the single biggest downside of moving from 2.21 to 2.3.

5. The way that 2.3 builds a DOM tree rather than directly printing HTML 
is intriguing.  However, from my perspective (building the 
bountifulbaby.com site), it really doesn't seem to change anything.  No 
apparant advantages, nor apparant disadvantages.  From the perspective 
of my #render... methods, everything seems to be working the same (other 
than the enhancement stated in #3, above).  But, realizing that there is 
a DOM tree behind the scenes garners a vague suspicion that there ought 
to be ways to exploit the DOM tree that I haven't thought of yet, and 
that using a DOM tree is potentially a huge win.  I just don't know 
where the win is, though.

6. Many of the old examples are either completely broken, or partially 
broken.  This will make it harder for new folks to start with 2.3 than 
if they started with 2.21.  For me, this is a downside of 2.3, but a 
smaller downside than the lack of html pretty-printer is.

7. As I think about how Seaside works, I have a vague suspicion that 
Seaside is not really suitable for high-volume sites.  However, as I say 
this, let me also add that I think many folks/companies are overly 
concerned about performance.  In my case, my pipe to the internet is *by 
far* the biggest bottleneck, and I suspect that is true of most other 
folks/companies.  And in any case, I also suspect that Seaside produces 
a better performing web site than most Java-driven sites have (Java 
servlets and various Java frameworks-- like Struts, for example-- are 
not that particularly performant).  But, Seaside definitely has a higher 
back-end overhead than stateless (Smalltalk-driven) approaches have 
(such as raw Comanche modules, etc.).

8. Most of the bountifulbaby.com site right now is static pages. 
 Seaside produces *no* benefits at all for a purely static web site. 
 Indeed, it even has a rather large downside for purely static sites, by 
not easily allowing "roundtripping" of page creation from, say, 
Dreamweaver, to Seaside, and back.  And, no, CSS doesn't seem to cut it 
as a complete designers tool, so losing the "roundtripping" is a huge 
loss for static-only sites.  However, the more dynamic the site, the 
more advantages Seaside yields.  For a completely dynamic site, I think 
Seaside is unparalleled in it's excellence.

Overall, I am very satisfied with 2.3, and wish to congratulate the 
Seaside folks for their very fine work, and their very fine help on this 
list.  And, like I mentioned above, there should soon be another public 
Seaside-driven web site online (at http://www.bountifulbaby.com).

Thanks,

Nevin



Avi Bryant wrote:

>Hi all,
>
>I'm putting up a 2.3a snapshot for evaluation at
>http://beta4.com/seaside2/downloads/Seaside2-3a.st.  I made a number of
>fairly large changes recently, and I've been feeling antsy that they're
>only available to the (non-existant?) minority of users that track CVS.
>This code isn't totally complete, but please do try it out.
>
>The changes include:
>
>- HtmlRenderer now builds a DOM tree rather than directly printing HTML to
>a stream.  This provides a greater amount of flexibility in various
>places, without (surprisingly) seeming to impact performance.  A more
>minor change (stolen from Cees) is the ability to use either strings of
>blocks pretty much anywhere, ie,
>
>html bold: 'foo'.
>html bold: [html text: 'foo'].
>
>- The StateHolder mechanism has been generalized so that any object can be
>registered to have the values of its instance variables backtracked.  For
>example, in WABrowser>>model:, you'll see
>
>  self session registerObjectForBacktracking: model.
>
>This means that the state of the Browser instance will be snapshotted each
>time it changes, and using the back button in the web-based browser will
>have correct behavior.
>
>Component classes that previously used StateHolders for all (or most) of
>their instance variables can now simply register themselves for
>backtracking at #initialize time.
>
>Yes, this can eat memory quickly if abused.  A "profile memory" link has
>been added to the toolbar to keep tabs on this.
>
>- The fairly complex Container model has been replaced with a much simpler
>notion of delegated components.  Each component has a 'delegate'
>StateHolder.  When a component is asked to #call: another component, it
>stores that component as its delegate.  When the #call: returns,
>'delegate' will be cleared.  When asked to render itself, a
>component with an active delegate will forward the render request to the
>delegate.  This means that a component will appear to be replaced, in
>place, by whichever component it calls.  This behavior is roughly
>equivalent to having each child component created with #containerFor: in
>2.2.
>
>The "inspect" link now presents a view of the current component tree,
>showing delegation, so that you can pick which component you want to
>inspect.  This can be useful for understanding the new model.
>
>- The codebase has been massively restructured and more cleanly layered.
>Some semi-coherent notes:
>The "Base" layer consists of Request, Response, and a completely new URL
>handling mechanism, the WARegistry.  This knows nothing about Sessions,
>but flexibly manages request handlers that map either to static urls or to
>unique, generated keys.  If a unique key exists in the url but there is no
>active handler for it, the registry will fall back to the closest static
>handler.
>The "Session" layer adds continuations and state backtracking.  It knows
>nothing about Components.
>The "Component" layer includes the delegation and embedding model.  For
>now, it largely shields user code from the changes to the other layers
>(#registerAsApplication: still works, for example).  It also includes all
>the development and configuration tools.
>The "Rendering" layer is mostly orthogonal to all of this; it provides the
>callback scheme and HtmlRenderer.
>
>Known issues:
>
>- The Wiki example is currently broken.
>- The new HtmlRenderer does not yet support pretty-printing.
>- Usage patterns for Application, Session, and Registry have to be more
>fully worked out (where does the current notion of preferences go?  Is it
>still appropiate to subclass Session? etc).
>
>_______________________________________________
>Seaside mailing list
>Seaside at lists.squeakfoundation.org
>http://lists.squeakfoundation.org/listinfo/seaside
>
>
>  
>