Howdy folks. As advertised in my last email, below is our Fishbowl
Proposal on a new template architecture. Some notes:
1) This mostly replaces DTML. As mentioned, the goal isn't necessarily
to get DTML removed from Zope. Rather, most of the audience will see it
little or none of the time.
2) This proposal has gotten more internal DC scrutiny from a
requirements perspective than anything we've done. The proposal has
been rewritten four times.
3) The original version of this forced the connection between
reinventing the data tier (documents) and the presentation tier
(templates/pages/stylesheets). We eventually found the way to decouple
the connection, but we still need to write a documents proposal.
4) What this really, really needs right now is extensive user
documentation with screenshots written *before* the software. This is
where we got stuck. Docs are the fastest way to confront the myriad of
usage details.
5) Our proposal is a little more ambitious than HiperDOM (we have a
concept of "components" that are hinted to but not explained). But for
now, HiperDOM is a good basis for exploring XHTML Templates.
6) I'm still not convinced template is the right word. Unfortunately
I'm less convinced at any alternatives. Whatever is chosen, it must
feel "normal" to the vast majority of the audience.
Cheers!
--Paul
XHTML Template Architecture
Zope should increase usability and promote separation of tiers by
moving to a presentation and data architecture. Site Designers will
author and round-trip presentation objects in familiar tools.
Combined with the Document Architecture, this proposal establishes
the fundamental content and presentation architecture for Zope.
Note on status
The great folks at Hiperglocia have already produced something quite
similar to what is discussed here. Their Zope product is called
"HiperDOM", http://www.zope.org/Members/lalo/HiperDOM/.
Note On Jargon
The choice of term for the presentation object has been contentious.
Right now the list of choices include: template, view, page, or
stylesheet. This proposal doesn't make the decision on the jargon.
Rather, the tier is usually refered to as the presentation. When a
choice has to be made, such as the Architecture section, Template is
used as the temporary choice.
Problem
Zope currently has a model of DTML Documents and DTML Methods as the
basic data and presentation tiers. However, this model is
confusing, doesn't promote separation of tiers, and doesn't work
with popular web design/authoring tools.
For the presentation tier, Site Designers are faced with an idiom in
which well-formed HTML is split between two "files"
(standard_html_header and standard_html_footer). Also, the
presentation mockups are "taken away" by programmers who insert a
bunch of alien tags that don't present anything on the screen of the
web design tool.
Worse, DTML is fundamentally impossible to edit directly by classic
tools due to the "source vs. rendered" issue. That is, when a Site
Designer wants to edit a piece of DTML, they will get the *rendered*
version of the DTML for editing, where all the DTML tags are
expanded into HTML.
In summary, there is a tremendous usability issue, both conceptual
and in practice.
There are additional problems:
o DTML is considered a "proprietary" language
o Data needs to have different presentations used under different
conditions
o Consulting practices need a way for customers to start seeing
screen results immediately without having the programmer "steal"
the templates by converting them to something alien
Goals
The goals of the Presentation Architecture are:
o Clear separation of presentation, data, and logic with clear
concepts in Zope for these tiers and audiences
o Increase usability by allowing round trip presentation with
common tools and familiar concepts
o Allow those presentation tools to work by having well-formed
markup (e.g. no separation into header and footer)
o Supplant "proprietary" markup language (DTML) in presentation
tier by leveraging standards (XHTML) (Note: "eliminate" isn't the
target as it might not be feasible in 100% of the cases)
o Match the appropriate level of capability currently in DTML
usage
o Simple presentation reuse within reach of standard tools
Solution
Zope should move to an architecture with clear separation of
presentation, data, and logic, with clear concepts in Zope for these
tiers and audiences.
The presentation tier will get a tremendous usability increase by
allowing round trip presentation with common tools. This also
ensures that Site Designers finish with the same stuff they started
with, meaning the programmers don't come in and cast their work into
"code".
The architecture should make sure those presentation tools are
effective by having well-formed markup (e.g. no se
