On 9/17/06, Edi Weitz edi@agharta.de wrote:
See also here:
http://common-lisp.net/pipermail/tbnl-devel/2006-February/000559.html
Thanks!
I don't think there's a better way. But do you think that a hook for MAKE-TMP-FILE-NAME is the right solution?
Conceptually the hook should probably be "after we have the filename, before we start reading the file". Good luck finding a good name! ;-) (I named mine *pre-file-upload-hook* which I'm not satisfied with but I can't think of anything better right now.)
Whether that's in MAKE-TMP-FILE-NAME or not doesn't really matter to me. The reason I picked it was simply that I didn't want to change RFC2388, because as you say, the way it works now by calling back into TBNL is hackish enough already. :-)
At that point you won't know for /which/ uploaded file you're called.
Actually I do know. At that time *REQUEST* is bound and I store a session-key in a cookie that's passed in. So what I do in my hook is retrieve the user doing the upload, via the cookie, then store the temporary filename in my database as part of the user's session. This way my Ajax calls won't have to pass around a filename and there's no way for the user or browser to see my filesystem layout and/or change the filename that's checked in the progress bar.
Seriously, this is a bit hacky anyway because the RFC2388 calls back into TBNL. I'd like to have a cleaner solution, but that'd probably imply that TBNL implements its own RFC2388 parsing.
Yeah, not sure what the best approach is yet. To be honest, I haven't looked much at the RFC2388 library.
I'd like to provide something in TBNL to enable things like upload progress bars, but I'm still looking for a solution that looks clean and unobtrusive to me.
The simplest way I can think of is with a hook right when we have the filename but before we start writing to that file. It's the one I'll be using for now but if I think of something better down the line I'll be sure to suggest it here.
The older thread you linked suggested modifying RFC2388 to write a status file but this is an extreme specialization of the RFC2388 library, in my opinion.
Thanks, Erik.