[tbnl-devel] Add hook before uploading a file.

[Erik Enge]

On 9/17/06, Edi Weitz <edi at 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.