[Seaside] Hopelessly stupid newbie question

[Nevin Pratt]

A bunch of the conversation clipped, and then Nevin wrote:

>
> As I see it, Seaside allows you to build web apps in the same style as 
> classic client/server apps (like you would do with the Canvas tool in 
> VW, or WindowBuilder in VA, etc.), but with one glaring exception: 
> Seaside doesn't easily accommodate a GUI-painter.
>
> Sounds like he wants both of those (client/server style web 
> development, like Seaside can do, plus a GUI painter).
>
> I don't think he wants just cgi-style web apps to a Comanche module.
>
> In an earlier version of Seaside, I experimented with using 
> Dreamweaver as the GUI-painter, and then wiring those screens into 
> Seaside afterwards.  I actually had something that seemed to work OK, 
> but have no idea how easy it would be to get it working in Seaside 
> 2.x.  Plus, I never documented it.
>
> Nevin
>


Then Randy Siler wrote:

> Yes, you have it right. I do want to create the form with a wysiwyg 
> editor (GUI Painter) and have Seaside process the form data. And to 
> some extent my first experiment did that, but when it came time to 
> return results to the user I realized I probably had to "code" it 
> rather than "paint" it.
>
> From the examples I've seen there is a real beauty to how clean that 
> Seaside 'coding' looks and I was attracted by that but my previous 
> experience has left me not wanting to code what I could paint. But 
> perhaps with a little more experience I could overcome that.
>
> Randy


Randy,

As I mentioned, I've been playing around with using Dreamweaver as a 
WYSIWYG screen painter tied to Squeak Comanche, both with and without 
Seaside.  Here are a few of my observations:

First, using Dreamweaver (or FrontPage, or whatever) as the GUI 
painteris certainly doable. But when doing this, the code on the 
back-end has a distinct (and clumsy) CGI feel to it.  It's also very 
easy to end up with CGI-code sphagetti and many "special case" CGI code 
situations.  To alleviate the "special case" code situations, I found 
myself slowly gravitating to a normalized "works for everything" style 
of architecture.  That architecture is very much like the classic 
client/server architectures, where a given screen is "installed" on a 
given class.  Note the similarity between this and the way you paint a 
GUI with VisualWorks, and then install the GUI on a class (usually a 
custom subclass of ApplicationModel).  The VA GUI builder does something 
similar, where you install on a custom subclass of AptBuilderView (or 
some name like that, I forget now).  VA with WindowBuilder likewise does 
something similar.  NeXT's Interface Builder likewise has you install a 
screen on what I used to call a "NIB Manager", but again it is the same 
concept.  In fact, installing a painted screen upon a custom object that 
has been built to handle just that particular screen seems to be a 
fairly universal paradigm for almost all GUI builders.

Anyway, if you do this for HTML-painted GUI's, you again would create a 
custom subclass whose job it is to handle the screen, and (usually) only 
that one screen.  That way, all of the screen code associated with that 
screen (i.e., the CGI scripts for supporting that screen) can be found 
on a class that handles that screen.  You can still create a class 
hierarchy of abstract superclasses that contain common code, and thus 
eliminate code duplication, so there is no need to duplicate common 
"CGI-scripts" (i.e., methods on the installed class) with every screen. 
 They can be factored out to common superclasses.

However, for your custom subclass, you now will often find yourself 
needing to "interact" with the screen in fairly ad-hoc ways, depending 
on the particular needs of that screen.  For example, you might want to 
reserve a status line where you write status information when the screen 
is drawn, or you might want to dynamically change the contents of a 
drop-down list, etc.  But, to do this, you now need some way to 
dynamically change the HTML output that was produced by your GUI 
painter.  There are a couple of approaches to do that:

You can parse the HTML output of your GUI painter at runtime, finding 
the appropriate tags within the text that you need to modify for each 
case, and then modify that text on the fly (this is a typical 
Pearl-style approach).

Or you can build a framework that "objectifies" the HTML contents, 
building objects from the HTML tags that it finds, so that you only have 
to send messages to, say, a status texfield, etc., and then ask the 
screen to re-render it's HTML when you are done modifying the screen 
contents.

The first approach is rather clumsy, but straight-forward for simple 
tasks, but can also get unmanageable as things grow.  It's not a 
particularly scalable approach, in my opinion.

The second approach is actually how tools like the VW canvas tool works. 
 Think of the HTML output as nothing more than "screen specifications". 
 The custom subclass that it is "installed" on would read those screen 
specifications from the external file, and then build various HTML 
objects from those specifications.  Then it provides hooks allowing you 
to send messages to those objects to dynamically change screen elements 
at runtime.  Then those HTML objects are finally asked to re-render 
themselves back out to HTML text.

As far as I know, there is currently nothing available for Squeak that 
follows this second approach.  You would have to write it yourself.

So, the first approach gets clumsy and unmanageable very fast, and the 
second approach you would have to write yourself.

But even then, I'm still not sure you would have something that was 
particularly desirable.  You would have something like VW and VA does, 
but it still suffers from a few drawbacks.

One of those drawbacks is: when I was doing such work with VW and VA, I 
*still* needed to put my HTML cap on, and think in HTML, and write HTML 
within the provided component framework.  Thus, I still had to switch 
back-and-forth mentally between HTML and Smalltalk.  Furthermore, I 
would lose the ability to do things like 'senders', 'implementors', 
etc., at the interface between the HTML and the Smalltalk, or even 
within the HTML code, because the HTML was external, in external files 
created by, say, Dreamweaver.  Plus, HTML is rather clumsy, and I would 
lose various abilities to refactor pieces of HTML code that we take for 
granted in the Smalltalk IDE.  I would also need to occasionally launch 
Dreamweaver and look at the screens, and modify the screen there.

All of this in effect creates a "two-IDE" split personality: one IDE for 
the HTML, and a separate IDE for the Smalltalk.  And for many tasks, the 
Smalltalk IDE is hands-down the most productive.  Not to mention 
criss-crossing between the chasms creates a good deal of code (and time) 
thrashing.

In other words, while the whole idea of using tools like Dreamweaver as 
a GUI painter sounds good on paper, I'm not sure it is what it's cracked 
up to be.  The native approach used by Seaside is looking more and more 
attractive to me all the time, where the HTML is written completely 
within the Smalltalk IDE via a quite sophisticated template engine, but 
it also has the ability to utilize external CSS files for use by the 
graphic designers.

Nevin