[Zope-ZEO] Advice

[Toby Dickenson]

On Thu, 21 Sep 2000 10:20:53 -0400, Greg Ward
<gward@mems-exchange.org> wrote:

>Andrew experimented with
>writing Products and didn't like what he found;

From what I understand about what you are doing, a Python Product
(with code in CVS, and no <textarea>) sounds like it would have been
the best route. It solves all but one of the problems you list.

>  * procedural abstraction is painful, part 2: procedures (DTML methods)
>    don't have formal parameters, they just happen to inherit whatever
>    namespace they were called from.  Yikes!  This is like Perl, only
>    worse; at least with Perl, you *can* have lexically-scoped
>    variables.

DTML is good for *Document* *Templates*, but it does gets used for
many thing beyond that where it is not so suitable.

Ive lost many hours sleep over the parameter passing / namspace issue
too. The problem is not quite so bad if you are developing a Python
Product since the real logic can go in python functions.

>Where a Zope URL traverses Zope's database-of-code-objects, a Quixote
>URL traverses Python's namespace hierarchy.  Eg. in the code I'm hacking
>on today, the URL /q/user/login (I'm leaving of "http://" and the
>hostname, of course) resolves to the callable Python object
>"mems.ui.user.login".  (Our Quixote config file establishes that the
>"/q/" URL maps to the Python namespace "mems.ui".)
>
>Through a bit of aliasing in mems/ui/user/login/__init__.py, that
>callable object is a function:
>
>    def login (request, response):
>
>which generates and/or processes a user login form.

To a Zope developer I think this approach is all too familar.
ZPublisher as used in Zope usually traverses a namespace made up of
class instances (most, but not all stored in ZODB) but it can traverse
modules and submodules equally easily. As I understand it, this aspect
of Quixote is a pure subset of ZPublishers capabilities.

>Ultimately, this comes down to another callable Python object, which is
>written in a Python dialect called PTL (Python Template Language).  A
>simple example:

PTL is a different animal altogether. I have recently had alot of
success converting the presentation logic of my Zope application to
using PTL.

Previously some of this logic was in DTML, but creeping complexity of
the logic quickly makes this unwieldy. If the logic is simple then to
my eyes DTML is still a better choice. Here is a dtml equivalent of
Greg's PTL example:

	login_form=HTML("""
<dtml-var "standard_html_header(None,_,title='Login to the MEMS
Exchange')">
<form method="POST" action="login">
User ID: <input type=text name=user_id size=20
                value="<dtml-var userid html_quote>"><br>
Password: <input type=password name=password size=20><br>
<input type=submit name=login value="Login">
</form>
<dtml-var standard_html_footer>
""")

Using the DTML namespace requires the ugly None,_ however note that
handling the userid parameter is easier because of it.

The traditional answer to creeping complexity in DTML is to switch it
to python code. I see PTL as an evolution of this step..... if the
sole purpose of the function is to assemble a string, then you can
improve readability by not having to worry about exactly *how* the
string gets assembled, allowing you to focus on *what* gets assembled.

of course this is nothing to do with zeo......




Toby Dickenson
tdickenson@geminidataloggers.com