On Sunday 03 June 2001 13:35, Ian Bicking wrote:
> 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:
Good idea! TemplateServer's gaping hole at the moment
is higher-level docs that describe how it can be used in
> 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.
Can you post the code and an example? I'm interested
in your approach. I particularly like your idea
about being able to extract content from pages that
have been defined in a WYSIWYG editor.
The example site that I created
is but one way to use TemplateServer. It doesn't illustrate
how to use TS to meet all the goals you have, but I'm fairly
confident that many of the can be met when TS is use in a
different manner from the way I use it.
The core of TS is fairly flexible and straight-forward. There
are many ways in which it can be used to build up a site, or
whatever else you're building. My SkeletonPage / TSservlet
approach is but one. Therefore it might be possible to
accomplish most of these goals with TemplateServer.
SkeletonPage + TemplateServer.Servlet != TS
> * 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.
To be honest this was never high on my list as I never
use WYSIWYG tools that muck with your sourcecode. I'm
like you and use Emacs for everything.
However, many use nothing but WYSIWYG tools and it's
a worthy goal to give them something usable.
> * 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
This can definately be achieved with TS. The #block directive
is intended for this:
Place your text here...
> 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.
> * 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)
Good idea. Mike's block idea in PlowPlate is similar to this.
You could write a small script that searches for #blocks
that are defined anywhere in an HTML file and extracts the
blocks with an associated blockname.
Again, the only thing about TS that is page orientated
is TS.Servlet + SkeletonPage and
TS.Servlet + SkeletonPage != TS
> * 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.
That was one of my original goals, but I shifted away from it
upon realizing how complex things can become. The hooks
for code security validation are in place so it is possible to
build it up if anyone is interested in 'safe-delegation' that
guards against malicious stuff.
> * It really should be usable for non-HTML code,
> specifically form emails. This is where a number of my
> trials have failed.
Trials with what? TS or what you're working on? TS is
designed to be used with an text not just HTML. The
SkeletonPage framework is HTML specific, but SkeletonPage
is not TS.
> It uses tags like [varname]...[/varname] to define
> structure. The resources title, keywords, description,
> and body are also taken from the HTML.
What do you mean by "structure"?
> 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
> The SitePageServletFactory I posted earlier does just the
> simplest stripping of title, body, keywords, and
> description elements, but has a similar intention.
Stripping to get rid of them, or stripping to keep this info?
> I'm not sure if TemplateServer can really do this
> usefully -- it shouldn't be everything to everyone.
True, but the core should be reasonably flexible so it
can be used as desired. The framework that is built on
top of it - SkeletonPage, etc. - is less permissive.