durusmail: quixote-users: Quixote with ZPT?
Quixote with ZPT?
2002-11-05
2002-11-06
2002-11-06
This is why Quixote appeals to me (was: Quixote with ZPT?)
2002-11-06
This is why Quixote appeals to me (was: Quixote with ZPT?)
This is why Quixote appeals to me (was: Quixote with ZPT?)
2002-11-06
This is why Quixote appeals to me
2002-11-06
2002-11-11
Quixote with ZPT?
Bud P. Bruegger
2002-11-06
I've always thought it was a nice idea of separating design and development.
But since I've worked on project that used designers without a clean
separation, I know it's a life saver!

There are other approaches to separation besides ZTP.  One--and I believe the
first ever--is Enhydra's XMLC (http://xmlc.enhydra.org/index.html).  It is
written in Java (and people use it from Jython it seems).  The concept is to
use id attributes in the html/xml document from the designer and use XMLC to
compile it to a (java) class that builds a DOM of the document with special
accessor methods where elements had id attributes.  Designer tools seem to
leave the id attributes alone (as they leave the attribute language used in ZTP
alone).  Developers use DOM methods to manipulate the DOM, substituting element
contents, etc.

It seems that also Twisted uses a similar approach with its DOM Templates
(http://www.twistedmatrix.com/documents/howto/domtemplate).  That is in Python
but I don't know how easy it is to use outside Twisted (????).

It may be easy to implement a poor man's XMLC in Python by simply parsing a
document to a DOM and pickling it for later use.  This gives you standard DOM
methods for modifying the DOM before writing it out as response.  Some optional
add-ons would be to use tidy before building the DOM
(http://www.lemburg.com/files/python/mxTidy.html) as does XMLC.  Also you could
write a simple wrapper on top of the DOM to make the most used modification
tasks easier and more Pythonic.  Finally, you could have a simple run-time
method to chose one of the pickled DOMs based on preferences (language, style,
etc.).

A shortcoming of this and all DOM-based methods (and I believe also ZTP?) is in
the granularity;  I don't believe it is the page (document) that should be the
object of design but rather a page fragment (DOM fragment) that I normally call
widget.  These are parts like headers, footers, titles, nav bars, form
elements, etc. that are typically reused on multiple pages.  I haven't yet
looked into how easy it would be to pickle DOM fragments instead of a complete
DOM.

I have put quite some thought into these matters, wanting to implement database
widgets for quixote that have a data binding and a pluggable rendering with
clean separation of design.  But haven't had the time to implement anything
yet.

cheers
--bud

reply