Very nice DPP - will try and take a look at this today. Cheers, Tim
On Jul 1, 7:20 pm, David Pollak <feeder.of.the.be...@gmail.com> wrote: > Okay... I've checked in new code. > > In LiftRules, there's: > > /** > * The function that converts a fieldName, contentType, fileName and an > InputStream into > * a FileParamHolder. By default, create an in-memory instance. Use > OnDiskFileParamHolder > * to create an on-disk version > */ > var handleMimeFile: (String, String, String, InputStream) => > FileParamHolder = > (fieldName, contentType, fileName, inputStream) => > new InMemFileParamHolder(fieldName, contentType, fileName, > Helpers.readWholeStream(inputStream)) > > You can change handleMimeFile to use OnDiskFileParamHolder. There's a > companion object that has a helper that'll allow you to create an instance > out of the parameters. By default, the OnDiskFileParamHolder deletes the > temporary file when it is finalized. > > If you want to monitor the progress of an upload, use LiftRules: > /** > * The global multipart progress listener: > * pBytesRead - The total number of bytes, which have been read so > far. > * pContentLength - The total number of bytes, which are being read. > May be -1, if this number is unknown. > * pItems - The number of the field, which is currently being read. (0 > = no item so far, 1 = first item is being read, ...) > */ > var progessListener: (Long, Long, Int) => Unit = (_, _, _) => () > > By default, it does nothing, but you can put in a function that'll look for > a session-specific CometActor and send it messages. > > If the above does not satisfy all your needs, you can subclass > FileParamHolder and do whatever you want. > > Thanks, > > David > > On Wed, Jul 1, 2009 at 10:31 AM, David Pollak <feeder.of.the.be...@gmail.com > > > > > > > wrote: > > K... I'll check some code in later today. > > > On Wed, Jul 1, 2009 at 9:05 AM, Andrew Scherpbier > > <and...@scherpbier.org>wrote: > > >> It would also be nice to be able to provide progress feedback. The page > >> returned after the form submission can then use comet to display a > >> progress bar or something like that. (The media upload at Vimeo comes > >> to mind as a good example of this!) > > >> Also, I would suggest some smarts when creating temporary files. It > >> might be good to abstract the cache so that small files don't get put on > >> disk. > > >> --Andrew > > >> Vlad Seryakov wrote: > >> > I am also contemplating to use Lift but lack of big file upload is the > >> > showstopper. We need to upload images, and big video files and > >> > currently there i snot way to do it in Lift, i need something else to > >> > handle that which makes the whole stuff more complex than needed. > > >> > Spooling into temp file and doing async upload of multiple files at > >> > the same time is what needed. Nowadays media uploads is normal and > >> > those files are getting bigger and bigger. > > >> > On Jun 30, 5:58 pm, Timothy Perrett <timo...@getintheloop.eu> wrote: > > >> >> This has been hurting me for quite a while now (raised it on list > >> >> about 2 months ago) and could really do with getting it fixed. > > >> >> As derek points out, it's not a small change which is why I've done > >> >> nothing about it to date - a little too much core hacking to feel happy > > >> >> If you think your able to do something about it that would be > >> >> absolutly brilliant! > > >> >> Cheers > > >> >> Tim > > >> >> Sent from my iPhone > > >> >> On 30 Jun 2009, at 22:33, David Pollak <feeder.of.the.be...@gmail.com> > >> >> wrote: > > >> >>> What kind of priority is this issue? I think I can abstract things > >> >>> in such a way that it works correctly, but it'll take a couple of > >> >>> days. > > >> >>> On Tue, Jun 30, 2009 at 2:08 PM, Derek Chen-Becker < > >> dchenbec...@gmail.com > > >> >>>> wrote: > > >> >>> Well, as usual something that seemed simple at first glance is now > >> >>> looking somewhat complex. I'm thinking of reworking the fileUpload > >> >>> handling to allow a user to register either a (String, String, Array > >> >>> [Byte]) => Any or (String, String, InputStream) => Any function, > >> >>> which would then be executed during request processing. The issue is > >> >>> that form field processing (ParamHolders) takes place in Req, befor > >> >>> e LiftSession has been set up, and the act of parsing the request fo > >> >>> r form data, particularly for large upload streams (the target of th > >> >>> ese changes) precludes holding on to any data for later processing ( > >> >>> the servlet container cannot be expected to hold the entire request > >> >>> in memory). On the other hand, users should reasonably expect that t > >> >>> heir form handling functions are stateful, so I'm trying to think of > >> >>> some way to meet in the middle on form processing. Ideas? > > >> >>> Derek > > >> >>> -- > >> >>> Lift, the simply functional web frameworkhttp://liftweb.net > >> >>> Beginning Scalahttp://www.apress.com/book/view/1430219890 > >> >>> Follow me:http://twitter.com/dpp > >> >>> Git some:http://github.com/dpp > > > -- > > Lift, the simply functional web frameworkhttp://liftweb.net > > Beginning Scalahttp://www.apress.com/book/view/1430219890 > > > Follow me:http://twitter.com/dpp > > Git some:http://github.com/dpp > > -- > Lift, the simply functional web frameworkhttp://liftweb.net > Beginning Scalahttp://www.apress.com/book/view/1430219890 > Follow me:http://twitter.com/dpp > Git some:http://github.com/dpp --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~----------~----~----~----~------~----~------~--~---
