Hi Matt, great to here that you finally got started with it. I currently have no time but hopefully soon to look at it. Together with the new callback mechanism of XML::LibXML/XML::LibXSLT this offers many interesting things for the future.
Tom Matt Sergeant schrieb: > 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] > >
signature.asc
Description: OpenPGP digital signature
