On Tue, Jun 30, 2009 at 11:32 PM, David Pollak < feeder.of.the.be...@gmail.com> wrote:
> > > On Tue, Jun 30, 2009 at 2:22 PM, Viktor Klang <viktor.kl...@gmail.com>wrote: > >> Create a tmp-file, store the localpath in S.param and register a delete on >> request done >> >> will be more streamlined than potentially monkeypatching it in >> Thoughts? >> > > Huge hack > Yes, and I apologize for suggesting it, it was inappropriate. As we all know, the problem is that if you want to have access to the _full_ "current" state of the client (S) at the time of parsing the request (the parsing of the file likely not the last item in the request) in order to be able to process the file in a stream, unless some other solution is found, the stream parsing of the file has to rely on not having current client side state (S) available. Now, I've made such solutions in the past, and the impression I've had from API users have been that they actually expected client state to be available at file parse time. So in order to solve this you'd have to either guarantee that the file(s) present in the multipart request is always located _after_ any and all other form fields/parameters and the issue the callback at the time of each file item being encountered (at the time of calling openStream()) Also, so far in the thread different behaviors of file uploads are mentioned: 1) Process one or many files in a streaming fashion 2) Multiple file upload (store on server and process when user says he's done) As we've all said in this thread: The problem is not trivial to solve in a satisfactory way, but I think we all can agree that you, David, will most likely be able to solve it, as usual, very cleanly. One possible solution that I can imagine is to have a multiple request solution: On the client, before every file upload, send the current client state as a separate request and wait for a 200/OK before sending a request containing one or more files. This way you can rely on the client state being fresh when processing the files, and lift would invoke the input stream processor associated with the file field in question. > > > >> >> -- Viktor >> >> On Jun 30, 2009 11: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, before LiftSession has been set up, and the act of >> parsing the request for form data, particularly for large upload streams >> (the target of these 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 >> their 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 framework http://liftweb.net > Beginning Scala http://www.apress.com/book/view/1430219890 > Follow me: http://twitter.com/dpp > Git some: http://github.com/dpp > > > > > -- Viktor Klang Scala Loudmouth --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
