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

[Paul Boddie]

Stephen Tyler <nntp at ebusinessresults.com.au> wrote in message news:<3d21259f$0$28006$afc38c87 at news.optusnet.com.au>...
> 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.

Indeed. But the involvement of many different parties is, in my view,
a strong argument for simplified template systems which can be
"round-trip" edited in WYSIWYG HTML editors, for example. My
justification for this is that otherwise a larger workload may be
placed on the person who has to integrate design changes into the
system.

[Python-HTML-other triangle]

> 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.

That's why there's a strong argument for implementing template systems
which are not programming languages - wholly declarative template
notations, for example. Whilst such notations cannot express
complicated dynamic layout, one can always use a layered approach: one
layer builds the forms, another does the fancy colouring, etc.

> 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).

No, but HTML is a standard on the Web...

> 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)

The biggest challenge in terms of code reuse is arguably where
validation of data is performed. One problem with markup reuse (as
typically implemented in template systems) is the lack of support for
"includes" in various editing tools, as far as I am aware. Thus,
previewing of templates is fairly impaired in many tools, although I'm
sure that some of them are starting to deal with this.

> - Authorisation and security

The standard authentication mechanism in J2EE, for example, is
interesting because the process of authentication is transparent to
the application - it is the application server which prompts the user
for their details, even using a Web page. An authorisation scheme can
be more complicated to design unless it is deliberately kept simple.

> - 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)

I agree with you on the issue of forms, in the sense that form fields
should be consistent with the underlying schema, but tables, lists and
trees all reduce to the same general case. The big question is: how do
you allow someone to edit these objects using a tool giving a more
sophisticated representation than a text editor (or uninspired XML
tree editor)?

> - 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)

Again, this would be great if one could retain a WYSIWYG HTML editor.

> - 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?)

Well, it would be nice to hear the best practices in this area - how
to develop, test and deploy Web applications using CVS, perhaps.

> 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:

In that you often need to build the form fields manually, and don't
have many possibilities for automatic verification/synchronisation of
those fields against the database?

[Access, validation]

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

This is something that a general mechanism can be very helpful with.
Manually coding error checking in both the Python code and the
template can be extremely tedious.

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

Indeed. It's dubious to say that "we log all errors" - who actually
reads the log unless the whole system is down?

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

With different templates? Let's say you have a US site and a British
site: "Not many spelling differences there," one may think, until one
realises that the very nature of the user interface could be different
- different information, legal terms, presentation style, and so on,
could all apply.

> - 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?

I personally wouldn't look to a templating system to generate SQL
queries - that's why we have multi-layered architectures, in my
opinion.

> - 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?

Again, it's arguably best to introduce another layer.

> 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.

I'll agree with this assessment in principle. I'll also claim that
complicated forms can be a nightmare to implement without specific
assistance from the Web development framework in the areas of
validation and presentation/templating.

[...]

> 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.

XSLT is (arguably) not easily previewed - at least not in the sense
that one can take an XSL document on its own and say that the final
output "will look something like this". In contrast Zope Page
Templates is designed to make sense in its "uninstantiated" state.

> 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.

My advice would be to not rely on a single specific technology to do
everything from Web serving to database management, and to expect to
combine frameworks with other projects to solve these kinds of
problems.

Paul