Mark Stosberg wrote:
On 2005-06-16, Rhesa Rozendaal <[EMAIL PROTECTED]> wrote: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.
That would make a great addition during development, but I'm also using it in production. It should be possible to make that configurable, so we can accomodate both goals. Final fixup is still a good idea though: you may be able to control the templates, but what about all the data you send into them?
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?
That would be entirely up to you. Tidy's configuration is quite flexible, and allows for a great many tweaks. The only quibble I have with the current version of HTML::Tidy, is that it only accepts configuration parameters through a file. I'd much prefer being able to pass a hash of options. Maybe I need to prod Andy about that.
I must say that you may need to reconsider if you're worried that valid (x)html wouldn't render as intended. That sounds as if you're relying on browser quirks instead of standards, and I can tell you first hand that is not a safe position :)
For that purpose, I use the 'postrun' callback. [snip] 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.
I'm sorry I haven't been able to participate in that discussion earlier.Has anybody ever mentioned Class::Trigger? It would be nice to have 'before_foo' and 'after_foo' triggers, for instance, and Class::Trigger has already proven its usefulness in Class::DBI. I don't think it answers the "really_first" vs. "first" issue though, I believe.
> 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 prescribedordering 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 runvia a callback is skipped.
That's how regular plugins work, and would be used, isn't it? Like Plugin::Session for example. This is basically how I use tidy at the moment. It still requires me to override cgiapp_postrun (or add additional code there), which I was hoping the hooks would alleviate.
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 righttime, and other plugins can cooperate in the same way.
I'm not sure I see the difference. The only advantage this has, is that there could be several callbacks at that point. In that rare case, I would rather see a public hook at that point, such as 'after_postrun'.
I haven't actually tried either design myself to confirm they actuallywork.
Let me see if I understand the process:
- Plugin gets 'use'd;
- PLugin calls new_hook('html_tidy');
- Plugin calls add_callback('html_tidy', sub{ ... } );
- at some point in user code, add a call to call_hook('html_tidy');
That doesn't look so bad, come to think of it! This would allow me to
create two new hooks: fixup_html and validate_html. You would
call_hook('validate') in your postrun, while I would call the fixup
variety. That's a nice compromise!
use CGI::Application::Plugin::HtmlTidy config_file => '/etc/tidy.conf'; Is there a better transparent way to supply data to the callbacks?Maybe you want a closure?
Maybe later, but thanks for the offer :)I was wondering about how to give the user the possibility to pass data to a plugin that installs class-based hooks, since normally you don't need to add any code beyond the "use" line. And since those hooks are class-based, they can't get at the param() data at the moment of installation. You did make me realise they can get at it later on, though, since they receive the object at the moment of invocation.
I think it's best to keep the params to 'use' for real imports or stuff that really needs to happen at install time.
See also: New Perl Book called "Higher Order Perl".
I'd like to see that "en vakker dag" :)Thanks for the discussion, I now understand the whole business a lot better. I really need to go talk to Andy now :)
Rhesa --------------------------------------------------------------------- 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]
