On 2005-06-17, Rhesa Rozendaal <[EMAIL PROTECTED]> wrote:
>
> 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?
Usually the data doesn't have embedded HTML chunks to worry about it.
But I agree it would be nice to fix them up if they were present.
>> 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.
Andy Lester? He always strikes me as rather busy, but I imagine he would
respond well to prodding if it was accompanied with a patch.
> 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 :)
Still, I don't like the idea changing the design in automated way. The
document may become technically "standard", but may look broken in /all/
browsers if the changes aren't overseen by a human.
> 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 looked it in passing. If you try it with C::A, let us know how you
like it.
>> 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.
>
> That's how regular plugins work, and would be used, isn't it? Like
> Plugin::Session for example.
Yes.
>> 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'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'.
The other advantage is when the hook is created by another plugin, so
the whole thing is transparent to the user.
>> I haven't actually tried either design myself to confirm they actually
>> work.
>
> 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!
Although it may be still worth weighing the simple traditional way: I could call
$self->validate_html() and skip the hook, and you could call
$self->fixup_html().
and skip the hook system, too.
>> See also: New Perl Book called "Higher Order Perl".
>
> I'd like to see that "en vakker dag" :)
When I Google that phrase, a lot of Norwegian websites come up.
I enjoyed visited there is a teenager...
Mark
--
http://mark.stosberg.com/
---------------------------------------------------------------------
Web Archive: http://www.mail-archive.com/[email protected]/
http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
