The problem AxKit solves [was: templating]

[Matt Sergeant <ma...@sergeant.org>]

Actually that should say "one of the problems..."

Most templating systems out there work in one of two ways:

1. a bi-directional manner, where you have both systems calling into the
template, and the template calling out to code. Take for example TT, you
can have a module call the template toolkit to generate a page, and the
page can execute functions elsewhere, calling back into Perl-space.

2. A uni-directional manner, but in (IMO) a backwards direction, where the
template calls into Perl-space. Systems such as ASP are like this.

What AxKit allows you to do (you are not prevented from using the above,
but its a bad idea, I think), is have a uni-directional system where the
template _never_ calls backwards in the procesing stream - it is always
forward looking. The advantage of this is that you can build systems where
there's never any *incentive* to build some small component that you might
embed some HTML tags to add an extra feature (in Perl-space) because you
should never have to output tags in your coding stage.

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

Now I picture the bi-directional systems:

  Res ---> Process ---> Process ---> Process ---> Delivery
   \         /             /            /
    \       /             /            /
   [ P E R L -- S P A C E -- P E R L -- S P A C E ]

Thats not actually *such* a bad idea, because at least you're requesting
the resource, not the process.

Now picture the other uni-directional systems:

  Process ---> Process ---> Process ---> Delivery
     \            \             \
      \            \             \
    [ P E R L -- S P A C E -- P E R L -- S P A C E ]

There is no resource. What your browser requests is not a resource but a
stylesheet!

[Its worth noting that I've shown several processing stages here, but in
reality not many templating systems support more than one processing
stage]

Thats why I prefer AxKit's method, which is the first diagram. I just find
that neater. I also realise that this may irk some people, because my
concept of Perl-Space here is a virtual one - there's no real separate
perl space in most of these systems, its just a conceptual separation. But
to a designer working on a web site I think the forward pipeline
processing makes more sense. I'm certainly not suggesting any increase in
speed from the forward processing methodology.

-- 
<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

Re: The problem AxKit solves [was: templating]

[Matt Sergeant <ma...@sergeant.org>]

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

Re: The problem AxKit solves [was: templating]

[Joshua Chamas <jo...@chamas.com>]

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?

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.

Alternatively with XSLT & Apache::ASP, the ASP script
becomes the XML resource, static or scripted, translated 
by a separate possibly scripted XSLT stylesheet.

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?

-- Joshua
_________________________________________________________________
Joshua Chamas			        Chamas Enterprises Inc.
NodeWorks >> free web link monitoring	Huntington Beach, CA  USA 
http://www.nodeworks.com                1-714-625-4051