On Mon, Apr 15, 2002 at 10:47:24AM +0200, Stephan Diehl wrote:
>
> > > It would also help to have an option of "accept the source format
> > > without conversion and serve it as is without touching its internal
> > > structure" alongside "convert the source document to an in-between
> > > format so it's easy to reconvert into any output format."
> >
> > This is especially important for sites that trust a CMS kit enough
> > to use it, but not enough to allow it to go wild reformatting the
> > internal structure of the page. Maybe as these users deploy the
> > CMS and start us
> > ing it for a while, they'll trust it more later to
> > do some reformatting.
>
> What would you see as essential for a CMS kit?
At minimum, the basic functionality of a wiki minus the wiki syntax:
write document online, edit online. I guess a preview mode should be
essential, with a "make more changes" button (sometimes pressing the
browser's Back button on TWiki's preview page loses all my changes).
Alternate ways to edit the document are important, because textareas are
inconvenient for large documents. FTP (a la Zope) is good because
everybody has it, and WebDAV for those who have it. The first phase
could just have a stub for import/export routines, to be filled in later.)
Version history is not that important to me, but if it's easy enough to
incorporate CVS, why not? That might suggest a web interface to CVS
(CVSKit?), but that would be better done as a separate project. (PS.
Remember that CVS alternatives are emerging, so we wouldn't want to
write a CVS kit that precludes plugging in alternative back ends.)
Most sites will want metadata stored with the document. Title, author,
publishing date, category, etc. However, each site has different ideas
about what these fields should be. You'd need a list of field names,
types, and boolean required/optional. We'd need a form for editing
these fields. Zope makes a form with the fields at the top and the
textarea below, with a file upload control (actually a tab) for the
textarea. Zope also has a web interface to modify the field names, but
we could skip that and make the siteadmin put a Python list somewhere
instead. For field types, we'd have to decide what variety to support.
Strings at minimum, maybe also numbers and dates (using mx.DateTime).
Zope supports many types, but maybe we don't want to go that far.
Some sites will need a "hide this document" checkbox, or a date range for
when to display, to avoid the public reading an unreleased or expired
document. Sometimes documents need to be prepared the day before and
published in the middle of the night when nobody is at around, to
coincide with 8am in another time zone.
Sites that edit documents in text files may want to edit the metadata
with the documents. We could use a simple XML format:
<article>
<system-metadata>
<publish>Y</publish> <!-- Legal values: 'Y', 'N' -->
<start>2002-04-15</start> <!-- Date visible to public, empty=now -->
<end>2002-04-15</end> <!-- Date expires, empty=never -->
</system-metadata>
<user-metadata> <!-- Fields specified by siteadmin -->
<title>The Adventures of Huckleberry Finn</title>
<author>Mark Twain</author>
<email>[EMAIL PROTECTED]</email>
<visible-publishdate>2002-04-15</visible-publish-date>
<dateline>Raleigh, NC</dateline>
<teaser>A story about an ornery dude.</teaser>
</user-metadata>
<body> <![CDATA[
This is my article. In HTML format, wiki format, or whatever is
acceptable for this site section.
]]> </body> <!-- Strip leading/trailing whitespace, add final newline. -->
</article>
External Python routines will need a way to get all the articles in a
certain site section, query metadata fields individually, update fields
and validate articles (e.g., all required metadata present, correct
types, start date <= end date). Perhaps export it like this:
class Article:
def __init__(self):
self.system_metadata = {}
self.user_metadata = {}
self.body = ""
Sites will want to display the articles their own way, so we could have
a generic Display class sites can customize. Some sites may want to use
a Cheetah template to display the article, e.g.,:
from SOMEWHERE import Display
from Cheetah.Template import Template
TEMPLATE_FILE = "/home/bozo/article_template.tmpl"
class MyDisplay(Display):
def __init__(self, article):
self.article = article # An Article instance.
def html:
searchList = [article]
t = Template(file=TEMPLATE_FILE, searchList=searchList)
html = str(t)
return html
with a template like:
#set $umd = $user_metadata
### sectionImage is a user method to convert section name to image URL.
<IMG SRC="$sectionImage($umd.section)">
<H1>$umd.title</H1>
$body
which would be plugged into a larger servlet.
Of course, some sites will need distinct pools of articles for various
portions of the site, with different display styles and different
metadata. They can use separate CMS Kit instances for this.
Since it's unlikely we'll arrive at one CMS Kit that pleases everybody,
we should plan a naming scene that allows several to coexist.
Especially, the generic name CMSKit should not be monopolized by one
implementation that may turn out not to be the best.
On the wiki at
http://webware.colorstudy.net/twiki/bin/view/Webware/WebwareDocumentManagementSystemMSO1
linked on the document management sysem appideas page.
(Grr! TWiki + Mozilla = pains trying to paste in a document larger than
a page. You click the mouse "paste" button, and it puts the text in the
wrong place. The cursor jumps to the beginning of the document, and you
try to cut & paste the page again or discard changes and start all over.
Repeat for each screenful of added text. Not only that, I had to play
with <verbatim>...</verbatim> several times to get the XML example to
display right, and finally changed all the <> to {} to get around it.)
--
-Mike (Iron) Orr, [EMAIL PROTECTED] (if mail problems: [EMAIL PROTECTED])
http://iron.cx/ English * Esperanto * Russkiy * Deutsch * Espan~ol
_______________________________________________
Webware-discuss mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/webware-discuss
