[Html-widget] file uploads and element_type combined patch

John Napiorkowski jjn1056 at yahoo.com
Wed Nov 15 21:32:52 GMT 2006


Hi,

Here's a patch for the two changes I've been talking
about the last day anf a half.

First it has the new accessor called 'element_type'
for the element object, which returns the scalar name
of whatever you typed into the type field when
creating the element.  It's just a nicer way of doing
a regex against ref $element to get the type name. 
The only changes between this and the patch I sent
earlier today is some documentation about the new
accessor.

The second patch is more involved, and changes the way
file uploads are handled.  Here's what I did:

If you don't set $widget->uploads or don't set the
uploads during process ($widget->process($query,
$uploads) this works exactly like it did before, 100%

If you DO set either the uploads accessor or pass a
second parameter to process, the following happens:

First, whenever you used for $uploads is tested to see
if it is a ref and if it has a method called 'upload'.
 If it doesn't it croaks out and stops.  We might want
to have this do a warn or something instead, because I
imagine this might break some people's stuff.  Let me
know.

If everything is good, it will get the uploads and
merge them into the local params, not the
catalyst->request->parameters.

This get's processed as normal for the rest. 
Afterwards, the results object will give you access to
the upload object (that have been filtered) via the
$results->param(upload_field) method.  The only that
that is changed with this is that before the
$results->param(...) would give you the filename of
the uploaded file.

This is also behavior that could break existing stuff,
if you are looking for that filename.  Although
honestly it's pretty useless, so hopefully this won't
be an issue.

When you make filters or constraints against an upload
type field, the value is not a scalar, but the upload
upload that catalyst or a compatible object presents. 
So if you want to do some checking you'll have to call
those methods on the object.

Here's an example of a filter I wrote that resizes an
uploaded image:

my $mediafile_filter = $self->form->filter(
'Callback', 'mediafile' );

   $mediafile_filter->callback(sub {

      my ($value) = @_;
      
      if($value)
      {
         my $content_type = $value->type;
         my $mediafile_out;
         
         if($c->request->parameters->{media_type_id}
eq 'profile_photo')
         {
            my $mediafile_hd = $value->fh;
            
            ## Convert to the right size and output as
a jpeg
            
            my $upload_img = Imager->new;
   
            if ($upload_img->read(fh=>$mediafile_hd))
            {
               my $resized_img   =
$upload_img->scale(xpixels => 120, ypixels => 90, type
=> 'min');
               
               my $background   = Imager->new(xsize =>
120, ysize => 90);
               $background->box(filled => 1, color =>
'blue');
               $background->paste(src=>$resized_img);

               $background->write(data =>
\$mediafile_out, type => 'jpeg');
            }
         }

         return $mediafile_out;
      }
      
      return '';
   });

I also added a test for this new behavior.  I had to
make some changes to the test mock object to support
uploads.

Now that we have this, I can update the upload element
so that all those documented constrainsts (accept,
size, ect) will actually do something.

let me know if you want a more generic form of the
image filter above.  I can imagine other people might
want it.  It's good for when you want to allow a
client to upload an image but you want to normalize it
to a certain size and file type.

Anyway, let me know if this is the right tack to take.
 Awaiting your thoughts.

John


 
____________________________________________________________________________________
Sponsored Link

Online degrees - find the right program to advance your career.
Www.nextag.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: combined.patch.gz
Type: application/x-gzip
Size: 2442 bytes
Desc: 1395907857-combined.patch.gz
Url : http://lists.scsys.co.uk/pipermail/html-widget/attachments/20061115/90e1a664/combined.patch.bin


More information about the Html-widget mailing list