Steve,
> 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.
I have to say I've studied http://xml.apache.org meantime, and that now I
see your scheme looks very similar to Cocoon/XSP processing scheme, except
you are trying to use XSLT (possibly with extensions) for all
transformations/logic. I must say that after I looked at Cocoon and your
design, I quite like the "data -> (static) content -> design" distinction.
In our Charlie schemes we are typically collapsing the "data -> content"
part (or even "input => data -> content") to a large extent into a single
step processed by background XML application. The thing here is that while
you talk about a complete web application framework, Charlie is really an
"XML application middleware", working with any XML application backend and
providing it with interface processing (what you call design) and various
caching features. We don't want to dictate the metodology of XML
data/content generation, let it be plain XML files, CGI-scripts, mod_perl
application, Cocoon, Zope or whatever, so we view the source of XML
data/content as a black box. Anyway, this doesn't negate anything you say,
just that we are at this point not particularly interested what way are XML
data generated, while you are.
> 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.
Isn't it foolish to try to use XSLT, even with extensions for this, then ?
While using only small number of technologies within the whole framework
sounds simple, bending them to much to perform task not natural to them can
make it worse in turn. I think this is a place for a full fledged
application language, such as (mod_)perl or Zope/Python (or possibly ASP,
XSP etc, but I personally don't consider these so flexible). I guess that's
the same idea you describe with a "datascript" model bellow.
> 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?
Coccon seems to have something like this, BTW, called DCP (I think). The
description looked very similar to your original object embedding idea.
> controller => datascript => controller => input+data -> content -> design
>
> 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.
Yes, that is actually exactly the point I was trying to make above. XSLT
isn't a good tool for your engineers.
> > 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.
Actually I would say both of these approaches are quite close. In Charlie,
the XML data/content (again, the distinction of data and static content is
hidden within "XML data source" and I call it both together "XML data") can
be static or dynamic, generated in any way - charlie (and it's actions)
refers to it by URL. The built-in controller is pretty simple in Charlie, as
all it does is calling javascript actions, which play the role of your
"controller". When you add new designs etc, you change actions, but there is
also a lot of space to implement any possible naming conventions in
"default" actions.
I've already discussed the reason for a choice of JavaScript - while you are
designing a compact server-side XML/XSL web application framework, this is
only one special mode of operation of Charlie. Ultimately the main features
of Charlie will be inteligent XML data and XSLT template caching in case
charlie runs on different machine (possibly same as browser or some local
proxy) than the XML data server.
Honza
