At 01:01 PM 1/15/99 +0000, Jim Fulton wrote:
We plan to support something like this in 1.10.
I was thinking of either:
- DTML Documents and - StructuredText Documents (that can use DTML)
or
- A single DTML document that has an option to process it's inoput through structured text when it is compiled.
Probably the second option is the way to go.
Opinions?
I would like the option *not* to use DTML. For example, I often find myself writing StructuredText Documents which use DTML examples, but do not want to actually use any DTML. It can be difficult to easily escape DTML in StructuredText. Also, I think for those who don't want it, it would be nice to be able to turn it off. After all--I believe that DTML is cool, but not necessarily central to the idea of an object that is meant to hold content. (Not, this is not the case for templating, as opposed to content-holding objects.) Also, if we decide to go for a generic Document object with an option for post-processing, I would advocate that there be a way to plug different processors easily into it. For example, I might want my Document to hold XML and process it with XSL (inspiration from Gabe Wachob). In fact, if we head down this road I can see lots of interesting things, like processors that do text filtering (like a frontier 'glossary' for example). We might also want processors to be actual Zope objects, so that moving them around in the object hierarchy changes how sub-Documents are processed. We might want Documents to have mime types, and processors to be registered to handle given mime-types... I think Zope's content management facilities could be beefed up, and the introduction of a new Document object is a good time to think about it. Not that I'm volunteering to write all this ;-) -Amos