[ZPT] Web Design with ZPT

[Joel Burton]

On Sat, 2 Mar 2002, Joseph Griffin wrote:

> Thanks again for the response Joel,
> My background has been mostly with Microsoft. When I ran across Zope, I was
> truly impressed with the idea of an object oriented website. Since it's
> free, it's gets double bonus points from me. What I have learned in software
> development is that the pros (that is, those persons whose sole interest is
> making money) go 10 miles out of their way to streamline their efforts into
> a boring repeatable pattern than lowers overall risk. Zope, in my opinon, is
> ripe for a deployment tool in the form of a database/python/ZPT script
> generator. This assumes that the Zope/ZServer/ZODB etc... has stable
> interfaces. After all, Zope is database friendly, so once a datamodel is
> defined, you could build the initial Zope website from the data model along
> (something like Znolk, but on a much larger scale). Database scripts would
> build the tables, python scripts could do the framework installation and ZPT
> would present the data. The whole install could be automated to the point of
> establishing a complete web layout is less than a week. This type of code
> generation has been done by Promatix for Visual FoxPro (www.promatrix.com),
> Microsoft Access,SQL Server,Oracle,Sybase, and DB2 using VBExpress
> (www.vbexpress.com).
>
> To make the whole thing platform compatiable, write it in Javascript using a
> browser as GUI and XML as a database. Do you think other people would be
> interested in doing something like this? Obviously there is a thousand
> issues to resolve, but if you want to make Bill Gates the 2nd richest man in
> America, web applications are probably the future in software development.
> Joseph

That's a tall order from where Zope is, but I think there are pieces we
can learn from this that could be closer.

Here in Zopeland, we have an excellent toolkit for building websites, but
not much middle-ground for common representation of information. For
example, acl_user user objects have only a username, roles, and password;
there is no way to store real names, preferences, etc. There are add-on
products in Zope for this (exUserFolder, etc.), but none are in the core
or so widespread that you can count on anyone else using them if you're a
product developer. Therefore, few other products can rely on them. This is
negative in many ways because it means that less products are available
out-of-the-box with hooks for this type of information.

I wrote a simple product last week to encapsulate offsite links. Rather
than just hardcoding <a> tags in the html of our pages, we point to a
WebLink object. This object has basic properties (description, url,
expiration_date, etc.), and can be configured site-wide to use a frame
"return-to-site" launch or a regular just-link-there redirect. Part of the
product is the ability to send an email message to the owner of the link
letting them know that the link is dead. I can do this because I know how
to get the email address of the user (in my case, through the kickass
product exUserFolder). However, there's no API to get-user-email (even in
exUserFolder), so there's no way for me to write this as a reusable idea
without someone having to edit configuration information to have this work
in their site.

There's no standard name for a mailhost object. There's no standard name
for ZPT template (though I suspect that standard_template.pt will pick up
from being the 2.5 default). Flexibility is good, but an API for these
things would help us re-use and share tools to build faster sites.

It's hard to fix these problems in a way that makes everyone hapyp.
People's needs and preferences vary. ZC controls (to some degree) what
goes in the core Zope. Perhaps there might be some value in having a group
(like the Zope Documentation Project) start to sketch out recommended
higher-level site APIs (like current user email address (if known),
standard name for mailhost object, etc.) Many sites couldn't use all of
this, but many sites could and might be easier to share work and share
implementors if they did.

CMF might help some of this; it provides names for Dublin Core properties
and such that will become pseudostandards in the Zope world. Is it
worthwhile asking ourselves if there are other APIs we can agree on?

-- 

Joel BURTON  |  joel@joelburton.com  |  joelburton.com  |  aim: wjoelburton
Independent Knowledge Management Consultant