On Thu, 18 May 2000, Honza Jirousek wrote:
> I don't understand the purpose of the XSLT extensions suggested, or perhaps
> used by XT or XSP. We would indeed appretiate some hints/explanations in
> this area, sure it might turn to be the best thing under the sun we
> underestimated so far ... Anyway, within Charlie architecture the role of
> Sablotron is to be a straightforward template/transformation processor. We
> have no need to spoil XSL or Sablotron with application control or data
> generation logic, because that's what Charlie is all about (see bellow).
I'll give the quick overview of my thinking: Imagine a transformation flow
for each page that looks like this (simplified):
controller **> input => data -> content -> design
The words (other than controller) indicate XML, and the arrows are XSL.
Now, with this setup, the writers edit the static content transform, the
designers edit the design transform (output is XHTML), and the engineers
work on the ==> step, which transforms from an XML representation of form
input to the set of data needed for that page.
The problem is that the => step needs to be able to get to a full
procedural language. XSLT's basic control structures just aren't good
enough.
I had imagined that most of the logic for the underlying data model is
kept in an object library. These objects aren't aware of anything XML or
in fact of the web (except in special cases). XSLT already has loops,
conditionals and variables, so I didn't want to take the Cocoon approach
and embed yet another language in the XSL file. So why not extend XSLT
slightly and give it the capability to instantiate objects and call
methods?
I've talked over the issue with some people at work, and tried to figure
out a way around the fact that this functionality isn't supported well
right now. We ended up deciding on a different approach.
controller => datascript => controller => input+data -> content -> design
This diagram is less useful, but basically we backed down to a better
version of the more traditional "CGI outputs XML, then transforms it"
model. The controller calls a data script, which is just a Python object
(that derives from, say, a Page class). This Python object instantiates
other objects, lists of objects, whatever...basically builds a tree of
data and puts the values in its own attributes. Then, when the object is
finished its "go" function, some magic code uses an equivalent of
reflection to ponder the object and dump all of its data attributes into
XML. Then the controller adds an XML description of the input (just in
case the later transforms need it) and the rest of the flow continues as
normal.
The interesting thing about the new approach is that the engineers don't
write any XML, nor do they write any XSLT. It's purely a bunch of objects,
totally decoupled from the underlying transformation mechanisms. Kinda
neat.
> 3) independent template manager. What Charlie (and possibly others, we'd
> like to know about them) does, is defining a new type of object - an action.
> User's request points at an action, which itself decides which XML data
> source (typically URL) to use and which XSLT template to couple it with.
> Actions are pieces of javascript code, which allows indefinite flexibility
> and combinations of data generators (typically CGI/mod_perl scripts or java
> servlets generating XML data) and templates. There is also a system of
> "default actions" for simple cases. At this point Charlie only supports XSLT
> templates and Sablotron, but could be modified for any template language
> working on XML data. Check http://www.gingerall.com for more info and some
> examples of Charlie.
This is close to what I'm doing, but not quite. I don't want to get
javascript or other control languages into the game, because there are
already two languages present. In my architecture, the action *can*
override the XSLT transforms (and the paths used to find the .xsl files),
but the controller sets a reasonable default based on naming conventions.
It saves us from having to change "control" code every time we add a new
transform file to the tree. We also won't have any .xml files anywhere;
it's all dynamically generated.
