Well every once in a while someone still asks about AxKit 2. I know
this project has mostly floundered and people have gone on to other
things, but I still find some value in the XML paradigm for web
development - specifically in saving me from worrying about XSS
errors, but also it looks really useful for AJAX stuff.
Anyway... Where is AxKit 2.0?
Well it's coming. In the last few days I've thrown together a few
bits of code that are the framework for AxKit 2.0.
First things first: AxKit 2.0 is nothing like AxKit 1. It doesn't
even remotely resemble it. That's both a bad thing and a good thing.
I'll explain why.
But first, what does it look like? Well I spent a long time thinking
about what it meant to be AxKit, and I also spent a long time
thinking about how could I make it easier to use and install in these
days of quick setup frameworks like Ruby on Rails. Sadly mod_perl is
not quick to setup. Neither is Apache. These are large complicated
frameworks with lots of features I don't need on my application
server. Instead, AxKit2 has its own httpd. You can read a bit about
it here: http://use.perl.org/~Matts/journal/30438
Having our own httpd means that development and deployment is much
easier. Plus it frees us of the ties of Apache upgrade cycles and
mod_perl changes. I did not want to be stuck for an "AxKit3" when
Apache 3.x comes out!
So I wrote a simple pluggable scalable httpd. It's all pure perl, so
no nasty compilation required (except obviously you still have to
compile XML::LibXML etc). Plugins can trivially add configuration
directives, making development of new subsystems fast and easy.
And yes it's buggy as all hell right now. But it'll get better I
promise.
Now, on to what the "AxKit" part looks like. Well I decided that I'd
had enough of special cases and extra wrapper code inside the AxKit
internals - we spend so much effort in there making sure dependencies
are logged and checked, and caching is done at every step of the way
and so on. All this actually slows the whole thing down, and makes
the code really ugly. So it's gone. If you want to cache from now on
it will be DIY.
And all that config directives stuff to setup pipelines - that got
really ugly if you wanted alternate pipelines. So that's all gone
too. Instead AxKit becomes an API for setting up the transformation
pipelines, and a bunch of utility modules for helping that out.
Everyone can write perl, and if you can't the examples will be simple
enough, or someone will write a plugin to set all this up via config
directives.
So let's do a quick example. Say you want to do XSP -> XSLT -> XSLT -
> HTML. Here's what the code you'll write will look like:
sub hook_response {
my $self = shift;
my $file = $self->{headers_in}->filename;
# setup the processor
my $proc = AxKit2::Processor->new($file);
my $s1 = "/path/to/xslt1.xsl";
my $s2 = "/path/to/xslt2.xsl";
# run the transform ($out is an AxKit2::Processor also)
my $out = $proc->transform(
XSP => XSLT($s1) => XSLT($s2)
);
$out->output($self->client);
return OK;
}
(Note: I haven't got XSP working yet - but it shouldn't be too hard,
touch wood!)
So now where is this groovy code? Well it's in axkit.org svn for now,
but at some point I'll get the apache guys to setup a new repository
for us on there. Meanwhile follow the progress and have a play around
at svn://axkit.org/axkit2
Matt.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
