[Zope-dev] XHTML Templates comments from the peanut gallery

[Chris Withers]

(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