On Wed, Oct 17, 2001 at 11:47:01PM +0200, Jonas Liljegren wrote:
> What I was looking for is probably better described as "online website
> creation tool". The creator should be guided through some simple steps.
There's something I've been working on that might be of interest in
this discussion of CMS.
I've been writing some modules to represent the concept of a document
set. It's just a simple page/container model which allows you to define
documents which get grouped into document sets, which get grouped into
larger document sets and so on.
There can be any number of different ways to construct a document set.
For example, you could have an XML file to define the index, complete with
metadata, etc., which references files in particular directories.
e.g.
<docset>
<section id="foo" dir="foofiles">
<page file="abc.html" title="Blah Blah"/>
<page file="xyz.html" title="Hello World">
<author>Andy Wardley</author>
<version>3.14</version>
<about>This is a welcome to our version of reality</about>
</page>
...
</section>
</docset>
You should also be able to define some directories to search, in the
same way that ttree currently works (and indeed this might become the new
engine for ttree).
<section id="bar">
<search dir="barfiles" recurse="1">
<accept>\.html$</accept>
<ignore>\b(CVS|RCS)\b</ignore>
</search>
</section>
And there should no doubt be other clever ways of storing docset information
or file content in SQL databases, grepping META tags from templates to build
indexes, creating symbolic links across sections and so on. The docset should
try to Do The Right Thing to work out where files are based on paths relative
to their parents, unless you tell it otherwise.
One important concept to note is the separation of the document content
(i.e. the physical file on the disk or dbase) from the abstract document
properties within the document set. You may want to map real files to
document set pages on a 1:1 basis, but you might also want to split the
37 <chapter> ... </chapter> sections in a single XML file into 37 different
pages, or you might want to combine the 10 files in one directory into a
single HTML page. Hence the real/virtual mapping at that level to make all
these things possible.
As well as defining the information to map real world files (content) onto
the abstract docset model (sections and pages), you can also define URLs
for different components to map them onto a different abstract model (your
webserver URL space). Again, the default might be a 1:1 mapping based
on dir/file combinations, but you might also want to override that with
any number of different fancy schemes (supplying absolute URL, rewriting
file extensions, generating many pages from one template, merging many
templates into one page, etc.)
<section id="foo"
url="~abw/docset/foo/"
dir="/home/abw/docset/foo/">
<page file="hello.html" url="hello_world.html"/>
<section dir="bar/" url="bar/"/>
<page file="goodbye.html"/>
</section>
</section>
The nodes of the docset are smart enough to work out relative file paths,
directories, URL's and so on, based on their relationships with their
parents (enclosing sections). I haven't figured it all out yet (input
welcome!) but you get the general idea - it Does The Right Thing to grok
as much of it's own information as possible from its surroundings.
Once you've got a docset model you should then be able to apply certain
actions to part of it. For example, you can batch process one section
of the docset to generate content offline, just like ttree currently
does. Another section might get processed dynamically by a mod_perl
handler. It can use the docset info to map URLs to source templates,
process the file and send the output back. There are plenty more
possibilites.
As well as working as a document description framework for high-level
processes, it also has the benefit of exposing the document set structure
to the individual templates in a coherent fashion. What that means in
English is that you can write [% docset.next.link %] in a template to
generate a link to the next document in the set or something like:
<a href="[% docset.index.href %]">[% docset.index.title %]</a>
to generate a link to the index page for this section. The docset should
be able to construct absolute or relative URLs to any page in the docset
from any pages in the docset and that should make it a lot easier to write
generally reusable menus and other navigation components. Index pages
can also be constructed automatically, tables of contents, site maps, and
so on.
I've deliberately kept the model very simple because I think that's the
key to defining truly generic components for a larger Content Management
System. The docset model represents the structure and key features of
a document system and implements functionality to manage the connections
between parts of it (e.g. file -> page -> url mapping, generating next/prev
links, relative URL's etc). That's it, no more, no less. Sure, there can
be all sorts of fancy ways to build docset models, process parts of them,
store them in databases, apply access control policies, and so on, but
they're all optional extras. They're the things that people will want to
do differently from time to time, so they're outside the core system.
I suppose it's a lot like the XML Document Object Model but working on a
higher level. The Document System Model perhaps? Whatever it's called,
or however it turns out, I do think that, at the lowest level, there should
be a basic model-only representation of a document system that doesn't
implement any processing functionality itself, but is something that
other processes can use as a standard representation and operate upon.
I've got various snippets of working code that I'm putting together into
something usable (hopefully :-) but I'm still far from making any firm
decisions on how exactly it should look, feel and work, so I'm totally
open to suggestions, offers of help, etc.
And also, if there's anything already out there that I should be looking
at, in terms of existing software, projects, standards, etc., then please
do clue me up! :-)
A
