Things are going really well with AxKit2. I got XPathScript working thanks to a patch from Yanick Champoux. And I spent a couple of days porting AxKit::App::Gallery.
This would have taken me less time but I wanted to try and get rid of the XPathScript in AxAppGallery because it's rather verbose, slows things down a bit, and I thought it could be done a bit simpler under AxKit2 (this wasn't possible under AxKit1). I was right.
The gallery code is now pretty verbose, and I think it could be slimmed down a fair bit, or at least cleaned up, but I think it's great that we can ship AxKit2 with a working application that almost everyone will appreciate.
It got me thinking - everyone likes apps. So we should ship with a few to show people how things work, but also to get people to hit the ground running. So I'm thinking of the following apps to ship:
- A gallery (done)
- A wiki (port of AxKit::XSP::Wiki)
- A blog
If anyone else has ideas of what might be cool "standard" apps, let me know. What do people build first when they get their hands on a new technology?
Re:Cart
Matts on 2006-08-04T21:18:04
The simple summary is that you no longer write config directives - you write a plugin. A simple example plugin would be:This way you control how the transformation happens with perl rather than with config directives. You also have to do caching yourself. The reason being that caching was one of the most complicated parts of the AxKit code, and it didn't always get it right, and sometimes you wanted to just turn it off altogether, and sometimes you wanted to deliver the cached copy even when AxKit didn't agree. All of that was too hard with 1.x.sub hook_xmlresponse {
my ($self, $input) = @_;
return OK, $input->transform(XSP => XSLT('/path/to/style1.xsl'));
}
Re:A forum
Matts on 2006-08-04T21:56:03
And a pony?;-) Re:A forum
bart on 2006-08-05T14:20:21
You must have confused me with somebody else.
