[Seaside] presentation/logic separation XMLC style (Was Re: Hopelessly stupid newbie question)

[Brian Zhou]

Allow me to offer one more approach - the approach XMLC
http://xmlc.enhydra.org has taken. Basically,

 * designer works on L&F using HTML WYSIWYG editor and provides template
pages in pure HTML
 * developer/designer adds non-invasive tags (DIV, SPAN) and attributes (id)
to identify elements
 * the HTML pages containing templates are then compiled into java classes
representing DOM tree. For performance reasons, the DOM tree can be a lazy
tree - only the dynamic parts are in real DOM format
 * developer writes program in a way to manipulate the DOM tree with
standard XML DOM API
 * at runtime, the servlet serves HTML text converted back from DOM tree.

Please don't dismiss the idea simply because the current implementation is
in Java. Personally I think it's a neat idea comparing with ASP/JSP/SSP/PHP:
the content and logic separation is as clean as you can get, you can change
code and page independent of each other. The major serious downside - it's
in Java!

 * You cannot have Seaside continuation style framework.
 * Each time the template pages change, you have to stop the server and
recompile. The Java classloader does not like dynamic changes of classes.
Auto-compilation often is broken.
 * To manipulate DOM in Java and recompile the program is a pain. I'd say
DOM manipulation itself is not that difficult, people do client-side DOM
manipulation in Javascript all the time.

Of course you need to make sure the tags and attributes are consistent with
those referenced in the code.

Why am I writing this? I think if we have a WebDAV daemon in Squeak, we have
a winner here. The WebDAV daemon will be responsible for managing the
templates, versioning and auto-compilation. We can even check the
consistence between template and code! I assume there're already DOM
manipulation classes in Squeak.

This probably is overkill for lots of small projects, embedded HTML or
HtmlRenderer might work just fine in those cases. But I do think the
approach is ideal for enterprise web app. You can still abstract and
refactor as much as you like on the side of DOM manipulation code. Later
version of the Zope template markup is actually influenced by XMLC, but they
need to add non-standard attributes IIRC, not as nice as the original XMLC.

What do you guys think?

-Brian

----- Original Message -----
From: "Nevin Pratt" <nevin at smalltalkpro.com>
To: "The Squeak Enterprise Aubergines Server - general discussion."
<seaside at lists.squeakfoundation.org>
Sent: Monday, March 10, 2003 1:45 PM
Subject: Re: [Seaside] Hopelessly stupid newbie question


>
>
> 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
>
>
> _______________________________________________
> Seaside mailing list
> Seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/listinfo/seaside
>