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/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]

Reply via email to