squeakdot and seaside

Avi Bryant avi at beta4.com
Wed Jan 30 19:00:56 UTC 2002


Cees writes:

>>Ok, sounds good. In this respect our two frameworks both still suffers
>>slightly from the fact that we need to synch the ids in the HTML with
>>the code. Info in two places.  I wonder how this could be even more
>>improved...
>
>The only other thing is to use an XPath-like specification
>on the .Smalltalk side, methinks. Whether you want *that*...

No, that would still have it in two places - the instvar/method itself and
wherever the XPath is linked to it.  But this would likely be worse,
since realistically you duplicate the name a third place - in the unique
id of the html element so that the XPath can find it, which will probably
be the same name anyway.  Of course, you could have a default XPath that
made that assumption, but then you're in the identical situation to my
default bindings.

I don't actually think this is a big deal - you always have method
definitions and method sends.  Is it duplication that the method name
appears in both?  If two pieces of code are communicating they're going to
have share some piece of info, after all.

>>> I don't think of it as hiding the http flow - who *cares* about the
>>>http flow?
>>
>>Well, I do! :-) What I meant is that I have been burnt
>>earlier by 4GL tools, complicated frameworks etc. that tries to hide too
>>much and thus only "trips me up" because it does a lot of smart things
>>behind my back. It all depends of course on how good it's implemented.
>
>Yup. For example, using VisualWorks' VisualWave is tempting (Wave is a
>toolkit that renders Smalltalk UI's to HTML with a lot of javascript and
>server-side wizardry around it to fool the programmer into thinking that
>they're writing a native Smalltalk UI program), but it integrates badly
>with lower-level stuff (like their own Servlet/SSP framework - go
>figure). In effect, you're left with a big black box and your application
>will be able to do just what the Wave designers could think of (or, more
>likely, had the time for to write it).

The difference is, IOWA/SEASIDE is not trying to squeeze an API designed
for desktop apps into a web context, it was designed for web apps from
the start.  This means that
 - it doesn't rely on javascript tricks; it works just fine with JS
(and cookies) disabled
 - it coexists very happily with realities of the web like the back and
reload buttons (whereas VisualWave gets very confused by them)
 - the HTML it generates is, modulo a little url mangling, exactly the
HTML you give it; you have complete control over what the app looks like
 - you can get as close to the metal as you want - if you want to throw
away all the cool stuff and just use it as a servlet system, go ahead.
Not sure why you'd bother, but it's easy to do.

>OTOH, the design seems to have been inspired by WebObjects and I only
>heard good stuff about it...

Yes, WebObjects is very nice.  Some of the problems of WO that we tried to
address are:
 - WebObjects html templates don't use normal HTML tags for dynamic
elements; instead you end ypu with an html file that looks like
<webobject><webobject></webobject><webobject></webobject>... which means
your forced to use their WYSIWYG HTML editor whether you want to or not
 - WebObjects has a similar bindings system, but no defaults - so you have
to specify even obvious bindings explicitly.  Also, the bindings have a
special syntax rather than being specified programatically, which makes
them less flexible.
 - Lack of continuations/coroutines means no fun control-flow games.  This
leads to very different application designs (without them, webapps are all
GOTO... perhaps I should write a paper called "HTTP GET considered
harmful...")
 - Java! At least it used to be Objective-C...

Avi




More information about the Squeak-dev mailing list