I've been looking at TemplateServer some lately, and I don't feel like
it really fits some of the goals that I have. So, for TS's benefit,
or anyone elses, or even my own, I want to describe some of what I'm
looking for:
* Accessible to the web-publishing/html novice. This describes pretty
much everyone I work with -- they aren't stupid or unwilling to learn,
they simply have other duties and skills. They all know how to use
word processors, and in turn they should all find it easy to use a
WYSIWYG HTML editor.
Part of being friendly with WYSIWYG editors is that everything can
be described without going to HTML source mode, that fully formed
HTML pages are expected (complete with <body>) and that the
resultant HTML is reasonably correct (for instance, IMG SRC tags
point to a real image). It's not so much that putting text between
<table> and <tr> is invalid, as there's no way to access or create
that text in a WYSIWYG editor. But I'm unsure whether those cases
apply to what I'm describing anyway.
* Content-oriented. Right now I'm making most stylistic choices, and
implementing them myself. For the forseeable future it would be
perfectly fine for all such site-wide templates definitions to go
through me, even if a graphic designer makes the sample page off
which the template will be based. Such site-wide changes just don't
happen that often.
What I need is for the *contents* of pages to be easily
defined. Every web site has portions that are freeform text, like
contact information, upcoming events, etc. Allowing non-programmers
to define these concerns me, because non-programmers are the best
sources of that information.
* Not strictly page-oriented. There's a lot of data that involves
HTML, but doesn't map to a page. And for convenience of editing it
would often be nice if one server-side HTML page could map to
several pages on the web site.
To support this there should be some way of getting HTML fragments
from a page created by a WYSIWYG editor, and a way for the user to
define some structure to these fragments. I would prefer if the
model for this was declarative, rather than imperative (i.e., the
code provides data, it does not execute, and it does not modify
any namespace)
* Relatively safe to delegate responsibility (kind of like Zope).
For the most part I trust my users not to do anything too bad, but
they will make mistakes. They should be able to figure out what
they've done wrong, and they shouldn't have any access to Python
code. I consider putting their HTML into a different directory from
code to be sufficient security for the most part.
* It really should be usable for non-HTML code, specifically form
emails. This is where a number of my trials have failed. OTOH, I
often think that emails should be composed in HTML, instantiated,
then translated to text (via lynx, for instance). Otherwise the
word wrapping is off.
Right now I've implemented a simple system as an experiment. I
actually wrote it in Perl, but the idea is more important than the
(trivial) implementation.
It uses tags like [varname]...[/varname] to define structure. The
resources title, keywords, description, and body are also taken from
the HTML.
It is inserted into a template, which just uses [=varname], and has
one operator, "or". E.g., [= httitle or title] (if httitle is
defined, that gets inserted, otherwise title).
It would be nice if it nested structures, and if structures could be
repeated. This is where it becomes similar to XML... and indeed, it
has many of the same goals. It does not have attributes (which I
consider superfluous), and it has better tool support, since it
doesn't require XHTML, it doesn't mix structure with data, and it
works pretty well in current WYSIWYG editors.
The SitePageServletFactory I posted earlier does just the simplest
stripping of title, body, keywords, and description elements, but has
a similar intention.
I'm not sure if TemplateServer can really do this usefully -- it
shouldn't be everything to everyone. But this is the problem DTML
documents/methods try to solve, and I think it's a valid and important
problem. Oddly, I'm not sure if Zope Page Templates really address
these same concerns, even though they seem to intend to. And while
non-standard attributes are preserved, I haven't been able to find any
way to view, edit, or create such attributes in Composer or
FrontPage. So I'm not really sure if ZPT is as great as I was hoping.
Ian
_______________________________________________
Webware-discuss mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/webware-discuss
