(sorry I'm so late on this, things have been hectic :-( ) Paul Everitt wrote:
o Allow those presentation tools to work by having well-formed markup (e.g. no separation into header and footer)
Hmmm... I wonder how refactoring, which _header and _footer were really useful for, will happen now...
o Match the appropriate level of capability currently in DTML usage
That's interesting. I see a lot of DTML's problems being caused because it is 'overcapable'...
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 separation into header and footer).
...still not sure what this means
The new presentation architecture should match the appropriate level of capability currently in DTML usage. For instance, common idioms like browse-by-batch should be possible.
...that's going to be a fine line to tread :-S
Site Designers want simple reuse of content within reach of standard tools. For instance, the Site Designer wants a standard copyright "asset" on the bottom of every page.
How does this fit with the "no separation into header and footer" thing?
The presentation architecture should not know about the details of the data tier or the logic tier. Rather, the presentation architecture will just provide a view onto the model expressed in the object system, where the model uses standard APIs.
...not 100% on what that means...
A **page** is the result of applying presentation to data in the object system. A page is a particular result of a URL when viewed under certain conditions.
...I'd like to add to this: components used to make up 'page's should not be URL-visible. Why should they be? (would this raise issues with XML-RPC?)
Ultimately, data such as documents will be matched to a presentation according to implicit and explicit rules. The simple case will be simple (invisible); the complex, custom cases will be straightforward. In the initial rev of the architecture, only one presentation will be implicit for a resource. Other presentations of that resource will require explicit traversal to obtain them.
...that's a little unclear :-S
Site Designers will create XHTML Template objects that control
Where can I find out more about XHTML?
XHTML Templates will be complete, well-formed HTML that look like a resource will look when the XHTML Template is applied to it. There will be no "source vs. rendered" issue.
Does this mean the 'rendered' stuff could be considered 'bloated' as it contains stuff only needed for what would have been the 'source' editing mode?
The connectors will allow different "modes" that provide the alternation and conditional facilities present in DTML. These modes are just simple attributes to extend the semantics of existing XHTML tags.
This sounds interesting...
The XHTML Template architecture will facilitate re-use by allowing blocks in the XHTML Template to be named as a (component/library/asset) block. As the Site Designer authors and updates the block of XHTML, Zope saves the named block as a separate object in Zope. This named object can then be used in other XHTML Templates.
...that was confusing...
DTML has permitted the rendering on non-markup such as SMTP messages. The XHTML Template does not try to satisfy this job. Other objects, such as DTML Methods or Python Methods, would have to handle this chore.
:-( (but I can see why it has to be so...)
Clarifying the "DTML namespace" confusion felt by authors is not in the scope of this proposal.
Is it being covered anywhere else?
*Replacing magic with magic*. If too much magical stuff happens (e.g. how data gets implicitly bound in different ways to presentation, the component idea creating new stuff in the background) for people to handle, we're just replacing the confusing old magic with the confusing new magic.
Hmmm.... Well, sorry for being so late on this. I hope I haven't made too many comments that other people have already. The proposal looks really cool and should hopefully take a lot of the pain out of developing the presentation layer in Zope... cheers, Chris