[Seaside] Hopelessly stupid newbie question

[Avi Bryant]

On Mon, 10 Mar 2003, Nevin Pratt wrote:

<snip>

> 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.

<snip>

> 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,

Great summary.  You analysis very closely mirrors my own experience - at
various times I've built frameworks that take each of the approaches you
describe, but since moving to purely programmatic HTML building, I've
found it to be a bigger win than I expected (I started down this road
partly out of laziness, not wanting to build another template system).
The ability to work in Smalltalk "all the way down" allows for a much
nicer workflow and greater flexibility to abstract and refactor the
patterns you would find yourself repeating over and over again in
something like Dreamweaver.

The other point to make here is that well-factored web applications don't
consist of monolithic pages but of compositions of many small elements.
If you really do this properly, a lot of your components won't even have
complete, well formed HTML - they might have rows but no table, for
example.  When you're dealing with fragments like that, WYSIWYG tools are
much less useful anyway.

Avi