[Seaside] Seaside Thoughts & Questions

[Daniel Drasin]

Subject:Re: Seaside - love it!
   Date:Sun, 27 Apr 2003 21:46:45 -0700 (PDT)
   From:Avi Bryant <avi at beta4.com>
     To:Daniel Drasin <dan at drasin.org>
    CC:julian at beta4.com


On Sun, 27 Apr 2003, Daniel Drasin wrote:

> Be happy to put them on the seaside lists - didn't know there was one.
> (link?)  Thanks for all your thoughtfull responses...

http://lists.squeakfoundation.org/listinfo/seaside

> The long a short is, i'm going to have a business
> problem to solve - and smalltalk is often not going to be part of that
> solution space.  So, since i can't have what i want, what can i get that
> contains some of the same benefits.  Hence Java - maybe .NET will fill
> that place eventually.

Sure, fair enough.  I've made a conscious effort to stay away from such
constraints, and I've been surprised at how successful that has been -
90%
of my work is done in Squeak.  The thing with the other 10% is that it's
in environments so restrictive, even if I did have a Java-based
framework,
I probably wouldn't be able to use it unless I disguised it as a library
for Struts or something.

But my situation is fairly different from that of most developers.

> I think that if this approach was available to Java developers, the
> productivity boosts would eventually get noticed and there would be a
> signifant user community.

I don't doubt that you're right.  I'm also pretty sure that I'm not the
right person to push such a project, except maybe in a broad advisory
role
- life is too short to spend it writing Java.  But if you want to start
the ball rolling and write the bulk of the code, I'll be the first to
sign
up to the mailing list.  I would find it an interesting design challenge
to try to keep the framework clean and usable given the onerous
constraints of the language (rule #1 - no XML config files).

> So that if a user goes back to a page and tries to proceed from there, i
> want my application to respond differently that when they were on the
> page to begin with (the trivial case is to expire that page and say
> 'sorry', but you can handle it much more gracefully if you want - unwind
> all state changes and go on as the user requests.)

Sure.  In Seaside, the back button is *highly* mediated by the
application.  You can mark any piece of state as being "backtrackable",
so
that it will get unwound as you describe above.  You can use the
#isolate:
method to expire pages when the user passes a checkpoint, to avoid the
doubly-charged credit card problem.  It's very easy to introduce new,
similar constructs (Seaside 2.3 adds the #once: method, which ensures
that
each of a set of pages can only be viewed a single time).

> Does that make sense?  I'm not saying get rid of the back button
> functionality, i'm just saying get rid of the  way that web apps
> implement it which are disasters waiting to happen.

But in Java, to implement Seaside-like control flow, you would *need* to
get rid of it entirely.  And that's what I'm bemoaning.

> Definately true on the debugging.  But if you're in the java world,
> that's life.  Large ant (read "make") scripts are the norm, so adding
> one more line would be business as usual for java programmers.

Oh, I agree that Java developers have extremely low standards...

> I've found that removing sharp edges is an important part of having
> a framework.  But there's more to it than that.  The design i was
> suggesting takes the binding out of code (embedded in the method
> call in the context) and puts it into data (in a binding object).
> Good pattern in general, but in this particular case its particularly
> important because it can be introspected.  It's really just the
> Builder pattern in the end (which i've generally found preferable to
> using straight code commands).

Introspection is a good point.  Actually I was just having that
discussion
today with someone building a testing framework for Seaside - they've
moved to using MessageSends for callbacks so they can find out
programmatically what selector an individual element is bound to.  I
responded by writing a #selectorsSent method for BlockContext, but I
realize that this is not an ideal solution ;).

Unfortunately I don't have any decent, lightweight syntax for
constructing
a MessageSend that reads as well as a block.  If you have any
suggestions
let me know.

I still maintain that using selectors rather than textual tags is
preferable, but that's a minor quibble.

Avi
-- 
	Daniel Drasin				
	dan at drasin.org				8612 Long Meadow Ct.
	(410)-461-6168				Columbia, MD, 21045