First, I have to admit I'm nowhere near as savvy on the latest web
technologies as you are. I'm focused on other things at the
moment ... image recognition and my business ... but I am trying to
keep up with the latest web 2.0 stuff etc.
So, my use of AxKit1 right now: it's all XSLT and apache .htaccess
files. That's it, I have no perl, no XSP, nothing. I do however have
some pretty complex pipelines or actually pipeline trees to assemble
the final documents on http://semacode.org (100% axkit/xslt/apache)
like the front page which is assembled in maybe a dozen different
XSLT transforms from various files.
What I like about my system:
- it's 100% cached by axkit so it scales effortlessly
- since it's apache, I can mix in .php to send email, and I can use
mod_rewrite, etc, etc
What I don't like:
- it seems to be impossible to have such wonderful caching and also
have interactivity at the same time
So, for example, if I wanted to add a user login ... well, I was
thinking that for the pages that are static content, I could use AJAX
to do a user-side "include" for the dynamic content (like the
username, you have new messages, etc.) and keep the content largely
statically cached.
But what you're talking about seems like a major divergence. That's
cool, because I can't wait to see how it's all going to turn out. I'm
sure it will be interesting. But will it be a solution that I'll want
to use?
It seems like you're more abandoning the use of caching as a valuable
tool for scalability for example ... also it looks like I'll have to
write perl code to do anything (true?)
Anyway, my main interest is in continuing to explore the use of XSLT
pipeline/trees. I'd rather avoid writing procedural code (perl or
whatever). Is there something else that I should switch to? Will
AxKit1 be maintained?
--simon
On Jul 27, 2006, at 7:29 PM, Matt Sergeant wrote:
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]
--
http://simonwoodside.com
