Feedback Request: form:file Custom Tag
Matthew Woodward
We're rounding out our form custom tags for Mach-II 1.8 and since we added
so many controls recently, the only one we're left having not implemented
is an input type of "file."
Personally this one has always been a stickler for me in Mach-II. Because
of the way form posts and file uploads work, what exists in the Mach-II
event object when you do a file upload is the file data itself as opposed
to a simple string, which means people run into problems when using
event.getArg("fileFieldName") in their CFFILE tags. We wrote an FAQ on this
here:
http://greatbiztoolsllc.trac.cvsdude.com/mach-ii/wiki/FAQUploadingFile
This should be much simpler than it is, and since Mach-II 1.8 is code-named
"Simplicity," this is a prime candidate from that aspect in addition to
rounding out the form tag library. But we need your feedback so we
implement this feature in a way that makes the most sense to you.
Peter and I were discussing this on IM today and we came up with the idea
of having the file form field tack something unique on the end to indicate
it's a file, which makes things a bit easier in the listener that handles
the form post. So in your form you'd have something like:
<form:form actionEvent="processFileUpload">
<form:file name="photo" value="Browse" />
<form:button name="button" value="Upload Photo" />
</form:form>
(Note that bind/path syntax will work for the file input as well.)
If you use the form:file tag in your form, Mach-II will add the appropriate
enctype to the form tag for you since that's a common thing to forget.
As for the file field itself, this will potentially render something along
these lines for the HTML:
<input type="file" name="photo_-_file_-_" value="Browse" />
Note the "_-_file_-_" at the end of the input name. We haven't settled on
exactly what that will be, but what we're looking for is some way that will
indicate this is a file input, and doing so in such a way that the
potential to conflict with something you'd actually use for an input name
is minimal.
This leads to the listener. Peter and I talked through several ideas, from
leaving the CFFILE bits in the listener method up to the developer to
implement, to totally automating things, and I think where we landed was
somewhere in the middle, namely that we'd add a new method to the framework
to handle file uploads more simply. Of course this would ultimately be a
wrapper for CFFILE ACTION="UPLOAD", but would integrate better with Mach-II
(certainly much better than what you have to do now!).
So, just throwing this syntax out there for comments--imagine this would be
in a listener (I'll discuss the "uploadResults" bit in a moment):
<cfset uploadResults = uploadFile(arguments.event.getArg("photo"),
"/dest/directory/here") />
Without providing anything else we'd default to:
1. Using the original file name as the name of the file stored on the
server
2. Using a nameconflict setting of "makeunique"
3. Note the arguments.event.getArg("photo") bit--we'd tack the _-_file_-_
stuff on the end when grabbing things so you're using the name of the field
you specify before it gets modified to indicate it's a file input.
I'd have to think about what else we could intelligently default, but of
course you could pass additional parameters as well:
<cfset uploadResults = uploadFile(arguments.event.getArg("photo"),
"/dest/directory/here", "newFileName.jpg", "overwrite")) />
Lastly, the uploadResults would of course contain the typical stuff you're
used to having access to after a CFFILE upload. Again, it's a wrapper for
CFFILE under the hood but this should make things a bit more slick to use
and will certainly integrate with Mach-II much better.
So let us know what you think--ultimately this is YOUR framework and we
want to make it work as best we can for you!
Thanks,
Matt
--
Matthew Woodward
ma...@mattwoodward.com
http://mpwoodward.posterous.com
identi.ca/Twitter: @mpwoodward
Please do not send me proprietary file formats such as Word, PowerPoint,
etc. as attachments.
http://www.gnu.org/philosophy/no-word-attachments.html
Brian Klaas
will help newcomers who often get tripped up with file uploads in Mach-
II. I do have a couple of questions/concerns, though:
1. If the file upload happens in the listener, it's assumed that
validation for the object which is related to/contains the file has
already happened. If validation has not happened (let's say you have a
newsItem object, a property of which is a photo), and validation
fails, then the file would have been uploaded to the server, perhaps
unnecessarily, without the container object (the newsItem) being
persisted. Obviously, this can be handled by the individual developer
who can check and make sure that the object validates before
uploading. It'll be worth mentioning this in the docs so developers
don't fall in to this trap.
Looking forward, if a validation framework becomes part of Mach-II
1.9, taking in to account the file upload action as part of the
validation framework may become important. You, again, don't want to
upload if the container object doesn't validate.
2. The automatically-generated _-_file_-_ string appended to the form
field name doesn't seem to be much of a problem to me. If you're using
the form tag library, you're already letting it write the names of
form fields according to library rules.
3. Are there threading issues to be concerned about with the <cffile>
tag? My understanding was that at least through CF7, <cffile> wasn't
entirely thread safe and that you should create a separate "uploader"
object and instantiate that object each time you wanted to upload a
file to work around the thread safety issues.
brian
Matthew Woodward
Thanks for the feedback Brian--comments inline below.
On Tue, 3 Nov 2009 05:59:58 -0800 (PST), Brian Klaas
<brian...@gmail.com>
wrote:
> 1. If the file upload happens in the listener, it's assumed that
> validation for the object which is related to/contains the file has
> already happened. If validation has not happened (let's say you have a
> newsItem object, a property of which is a photo), and validation
> fails, then the file would have been uploaded to the server, perhaps
> unnecessarily, without the container object (the newsItem) being
> persisted. Obviously, this can be handled by the individual developer
> who can check and make sure that the object validates before
> uploading. It'll be worth mentioning this in the docs so developers
> don't fall in to this trap.
Right--honestly this is no different than what you'd have to do if you
handle uploads manually, so unless I'm missing something I don't think
we're introducing any new concerns here.
Just so it's clear, we will NOT be doing any automatic file uploads based
on form field names. You'll have to call the uploadFile() (or whatever it
winds up being called) method to actually do the upload.
From a validation standpoint what this means is that you could do your
validation prior to uploading the file, but if you're in a situation where
for some reason you have to upload the file first and then do some
additional validation, you're right; you'd have to delete the file after
the fact if you don't want it sitting on your server.
> Looking forward, if a validation framework becomes part of Mach-II
> 1.9, taking in to account the file upload action as part of the
> validation framework may become important. You, again, don't want to
> upload if the container object doesn't validate.
Sure--see comments above. The developer decides when the file gets uploaded
within the listener method, so again I don't think we're introducing new
problems. Definitely let me know if I'm misunderstanding the issue.
> 2. The automatically-generated _-_file_-_ string appended to the form
> field name doesn't seem to be much of a problem to me. If you're using
> the form tag library, you're already letting it write the names of
> form fields according to library rules.
OK--good to know that isn't a huge concern. Not sure how we'll handle it
exactly but I'd like to see the ability to refer to the form field within
the listener by the name without the stuff tacked on the end (e.g. "photo"
as opposed to "photo_-_file_-_). Should be easy enough for us to figure
that out for you.
> 3. Are there threading issues to be concerned about with the <cffile>
> tag? My understanding was that at least through CF7, <cffile> wasn't
> entirely thread safe and that you should create a separate "uploader"
> object and instantiate that object each time you wanted to upload a
> file to work around the thread safety issues.
I'll have to admit I'm ignorant on this point. Not sure why it would be
less thread safe than anything else but those of you on the list who have
more insight into this issue than I, please chime in.
Just so it's clear, we're not introducing an entirely new way of handling
file uploads, so it would be governed by the same rules as normal CFFILE
uploads since that's what we'll be using.
Thanks again for the feedback--very helpful!
Matt
--
Matthew Woodward
ma...@mattwoodward.com