See what I mean?
I do indeed. Most people that use XSP sucessfully end up casting it as thin layer between the incoming request and a Taglib that does all the real work; all others eventually seem to despair of XSP and look elsewhere (usually custom Application Providers).
There are two ways you can go here, at the moment:
First, you can use the Apache::Filter Provider, just write the part that generates content as a plain CGI script, and use the AxAddDynamicProcessor directive to define a class that sets the transformations that will applied to the generated content.
Second, you can do everything by hand in your own custom Provider class.
For the first case, you just create Ye Olde CGI script that generates the content (note, the result *must* be well-formed XML). Then, you write a simple DynamicProcessor handler that will select the styles and use the AxAddDynamicProcessor directive to point to that class.
I'll assume that you can write the CGI yourself, so all that's left is writing DynamicProcessor handler and the config block that makes it all work. Here's a skeleton for a DynamicProcessor handler class:
package My::CGI::Processors;
sub handler {
my ($provider, $preferred_media_name, $preferred_style_name,
$doctype_public, $doctype_system, $root_name) = @_; # normally, @styles will be generated dynamically rather
# than hard-coded as we have here. my @styles = (
{ type => 'text/xsl', href => '/styles/mystyle.xsl' },
{ type => 'text/xsl', href => '/styles/myotherstyles.xsl' },
);return @styles; } 1;
That's it (and pretty close to what you had imagined, actually). Now the config block:
<Files your.cgi> Options ExecCGI SetHandler perl-script PerlSetVar Filter On PerlHandler Apache::RegistryFilter AxKit AxContentProvider Apache::AxKit::Provider::Filter AxAddDynamicProcessor My::CGI::Processors </Files>
Now for the second method, the all-in-one custom Provider:
package Apache::AxKit::Provider::Garvin;
use strict; use warnings; use vars qw( @ISA ); use Apache::AxKit::Provider; @ISA = qw/ Apache::AxKit::Provider/;
sub process {
my $self = shift;
$self->{_XML_} = undef; # here's where you generate your XML, appending it
# onto $self->{_XML_} $self->{_XML_} = qq|<?xml version="1.0"?>|;
$self->{_XML_} .= qq|<root><child/></root>|;return 1; }
sub get_strref {
my $self = shift;
# just pass a reference to the content
# generated in process() and stored in $self->{_XML_}
return \$self->{_XML_};
}sub get_styles {
my $self = shift;
my ($pref_media, $pref_style) = @_;# again, hard-coded where yours probably won't be.
my @styles = (
{ type => 'text/xsl', href => '/styles/mystyle.xsl' },
{ type => 'text/xsl', href => '/styles/myotherstyle.xsl' },
); # note that it's an array *reference* not a plain list
# like in a DynamicProcessor
return [EMAIL PROTECTED];
}# these 3 are for AxKit's internals, ignore them for now
sub key {
my $self = shift;
my $r = $self->apache_request;
return $r->uri;
}sub exists {
return 1;
}sub mtime {
return time(); # content is dynamic, hence always fresh
}
1;And that's it. All you'd need do is change the content generated to fit your specific app and add the following to your config:
<Location /some/virtual/uri> AxContentProvider Apache::AxKit::Provider::Garvin </Location>
and you're all set. There are other ways to get the same net effect but these two are the easiest and least potentially messy going forward. Note that the custom Provider is a little more work, but will probably be significantly faster.
Let us know how you make out. If you get stuck, or something wasn't clear, please don't hesitate.
-kip
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
