[Seaside] Hopelessly stupid newbie question

[Nevin Pratt]

Avi Bryant wrote:

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

I'm not sure there is a universally accepted definition of "template 
engine", but the way Seaside allows you to programmatically generate 
HTML without having to explicitly write every little piece of HTML 
myself qualifies it as a programmatic "template engine" in my book.  I'm 
really not sure how else to describe this part of Seaside.

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

Yes.  That's part of why direct HTML programming is so clumsy.  But I 
think even when dealing with fragments as you describe, I'm sure you 
find yourself in situations where the fragments are attempted to be put 
together in unforseen combinations, and it just doesn't work as well as 
you hoped (and the experience produces the next Seaside "enhancement" to 
deal with the shortcoming :-) ).

In short, browsers provide a fairly clutsy way to program GUI's, no 
matter how you do it.

Another approach I've played with is, of course, embedding a small 
amount of Smalltalk directly into the page (via SSP mechanisms)-- just 
enough Smalltalk to provide a hook between the Dreamweaver HTML file and 
the Smalltalk backend.  Buf I've found that doing this, I end up yanking 
a lot of the HTML out of the Dreamweaver file, and sucking it back into 
the image, just like Seaside has it, but without the benefit of the 
Seaside HTML building framework.  Not to mention the lack of a 
continuation-style architecture following these other approaches that 
Seaside gives you naturally.

In short, I can do web pages with just about any architecture the client 
wants.  And each architecture has it's advantages and disadvantages, 
including Seaside.  But like I said, I'm finding the Seaside 
architecture to be more and more interesting all the time.

So, back to Randy (and anybody else reading this), don't brush Seaside 
off because it doesn't fit your preconceived ideas of what you want. 
 Look deeper at it-- in the long run you may be glad you did.

Nevin