Web templating/db tool with best designer/coder separation?

[Stephen Tyler]

Bengt Richter wrote:

> E.g., if you were hoping for an improvement over current practice,
> which do you consider to be the tool(s) to beat, and what would
> the killer improvement(s) be? TIA.

Well, there are more parties involved than just designer and coder.  What 
about content providers (authors, illustrators), database administrators 
and management (project managers etc).  They also play an important role, 
and their productivity is affected by the choice of web templating/db 
tools.

Most of the web templating debate focuses on the separation (or otherwise) 
of the programming code (python) and the markup code (HTML).  Most 
solutions are variants of:

Python code ----- New programming language
   \                    /
    \                  /
            HTML
[That is meant to be a triangle]

where "New programming language" is some kind of intermediate execution 
model (loops, conditionals) that is supposedly easier for non-coders to 
embed (or leave alone) in their HTML.

A simple "include" mechanism whould be on the Python-HTML axis, very close 
to the HTML end.

Echo statements in Python is a point very close to "Python code".

And most of the web templating solutions trend towards either defining a new 
programming language, or a way to embed Python in HTML.


But, as the new programming language becomes more expressive, it tends to 
become yet-another-PHP, and becomes yet another thing to mystify the 
non-coders, and another way to write obfuscated code for the coders.

Code should be written in an efficient code for coding (eg Python).  And 
likewise for the other elements (but I will stop short of saying that HTML 
is an efficient code for markup).

In my view, the next generation of web templating/db tool needs to move 
beyond the issue of python/HTML separation and start solving some higher 
level issues:

- Reuse (both of code, markup and content)

- Authorisation and security

- Higher level structures (forms, tables, lists, trees, navigation should be 
handled and manipulated at an abstract level, rather than as a mess of HTML 
markup)

- Consistency and style (the "style" of the site should be able to be 
changed across an entire site by making small changes to a small number of 
items in a small number of places - and my definition of style is much 
broader than just CSS)

- Configuration management (Can we revert to the previous version if the 
change is not working properly?  Can we test the new version on particular 
users (or classes or users) before fully commiting to the new version?  Can 
we track changes to the system?)


Just take the example of form handling:

You have certains fields in certain tables in your database.  And you want 
the user to be able to change those fields.  This is a pretty simple 
requirement, yet the solution in most web templating systems is pretty 
complex:

- is the user authorised to view, change, or create this record?

- how do we verify the integrity of the user input for each of these fields?  
For things like range checks, to date validation, email validation and 
dependencies on other fields.

- how do we notify the user of errors in user input?

- how do we notify the user of errors in authorisation?

- how do we notify the web administrator of errors?

- how do we label these fields?  If the label needs to be changed or 
localised, where do we make those changes?

- how do we access these fields?  Do we have to write an SQL query for this 
(and every other) data access?  Or can the templating system generate the 
appropriate efficient SQL query?

- How do we save the results back to the database?  How do we cope with 
results spread across different tables?  Can the templating system generate 
the appropriate efficient SQL query?  What about transactions?

Now in my view, all the templating systems I have seen turn this "simple" 
exercise into a fairly complex code.  And 99% of the time, the 
implementations of this code ignore several important steps in the process.  
And 99% of the time, the code has to be reimplemented for every new form 
that is required.


In my view, Zope (with suitable add-ons) comes closest to meeting these 
goals.  But it is not without its problems:

- It has strong links to a non-standard database.  Support for commonly 
deployed enterprise databases (Oracle et al) is relatively weak (but that 
is not to say that it is strong in other python-based systems)

- It has a version control system, but this is not well integrated with 
other version control systems (eg CVS)

- It is difficult to integrate with non-Zope workflow processes usable by 
non-coders

- Zope also strongly influences the http-server choices, yet it is not 
clearly superior to other http-server alternatives.

- Zope has a mean learning curve.  You can't just walk up to it and become 
productive from day one.  You need good documentation and examples (which 
used to be very difficult to find).


The other contenders for my "next-generation" web templating system 
typically use XSLT to transform a variety of XML inputs into XHTML output.  
But XSLT can be very obtuse for non-coders (and even coders).  And it still 
needs to be supplemented with a general-purpose programming language.


For my own code, I have developed a number of libraries over the years to 
solve these problems.  But they have all fallen somewhat short of my goals 
in one or more ways (too complex, too specific, inefficient, obtuse or 
missing functionality).  But I keep trying.

Good luck in your search,

Stephen Tyler
www.ebusinessresults.com.au