[Zope3-dev] Axe DTML Document

[Casey Duncan]

On Tuesday 18 December 2001 03:15 pm, Martijn Faassen allegedly wrote:
> Florent Guillaume wrote:
> [snip]
>
> > One question you have to ask yourself is, what kind of content do you
> > want ? Pure preformatted text ? Structured text ? HTML ? XML ? PDF ?
> > Microsoft Word ? Where do you stop... :-)
>
> That is an excellent point. We need Documents for each type of content,
> perhaps even multiple types. There will be commonalities we can perhaps
> make into a framework, but let's stop thinking about 'Document' as a
> single thing.

To me this brings me back to what is a file and what is a document and should 
we draw that distinction at the metatype level as we currently do, and create 
a different metatype for every conceivable format?

This is a convenient at first, but highly unscalable solution. So the 
suggestion is that we have 1 or 2 content objects. If we have two, they would 
be:

1. Binary files
2. Textual Files that can be edited directly "in place"

Now since, #2 is a subset of #1, is that a useful distinction? Zope 2.5 has 
blurred the line here by making textual file editable through the web. So 
perhaps we need only have files?

A distinction that was pointed out is that Documents have different views, 
and can be in some cases treated like a DOM tree and manipulated as such. 
But, I think you could argue the same for certain binary types there.

I'm still a ComponentArchitecture newbie here, so maybe it's not the pancea I 
imagine where you have "pure" content data in one object, with some generic 
functionality. And then specialized functionality (such as XML parsers, PDF 
writers, HTML mungers, Structured Text Renderers, MSWord converters, ad 
naseum) is in these separate "adapter" object/classes.

I'm sure it will come to me as I learn more.

So to distill it down to it's bare essence:

A document is a contaner for a blob of content, with associated metadata and 
a facility to associate it with template "views" for presentation (if 
necessary) and adapters for manipulation. These associations may be automated 
based on the content-type of the data.

A document should map cleanly to a single file so that FTP/WebDAV 
manipulation makes sense. Adapters could be used to include and extract 
metadata from content on the fly for certain formats (such as HTML or XML, or 
even an extended STX). Or alternately, metadata could be serialized as a 
"parallel" file in the FTP/WebDAV point of view.

Editing or manipulation of a document TTW should be facilitated by a view. A 
texteditor view would work much like the current "Edit" view of DTML objects. 
A DOM view could be used to inspect and work with tree-like data, such as 
XML. Views could be associated by content-type as well. 

In my mind, none of these requirements point to a definite need to have 
separate document and file objects at the base level. Is there a requirement 
that I have missed that does?

/---------------------------------------------------\
  Casey Duncan, Sr. Web Developer
  National Legal Aid and Defender Association
  c.duncan@nlada.org
\---------------------------------------------------/