[Catalyst] Where is the form field lost?

Charlie Garrison garrison at zeta.org.au
Mon Jan 25 12:31:38 GMT 2010


Good evening,

On 25/01/10 at 11:30 AM +0200, orasnita at gmail.com wrote:

>If I remember well, the algorithm for deletion made a single deletion
>and then did a last() thinking that if one file was deleted, all the
>files were deleted. I think there was a little comment there that tells
>that. Although I didn't need to store the files in different dirs, I've
>noticed that that piece of code won't work in case of more directories
>used, however I don't think it is so hard to patch it for solving that
>issue.

That's the issue and that's what I was going to patch. But 
IC::FS was a better solution (at least in my case).

>Thank you for the code you sent. I will analyse it better to see if I
>can use another way, but what I would like to avoid is exactly to need
>writing too much code like this in order to use the module, so I don't
>want to need writing those wrappers for each file column nor a separate
>subroutine that provides the file name. But maybe I will be able to
>create one in the inflator...

Those wrappers aren't needed; it was just a convenience to make 
usage from TT easier.

>However I am not sure the way InflateColumn::FS works is compatible
>with HTML::FormFu. I think a better way would be the style used by
>InflateColumn::File eventually with a more flexible storage, or
>InflateColumn::FS should be changed so it should get the ID of the row
>after it is stored in the DB.

I use HTML::FF, but not for any file uploads, so I have no idea 
what sort of compatibility is needed (or available). I don't 
recall any difference between IC::File and IC::FS in relation to 
how files are assigned to columns. Hmm, there is a vague memory 
that with IC::File I had to create a hashref and store that 
instead, so again IC::FS is a win for simplicity.

>But in the second case, I don't know how I could store the real file
>name and the random path to the file without using more fields in the
>table.

Create a fs_file_name method and have it assign the name? Maybe 
HTML::FF upload element doesn't allow any flexibility there. I 
know that I was able to use the supplied file name, but I was 
also passing around the $req->upload object so it was easy for 
me to grab the file name. In the end I decided I didn't want 
that anyway.

>Anyway, back to the main issue, the biggest problem is HTTP::Body
>steals the file upload fields if no files were attached.

Sorry, can't help with that. I'm not sure I understand the issue 
either; if there is no upload field then just assign undef to 
the file column. Ahh, cause HTML::FF is doing it all for you. 
While I find HTML::FF is a great solution for many cases, there 
are also many cases where it needs manual intervention; this may 
be one of them.

I just had a look at HTML::FormFu::Element::File and I don't see 
how it's doing anything to assist with creating the hashref 
required by IC::File. Is HTML::FormFu::Model::DBIC handling that?


Charlie

-- 
    Ꮚ Charlie Garrison ♊ <garrison at zeta.org.au>
    〠 PO Box 141, Windsor, NSW 2756, Australia

O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
http://www.ietf.org/rfc/rfc1855.txt



More information about the Catalyst mailing list