On Fri, 28 Jul 2000, Joshua Chamas wrote:
> Matt Sergeant wrote:
> >
> > To picture this better I imagine it as a forward moving pipeline, from
> > initial "resource" (the XML file, or whatever the URL maps to), to
> > delivering the file:
> >
> > Res ---> Process ---> Process ---> Process ---> Delivery
> >
>
> I think this is an interesting way of looking at things, took
> me a while to get my head around why ASP didn't fit into
> this model, because ASP usually isn't raw data right?
Right. The normal ASP model is to actually request the thing that is in
the style that is to be delivered. There's no dynamic choosing of the
right thing to deliver to the browser, its up to the application designers
to give the right URL's to things if they've got (for example) web TV's to
deliver the same content to.
> I think this limitation in the ASP model was striking which
> was a motivation between XMLSubs taglibs in Apache::ASP.
>
> <my:tag>
> Some content
> <my:deeptag>
> More Content
> </my:deeptag>
> </my:tag>
>
> What happens here with XMLSubsMatch my: is each tag
> level acts as your Res(ource), and the final output
> HTML, gets passed to the higher up enclosing sub for
> processing. This can be right along side any normal
> ASP scripting, and this mesh model gives you what you
> need when you need it.
This doesn't take you out of the realm of backward processing though (I
don't mean "backward" in a derogatory sense, btw) - the resource still has
to call backwards into Perl-Space to get a definition of the tag, and the
tag outputs HTML. Until you get to the next step...
> Alternatively with XSLT & Apache::ASP, the ASP script
> becomes the XML resource, static or scripted, translated
> by a separate possibly scripted XSLT stylesheet.
Right. This is pretty much the right fit solution IMHO. Here you have
forward processing, where the code simply executes and moves onto the next
step. Think of a factory production line - always moving along. If you
need to do more work you do it at a later stage in the pipeline.
> But what I find curious is that you denoted no perlspace
> for AxKit, and when looking at XPathScript, it seemed like
> there would be, so what I perhaps am missing the subtleties
> as to why AxKit necessarily doesn't have a perl space, I thought
> the perl scripted XML processing was quite a nice touch actually.
> Maybe your "processor" doesn't count if it is perl feeding
> directly off an XML datasource?
Although XPathScript does allow you to embed perl code, I strongly
discourage that unless its important to the transformation at hand. Or
perhaps something trivial like outputting the date. I do not envisage
anyone putting DBI calls in XPathScript stylesheets. If they do, they've
designed their application badly, probably. Doing DBI and processing form
params is trivial to do in XSP, and thats how it should be done.
--
<Matt/>
Fastnet Software Ltd. High Performance Web Specialists
Providing mod_perl, XML, Sybase and Oracle solutions
Email for training and consultancy availability.
http://sergeant.org | AxKit: http://axkit.org
