[Seaside] Seaside Thoughts & Questions

[Daniel Drasin]

Subject: Re: Seaside - love it!
   Date: Sat, 26 Apr 2003 20:37:14 -0700 (PDT)
   From: Avi Bryant <avi at beta4.com>
     To: Daniel Drasin <dan at drasin.org>
    CC:  julian at beta4.com

On Sat, 26 Apr 2003, Daniel Drasin wrote:

> i'm not sure i understand the comment on continuations.  Do you
> mean that they key is to be able to "rerun" a button press from a given
> page (after going "back") to it?  [I'm guessing this is where the value
> of continuations comes in over just using threads to store the stack -
> threads being transient and going away after they are resumed].  Is that
> it?  Or is there something more to it.

No, that's it.  The other half of that comment, however, was that even
if
you did give up on continuations, at a minimum you need one (suspended)
thread per active session, which is quite heavyweight in the Java world
(where threads usually map directly to OS processes).

> Assuming that's true, i would think it would be a reasonable restriction
> to "disable" the backbutton by expiring the pages.  (This was the
> approach i took - actually had a dispatching servlet which made sure
> the request came in the right order and if not, reset the user to the
> right place - seemed like the only way to achieve part2 below to
> make things work across UI paradigms...)

Well, I agree that it's a "reasonable restriction" in the sense that
it's
the best you can do given the technology available in, say, Java, and
given a requirement to have a lowest-common-denominator system spanning
several UI paradigms.  However, one of the things that's so *cool* about
web UIs is the freedom given to you by the back button, and related
features like being able to open a link in a new window/tab and so
explore
parallel paths.  If you watch experienced web users they hit the back
button continuously, and although you can train them not to do this for
a
particular app, you're both annoying them and lowering their
productivity.
Taking away the back button is not something to be done lightly, even if
the requirements of UI pluggability or JVM compatibility may outweigh
this
on occasion.

 > As for the syntax in java question, there are a
couple of solutions
> 1. deal with inner classes, not so bad once you bite the bullet and
> get used to them (the mind can block noise out pretty well after a
> while)

When I write Java code, I use them constantly.  But I'm sorry, they
*are*
that bad, particulary when compounded by Java's horrific type system.
Compare:

html textInputWithValue: person age callback: [:n | person age: n].

html.textInput(new Integer(person.getAge()), new Callback() {
  public void takeValue(Object value) {
    person.setAge(((Integer)value).intValue());
  }
});

Maybe your noise filters are a lot better than mine, but I find it real
hard to pick out the content from that mess of syntax.  And making it
clearer by introducing temp variables also makes it longer.  Pretty soon
a
simple render() method takes two pages instead of 3 lines.

> 2. preparser.  This is becoming a popular java solution (xDoclet an
> JAspect are good examples).

Been there, done that:
http://www.cs.ubc.ca/labs/spl/projects/elide/

But adding an extra step to the already tedious edit/compile/run cycle
is
a pain, and these tools tend to get in the way of incremental
compilation
in any form, and they make debugging much harder, and...

> 3. java api.  Something along the lines of S-Expr could handle most
> cases, i'd think.

Not sure what you mean by this one...

> 1. is probably the way to start (easiest), but 2. is probably the
> right long term approach (which could of course be combined with
> a solution to the continuation issue - since you could rewrite all
> method calls...)

Yeah, Shriram Krishnamurti had a very interesting paper that rewrote
Java
code to get continuations, basically so he could add a back button to
Swing apps (the subtitle was "Growing GUIs on Trees").

> At any rate, the big benefit i've found in seaside is the avoidance
> of request/response.  I think it would be a big hit in the java
> space too.  Maybe someday...

Well, it's still an open question, and I do think every once in a while
about trying to take what I've learned from Seaside and building a Java
web framework - I do believe that I could do something that would blow
all
of the current frameworks out of the water.  What I'm certain of,
however,
is that *for me*, it would be a much less productive system than what I
already have in Squeak.  Moving to the JVM and especially to Java as a
language would be a collosal step down in almost every area I care about
-
so why expend any effort on a project that wouldn't increase my
productivity?  The only possible justifications would be if it was
either
a viable commercial product or a high enough visibility open source
project to bring some peripheral benefit.  I don't think the first is
realistic these days, particularly given how saturated the "market" of
Java web frameworks is, and I don't think I believe enough in Java as a
platform to pull the second off (and besides, the niche Smalltalk market
works out fairly well from a consulting point of view).

So ok, I've probably made it more clear than necessary why I'm not that
interested in bringing this work to Java (unless, of course, someone
were
to pay me directly to do so).  Ignoring technical feasiblity, why does
it
appeal to you?

> As for your comment on method names being an indirection, that
> is absolutely correct.  However, in seaside those blocks can
> contain arbitrary code and they are in a context to directly
> refer to elements of the UI (rather than indirectly through
> a mapping layer).  (That's the difference between refering to
> the element with a tag and calling the method directly from
> the block - getting rid of the context).

True.  But this sounds like a "the developer might shoot himself in the
foot" problem.  Context is only harmful if misused; otherwise it's quite
useful.

> This indirection is key if you consider the distinction between
> application intention and implementation.  Take the example of
> a form, that you want to tell the user that they forgot to
> enter some information.  You'd want to tell the UI element
> (some sort of text element) to highlight itself.
>
>       (UI elementNamed: #textfield) highlight.
>
> In HTML, this would probably mean put a red *, next to it, in a
> windows application, you'd have the widget flash.  Of course,
> this abstraction could be implemented in a lot of ways - add the
> "common" api to all UI elements, create wrappers, etc.  But the
> key is the separation of application intention from UI implemenation
> (which is what i was getting at).

Sure.  But this has nothing to do (AFAICT) with using named tags for
elements.  In the example above, the text field could have its
"highlighted"  property linked on creation to a
#textFieldShouldHighlight
method.  What I've learned (slowly - earlier versions of Seaside worked
much like you describe) is that it's almost always more flexible and
certainly more efficient to use the late binding mechanism built into
Smalltalk - the message send - rather than to constantly invent new
ones.
Exactly how you apply this piece of advice differs from situation to
situation, but it invariably leads to a better design in the long
run, IMO.

> Be happy to - i'll clean it up a bit first ;-)  I'm not really happy
> about how i had to hook into the system to get the information, so an
> suggestions are welcome.  Also, i just threw some ideas into it in terms
> of how to capture information, how long to hold on to it, etc. So again,
> feedback always good.

Great, I look forward to seeing it.

By the way, why isn't this dicussion taking place on the Seaside list?
There might well be some good comments from others as well.

Avi