FAQ
I constantly bump into the mismatch in the treatment of 'normal'
params and the file uploads.

Wouldn't life be simpler if

$c->request->param( 'file_field' )

would return a Catalyst::Request::Upload object (or an array of them)?

You can get the name of the uploaded file from a
Catalyst::Request::Upload object.

Search Discussions

  • John Napiorkowski at Jul 3, 2007 at 6:27 pm

    --- Zbigniew Lukasiak wrote:

    I constantly bump into the mismatch in the treatment
    of 'normal'
    params and the file uploads.

    Wouldn't life be simpler if

    $c->request->param( 'file_field' )

    would return a Catalyst::Request::Upload object (or
    an array of them)?

    You can get the name of the uploaded file from a
    Catalyst::Request::Upload object.

    --
    Zbigniew Lukasiak
    I also think about this a lot since I'm working mostly
    on applications with lots of file uploading. You'd
    still get a sort of mismatch though, but would be in
    the type of thing that 'param' is returning.

    In a way, with a POST everything is really an upload,
    just that by convention if the type is urlencoded with
    consider it a flat parameter list. But I think we
    will need a more evolved way of thinking about this.
    Work that's been done on the REST controllers suggest
    a possible path. This way we can convert any type of
    incoming POST into some sort of Perl object or List of
    lists. Just need the correct de/inflators.

    I like that Catalyst lets me easily separate
    parameters extracted from a urlencoded body from
    search query parameters. I do really use then for
    separate things.

    You could probably write a quick plugin to push upload
    objects into the param list, but messing with that
    list will probably result in it not being widely
    accepted.





    ____________________________________________________________________________________
    Be a better Globetrotter. Get better travel answers from someone who knows. Yahoo! Answers - Check it out.
    http://answers.yahoo.com/dir/?link=list&sid96545469
  • Matt S Trout at Jul 3, 2007 at 9:10 pm

    On Tue, Jul 03, 2007 at 04:25:30PM +0000, Zbigniew Lukasiak wrote:
    I constantly bump into the mismatch in the treatment of 'normal'
    params and the file uploads.

    Wouldn't life be simpler if

    $c->request->param( 'file_field' )

    would return a Catalyst::Request::Upload object (or an array of them)?
    No, because this would break the ability to pass the request object to
    something expecting the CGI.pm API, and break compat for existing app code.

    Maybe have a think about what you'd like to see from a completely new
    unified API and propose that?

    --
    Matt S Trout Need help with your Catalyst or DBIx::Class project?
    Technical Director Want a managed development or deployment platform?
    Shadowcat Systems Ltd. Contact mst (at) shadowcatsystems.co.uk for a quote
    http://chainsawblues.vox.com/ http://www.shadowcatsystems.co.uk/
  • Zbigniew Lukasiak at Jul 4, 2007 at 12:29 pm

    On 7/3/07, Matt S Trout wrote:
    No, because this would break the ability to pass the request object to
    something expecting the CGI.pm API, and break compat for existing app code.
    I think you meant Apache::Request because the current implementation
    is not compatible with CGI.pm.

    ->param( 'file_field' ):
    - in CGI returns the filename that is also a filehandle
    - in Catalyst it is just filename

    ->upload( 'uploaded_file_name' )
    - in CGI returns a filehandle
    - in Catalyst returns Catalyst::Request::Upload
    Maybe have a think about what you'd like to see from a completely new
    unified API and propose that?
    So my wishlist would be: ->upload to return the filehandle (for
    compatibility with CGI), ->param to return Catalyst::Request::Upload,
    and make Catalyst::Request::Upload stringify to the filename. If we
    could also make Catalyst::Request::Upload work as a filehandle in
    angle brackets it would be entirely compatible with CGI.pm (but not
    with Apache::Request).
  • Matt S Trout at Jul 4, 2007 at 3:52 pm

    On Wed, Jul 04, 2007 at 11:29:12AM +0000, Zbigniew Lukasiak wrote:
    On 7/3/07, Matt S Trout wrote:
    No, because this would break the ability to pass the request object to
    something expecting the CGI.pm API, and break compat for existing app code.
    I think you meant Apache::Request because the current implementation
    is not compatible with CGI.pm.
    My mistake.
    Maybe have a think about what you'd like to see from a completely new
    unified API and propose that?
    So my wishlist would be: ->upload to return the filehandle (for
    compatibility with CGI), ->param to return Catalyst::Request::Upload,
    and make Catalyst::Request::Upload stringify to the filename. If we
    could also make Catalyst::Request::Upload work as a filehandle in
    angle brackets it would be entirely compatible with CGI.pm (but not
    with Apache::Request).
    That looks like it'd improve compat, give you what you want, and not
    break any existing code, unless I've misunderstood your logic. Assuming
    I haven't, I'd love to see a patch to do this - does anybody else have
    any thoughts?

    --
    Matt S Trout Need help with your Catalyst or DBIx::Class project?
    Technical Director Want a managed development or deployment platform?
    Shadowcat Systems Ltd. Contact mst (at) shadowcatsystems.co.uk for a quote
    http://chainsawblues.vox.com/ http://www.shadowcatsystems.co.uk/

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupcatalyst @
categoriescatalyst, perl
postedJul 3, '07 at 5:25p
activeJul 4, '07 at 3:52p
posts5
users3
websitecatalystframework.org
irc#catalyst

People

Translate

site design / logo © 2022 Grokbase