--On Monday, September 27, 2004 9:13 AM +0100 [EMAIL PROTECTED] wrote:
My current app has, say, 10 screens. It is set up in such a way that I have a module with 10 subroutines. Each screen has a perl script associated with it and a stylesheet. This is set up as one directory entry in httpd.conf with a <Files> directive for each perl script. Each perl script is very small and basically just calls a subroutine in the module above with arguments parsed from the URI string.
Given the above, how would I design a system using content providers? Would it be one content provider somehow calling the subroutines in the above module? Or would it be one content provider replacing one script ie 10 content providers? Would I use the same approach for 100 screens?
As with all things perl, Theres More Than One Way To Do It (TM).
Here's how my system does it... Its not the only way, or even necessarily the best way, but it works well for me...
I use a single content provider, which is really a wrapper around another Perl Module that is object oriented. The content provider's init method creates the object and stores it, i.e.:
$self->{object} = new My::Module::Here(@some_args);
It also parses any HTTP GET/POST CGI arguments and stores the ones it cares about, i.e.:
%args = $self->{apache}->args();
$self->{op} = $args{op} if (exists $args);
Then the get_strref method checks to see if it can map the 'op' CGI argument to a method in the object, and calls that method, i.e.:
if ($self->{object}->can("op_".$self->{op})) {
$op = "op_".$self->{op};
eval "\$doc = \$self->{object}->$op()";
return $doc;
}
Finally the provider's get_styles method is responsible for setting up the stylesheet chain. In my case the first stylesheet is based upon the arguments, with two additional sheets applied afterwards, i.e.:
if ($self->{netsage}->can("op_".$self->{op})) {
return [{type => "text/xsl",
href => "/xsl/op-$self->{op}.xsl"},
{type => "text/xsl",
href => "/xsl/application-html.xsl"},
{type => "text/xsl",
href => "/xsl/application-style.xsl"},
];
Then I have one stylesheet per page/operation in my application. Though in practice many of my stylesheets are just wrappers of other sheets, i.e. since the page displaying the info about a database object is essentially the same as the page you get after updating that object 'op-row_update.xsl' and 'op-row_info.xsl' share a lot of code. So op-row_update.xsl actually is just an xsl:include of op-view_info.xsl, and that stylesheet behaves slightly differently depending on the situation. My system has about 150 stylesheets, of which almost 100 are the simple 'run this other stylesheet instead' case. I could put more logic into my get_styles method, so it knows which real stylesheet to be calling, but I was trying to avoid my provider really knowing virtually anything about the content of the XML.
I've left out a *lot* of details here, including most of the error detection and evil-user protection. If you're interested in a full example I can provide you a pointer to my code.
-David
David Nolan <*> [EMAIL PROTECTED]
curses: May you be forced to grep the termcap of an unclean yacc while
a herd of rogue emacs fsck your troff and vgrind your pathalias!--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
