On 2005-06-16, Rhesa Rozendaal <[EMAIL PROTECTED]> wrote:
>
> I've been playing with the new callback stuff, and it's quite neat! Well
> done guys :)
Thanks.
> I'm in the process of building a plugin for HTML::Tidy. The intention is
> to convert the output into valid xhtml using tidy.
I'd like something similiar, but different. I'd just like to see the
problems as warnings in a pop-up. If they can fixed, we'll just fix the
files if possible.
I'm concerned about automated changes to the HTML that would break the
look of the page. Maybe HTML::Tidy has settings to just make the "safe"
changes automatically?
> For that purpose, I use the 'postrun' callback. However, I'm running
> into a potential problem: most of my applications do some
> post-processing in an overridden cgiapp_postrun as well (such as
> adding headers and footers), and the callback is called _before_ my
> cgiapp_postrun. This means the call to tidy comes too soon. Is there a
> way to make a hook that runs just after cgiapp_postrun so that I can
> do a final pass on the output?
This brings us back to the hook ordering conversation. I've had some
thoughts on it which might be new. Ordering implies there is a "first"
position. We were trying to figure out an automated way to handle
getting the Right thing to run really first, and I'm not sure that can
done without cooperation or human intervention. The current prescribed
ordering is going to be what some people want and not others.
Here's two about how run modes could cooperate.
1. At the end of your cgiapp_postrun, just call the routine you want to
run directly. Design the plugin so that allowed to be done, and the run
via a callback is skipped.
2. At the end of your postrun, add a call to the hook "run_html_tidy".
( The hook will have to be created first somewhere. )
Have the plugin check to see if a such hook exists. If it does,
register there instead of 'postrun'. Then it will run at the right
time, and other plugins can cooperate in the same way.
I haven't actually tried either design myself to confirm they actually
work.
> Another question I have is more a matter of interface design. I want
> to add the option to specify the config file for tidy, but I'm not
> sure how to get at it. Currently I'm (ab)using the 'use' line like
> so:
>
> use CGI::Application::Plugin::HtmlTidy config_file =>
> '/etc/tidy.conf';
>
> I'm wondering if that is the most appropriate way to do it; It feels a
> bit odd to me. On the other hand I definitely don't like to have the
> user mess around with package variables, and I'd prefer to avoid extra
> code for the user altogether.
There are two standard places for configuration variables to show in
CGI::App application designs.
1. The instance scripts. These can be passed via param(), or your
plugin can adopt/co-opt another key name to use in the hash.
2. In config files.
I vote for (1) for your app, which seems better suited for configurating
one or two things. I would just use the param() system, giving users the
flexibility to set the value at some othe place in their scripts besides
the instance script.
> This is how I get at it in my plugin (the option handling is just a
> quick hack, obviously) :
>
> our %OPTS; sub import { my %opts = splice @_, 1; $OPTS{CONFIG_FILE}
> = $opts{config_file} || '/etc/tidy.conf'; my $caller =
> scalar(caller); $caller->add_callback('postrun', \&tidy_clean); goto
> &Exporter::import; }
>
> Is there a better transparent way to supply data to the callbacks?
Maybe you want a closure?
# Pseudo-code-- not complete and working!
sub make_tidy_clean {
my $opt = '42';
$caller->add_callback('postrun', sub {
my $self =shift;
my @args_from_user = @_;
# Notice how I snuck $opt into this anonymous sub!
return &tidy_clean($opt,@args_from_user);
});
}
See also: New Perl Book called "Higher Order Perl".
Mark
--
http://mark.stosberg.com/
---------------------------------------------------------------------
Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/
http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
