Bug in URI ?!

[Paul Makepeace]

[+catalyst]

On 8/16/06, Matt S Trout <dbix-class at trout.me.uk> wrote:
> Dominic Mitchell wrote:
> > David Dorward wrote:
> >> Paul Makepeace wrote:
> >>> URI::_query::query_form() which makes query strings:
> >>>
> >>>  $self->query(@query ? join('&', @query) : undef);
> >>>
> >>> Now as anyone in web standards knows, that ought to be '&amp;'.
> >>
> >> Only if the URI is being written in HTML. Since, to judge from the
> >> module name, it is just a URL there shouldn't be any markup language
> >> specific encoding going on. Once you have the URI you should run it
> >> though a suitable encoding method before using it in markup though.
> >
> > Once again, this highlights how poor our tools our...  If templating
> > systems did HTML escaping by default, this wouldn't be an issue (i.e.
> > having to remember to html encode all strings that could possibly
> > contain user input).  When will our frameworks grow up?
>
> They already did, you just weren't looking.
>
> package MyApp::View::HTML
>
> use base qw/Catalyst::View::TT/;
>
> __PACKAGE__->config(
>    STASH => Template::Stash::EscapeHTML->new
> );
>
> 1;

Has anyone actually used this? Apart from it not passing its own POD
coverage tests (and thus requiring a force install), it seems to
simply result in the whole template output being escaped, HTML 'n all.
Admittedly I haven't looked into this very much but since it wasn't
even passing tests and that people cite modules on lists without
trying them I thought I'd ask first.

(Nice idea though.)

I think a less heavyweight solution would simply be to be able to
configure c.uri_for to produce HTML-escaped URLs (or not), which IMO
it ought to be default. It's a _web_ app framework after all... Even
Template's own URL plugin does this, putting correctness aside for
pragmatism.

P