[Catalyst] Bug in uri_for()

[Paul Makepeace]

On 7/14/06, Peter Karman <peter at peknet.com> wrote:
>
>
> Paul Makepeace scribbled on 7/13/06 7:44 AM:
> > Folks may already know about this, sorry I haven't checked RT etc:
> >
> > I've just upgraded from 5.66 to 5.70 and noticed a bug with uri_for -
> > it seems that if one of the final-arg hash ref parameters has a value
> > that is not something it's expecting it dies, for example,
> >
> >  $c->uri_for($base, @args, { url => $c->req->base });
> >  # "Non-array reference (URI::http) passed to uri_for()"
> >
> > The $c->req->base is a URI::http. My solution was to force it to
> > stringify by appending a blank string (e.g. .'')

> I don't think this is a bug. Had a similar problem this morning. I think

I consider at the least a usability bug - consider,

  $param = { url => $c->req->base }

  [% c.uri_for('/foo', param) %]

Would you reasonably expect that to break? Especially considering it
used not to, 5.66.

Not only that, uri_for() seem to break if its first arg is a URI::http
too, from some cursory tests earlier. (There may be something going on
here extra but I don't think so, $c->uri_for($c->req->uri) )

Just MHO :)

> the issue is how the URI::http object is overloaded. My solution was to
> do the same thing the overloading does:
>
>   $c->uri_for( $c->req->base->as_string )
>
> which is similar to what you're doing, but with the documented method
> rather than forcing the overload to occur.
> --
> Peter Karman  .  http://peknet.com/  .  peter at peknet.com
>
> _______________________________________________
> List: Catalyst at lists.rawmode.org
> Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
> Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
> Dev site: http://dev.catalyst.perl.org/
>