[Zope3-Users] emacs with metal and tal namespaces

[Fred Drake]

On 10/29/06, Perry Smith <pedz at easesoftware.com> wrote:
> I bumped into two problems that stumped me.  First, it is general practice
> to do:
>
> <metal:arbitrary_tag define-macro="page">

Constructs for this can be written in RELAX NG, but I've not tried
doing that myself though.  The Atom specification includes an example
for elements in the XHTML namespace.

> Second, metal and tal constructs are attributes that are placed inside any
> tag.
...
> So, to really do this properly, each schema that the tal or metal are going
> to be used in would need to be modified to allow the tal and metal
> attributes.  The RNC syntax does have a funny include construct that allows
> overriding constructs that are defined in the included file.  But, that only
> means that it would be possible to create a maintenance nightmare if someone
> wanted to do that.

Almost; it really depends on the how the base schemas are written.
They can be written to cooperate with extending or specializing
schemas.  There are examples in the RELAX NG tutorials.  It does
require that the base schemas be written with that expectation, just
like classes need to be written to expect subclassing.

> Which is probably a good idea anyhow.  Maybe the first example is frowned
> upon.  I got it from various tutorials.  But, as we can see, the namespace
> of metal and tal is never defined in the examples that I've been looking at.

That's definately a good idea to do anyway.

The TAL parser has two modes: HTML, and XML.  The HTML mode just
assumes the namespace declarations for tal:, metal:, and i18n:, though
it will honor declarations within the document properly.  The XML mode
makes no assumptions about the namespaces and requires proper
declarations in the templates.  It's unfortunate that triggering the
right mode is still a bit of black magic.  :-(

The fdrake-anguenot_better_xml_support_for_pt branch of Zope 3
includes a couple of different features.  The first is a unification
of the HTML and XML modes, so that input is always process as
XML/XHTML, and output can be generated for HTML, XHTML, or general
XML; that's not complete.  The second is some improved encoding and
mode detection support that Julien wrote after we'd discussed
approaches.  One of our ideas was to introduce a .xpt extension for
templates present on the filesystem that always triggered the
XHTML/XML mode.  Perhaps it would be worth pulling that feature out
and adding it on the trunk.


  -Fred

-- 
Fred L. Drake, Jr.    <fdrake at gmail.com>
"Every sin is the result of a collaboration." --Lucius Annaeus Seneca