[Html-widget] RFC Handling uploads, WAS uploads in the results object?

[Carl Franks]

On 14/11/06, John Napiorkowski <jjn1056 at yahoo.com> wrote:
>
> Okay, sorry to post so many brain dumps about this
> upload issue but now that I've spent some time looking
> at the code for this and for the way uploads are
> handled in Catalyst and CGI.pm I have some thoughts
> and would really like to get some opinions.
>
> First of all I don't think having the uploads method
> or attribute should be an Apache::Uploads object.
> Right now there is nothing in the code enforcing that,
> and although the upload reference is passed to
> contraints, filters and elements, nothing is being
> done with that so changing this won't break anything,
> as far as I know.

Agreed.

> The documentation specifics that:
>
> my $w = HTML::Widget->new('widget');
>
> $w->uploads($arrayref)
>
> where the arrayref should be of Apache Upload objects.
>  However my guess is that most people are using this
> primarily in catalyst or for CGI development, and
> between the three methods for accessing uploads
> (Catalyst->request->uploads, Apache::Uploads and
> CGI.pm) there are significant differences.
>
> As far as I can see there are only two things to do,
> either make a least common denominator structure to
> pass to uploads or to create a new interface objects
> that you'd need to build based on the upload interface
> of your choice.
>
> For solution one that structure would probably have to
> a hashref something like:
>
> {
>   uploadfieldname1 => {
>
>     fh => <filehandle>,
>     size => xxxxd,
>   },
>   uploadfieldname2 => {
>
>     fh => <filehandle>,
>     size => xxxxd,
>   },
> }
>
> Since there isn't much in common between the standard
> ways I've found of accessing uploads.
>
> For the second method, create an interface, we could
> do it to be the 'most common denominator' method,
> which would be a catalyst compatible hashref of
> objects.  Then we'd have parse plugins to convert from
> CGI.pm, Apache::Upload and Catalyst to that common
> interface.

Having $w->uploads() compatible with $catalyst->request->uploads()
should be the top priority.

Maybe for compatibility with CGI.pm, we could add a $w->cgi_query()
which would use $q->upload() and $q->uploadInfo() to fake up a
structure to give to $w->uploads().
Anyway, if you're not using CGI.pm yourself, don't worry about that now.

> Then it wouldn't be so hard to make the filters and
> constraints work.

If you already have an svn account on dev.catalystframework.org - just
ask an admin for write access to the HTML-Widget directory.
Otherwise a patch (preferably with tests) against svn would ge great.

Thanks,
Carl