Hello, what is the better way to implement a simple progress bar when uploading a file in Zope? Thanks (also for all the answers, hints and tips i've received from this wonderful community in the past times!) Bruno
Bruno Grampa wrote:
Hello, what is the better way to implement a simple progress bar when uploading a file in Zope?
Thanks (also for all the answers, hints and tips i've received from this wonderful community in the past times!) Bruno
_______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Hello, IIRC you cannot do it because Zope 2 publisher won't let you get a request state (ie, how much data has been retrieved by the server) I've started to work to add this feature for Zope 3 though. Tarek
+-------[ Tarek Ziad? ]---------------------- | | IIRC you cannot do it because Zope 2 publisher won't let you get a | request state (ie, how much data has been retrieved by the server) You can do it, you just need to think outside the box. You can't do it using purely through-the-web programming. -- Andrew Milton akm@theinternet.com.au
+-------[ Bruno Grampa ]---------------------- | Hello, | what is the better way to implement a simple progress bar when uploading | a file in Zope? The way I did it was to write a FS Product to handles uploads and that spawns a new thread for each upload. You should generate an id and redirect to a status page that can render any graphs you need (based on the id). -- Andrew Milton akm@theinternet.com.au
Andrew Milton wrote:
+-------[ Bruno Grampa ]---------------------- | Hello, | what is the better way to implement a simple progress bar when uploading | a file in Zope?
The way I did it was to write a FS Product to handles uploads and that spawns a new thread for each upload. You should generate an id and redirect to a status page that can render any graphs you need (based on the id).
interesting, how do you know in your thread the progress of data (i mean the %) that is beeing uploaded on the server ? Tarek
+-------[ Tarek Ziad? ]---------------------- | Andrew Milton wrote: | | >+-------[ Bruno Grampa ]---------------------- | >| Hello, | >| what is the better way to implement a simple progress bar when uploading | >| a file in Zope? | > | >The way I did it was to write a FS Product to handles uploads and that spawns | >a new thread for each upload. You should generate an id and redirect to a | >status page that can render any graphs you need (based on the id). | > | > | > | interesting, how do you know in your thread the progress of data (i mean | the %) that is beeing uploaded on the server ? To try and stem the flood of "how does it work" emails.. Long story short is I cheat. d8) You need some JavaScript to actually do the submission, which then pops up a status window which shows a Zope page that refreshes. The actual submission is to a small CGI that handles updating the status inside Zope via XMLRPC (you could also update a response file that the product could check as well, but, that's just more files that have to be written to and removed), when it's complete it passes in the location of the file(s) to the Zope Product so it can process them further (by spawning a worker thread, so you don't stop Zope from responding to requests). Part of the product also just draws a status graph giving a message saying what is happening and what the progress is, if there's more processing to be done (parsing or whatever), the graph can continue to be updated. When I said outside the box, I was pretty serious about being outside the box d8) Obviously you need to have some webserver available that can run CGIs, and talk to Zope, and (in this case is local to Zope for the file handling to work). It doesn't have to be in front of Zope. -- Andrew Milton akm@theinternet.com.au
Andrew Milton wrote:
The actual submission is to a small CGI that handles updating the status inside Zope via XMLRPC (you could also update a response file that the product could check as well, but, that's just more files that have to be written to and removed), when it's complete it passes in the location of the file(s) to the Zope Product so it can process them further (by spawning a worker thread, so you don't stop Zope from responding to requests).
oh k. i am trying to add this directly to the publisher, by providing a set of api and keeping running request state.
Part of the product also just draws a status graph giving a message saying what is happening and what the progress is, if there's more processing to be done (parsing or whatever), the graph can continue to be updated.
nice. in my use case it's a simple progress bar below the form
When I said outside the box, I was pretty serious about being outside the box d8) Obviously you need to have some webserver available that can run CGIs, and talk to Zope, and (in this case is local to Zope for the file handling to work). It doesn't have to be in front of Zope.
yes, i've seen some similar systems to deal with large file upload is you product avalaible ? Tarek
+-------[ Tarek Ziad? ]---------------------- | Andrew Milton wrote: | | >The actual submission is to a small CGI that handles updating the status inside | >Zope via XMLRPC (you could also update a response file that the product could | >check as well, but, that's just more files that have to be written to and | >removed), when it's complete it passes in the location of the file(s) to the | >Zope Product so it can process them further (by spawning a worker thread, so | >you don't stop Zope from responding to requests). | > | > | oh k. i am trying to add this directly to the publisher, by providing | a set of api and keeping running request state. Yeah ugly. I don't think distributing a Product that monkey-patches ZPublisher would be all that warmly received d8) | >Part of the product also just draws a status graph giving a message saying | >what is happening and what the progress is, if there's more processing to be | >done (parsing or whatever), the graph can continue to be updated. | > | > | > | nice. in my use case it's a simple progress bar below the form You could probably do that too using some JavaScript if you wanted, the API is all available in Zope. I'm not a 'front-end' type of guy, my main concern is to make sure it works so that people can put whatever frontend they want on it. | >When I said outside the box, I was pretty serious about being outside the box | >d8) Obviously you need to have some webserver available that can run CGIs, and | >talk to Zope, and (in this case is local to Zope for the file handling to | >work). It doesn't have to be in front of Zope. | > | > | yes, i've seen some similar systems to deal with large file upload | is you product avalaible ? The code is quite old, so I'm currently making sure it still works, and sanitizing it for public consumption. Give me a day or two, to clean it up, add a simple demo, and write up some docs about how to use it. My days are currently consumed with visiting recruiters who are in the way of actual jobs (unfortunately not Zope related ones). -- Andrew Milton akm@theinternet.com.au
Andrew Milton wrote:
+-------[ Tarek Ziad? ]---------------------- | Andrew Milton wrote: | | >The actual submission is to a small CGI that handles updating the status inside | >Zope via XMLRPC (you could also update a response file that the product could | >check as well, but, that's just more files that have to be written to and | >removed), when it's complete it passes in the location of the file(s) to the | >Zope Product so it can process them further (by spawning a worker thread, so | >you don't stop Zope from responding to requests). | > | > | oh k. i am trying to add this directly to the publisher, by providing | a set of api and keeping running request state.
Yeah ugly. I don't think distributing a Product that monkey-patches ZPublisher would be all that warmly received d8)
I was not talking about doing a monkey patch there, but add a feature within the publisher.
| >Part of the product also just draws a status graph giving a message saying | >what is happening and what the progress is, if there's more processing to be | >done (parsing or whatever), the graph can continue to be updated. | > | > | > | nice. in my use case it's a simple progress bar below the form
You could probably do that too using some JavaScript if you wanted, the API is all available in Zope. I'm not a 'front-end' type of guy, my main concern is to make sure it works so that people can put whatever frontend they want on it.
they are two distinctive part to do that: 1/the client side, wich gets asynchronous feedback from the server, that is javascript or whatever. 2/ the server side that keep track of a given request state. (getting data / processing) (that's the missing part, that you probably did with another cgi server on seperate thread)
| >When I said outside the box, I was pretty serious about being outside the box | >d8) Obviously you need to have some webserver available that can run CGIs, and | >talk to Zope, and (in this case is local to Zope for the file handling to | >work). It doesn't have to be in front of Zope. | > | > | yes, i've seen some similar systems to deal with large file upload | is you product avalaible ?
The code is quite old, so I'm currently making sure it still works, and sanitizing it for public consumption. Give me a day or two, to clean it up, add a simple demo, and write up some docs about how to use it. My days are currently consumed with visiting recruiters who are in the way of actual jobs (unfortunately not Zope related ones).
Don't waste your time for me about it, i would just have had a look to see how it's done, but i am not planning to use it soon Regards Tarek
+-------[ Tarek Ziad? ]---------------------- | Andrew Milton wrote: | | >+-------[ Tarek Ziad? ]---------------------- | >| Andrew Milton wrote: | >| | >| >The actual submission is to a small CGI that handles updating the status inside | >| >Zope via XMLRPC (you could also update a response file that the product could | >| >check as well, but, that's just more files that have to be written to and | >| >removed), when it's complete it passes in the location of the file(s) to the | >| >Zope Product so it can process them further (by spawning a worker thread, so | >| >you don't stop Zope from responding to requests). | >| > | >| > | >| oh k. i am trying to add this directly to the publisher, by providing | >| a set of api and keeping running request state. | > | >Yeah ugly. I don't think distributing a Product that monkey-patches ZPublisher | >would be all that warmly received d8) | | I was not talking about doing a monkey patch there, but add a feature | within the publisher. I was referring to my code, not your code d8) | >| >Part of the product also just draws a status graph giving a message saying | >| >what is happening and what the progress is, if there's more processing to be | >| >done (parsing or whatever), the graph can continue to be updated. | >| > | >| > | >| > | >| nice. in my use case it's a simple progress bar below the form | > | >You could probably do that too using some JavaScript if you wanted, the API | >is all available in Zope. I'm not a 'front-end' type of guy, my main concern | >is to make sure it works so that people can put whatever frontend they want on | >it. | > | > | they are two distinctive part to do that: | 1/the client side, wich gets asynchronous feedback from the server, that | is javascript or whatever. | 2/ the server side that keep track of a given request state. (getting | data / processing) | (that's the missing part, that you probably did with another cgi | server on seperate thread) No, I didn't. There's only one CGI to handle the upload. The rest is inside the Zope Product, which tracks the state of each upload. You can call http://example.com/path/UploadManager/uploadId/percentComplete and get a number from 0.0 to 100.0. There's also methods to get error messages etc. I'm just too lazy to write a nifty front-end to it d8) I'm sure someone else will and I can just add that to the codebase... | >The code is quite old, so I'm currently making sure it still works, and | >sanitizing it for public consumption. Give me a day or two, to clean it up, | >add a simple demo, and write up some docs about how to use it. My days are | >currently consumed with visiting recruiters who are in the way of actual jobs | >(unfortunately not Zope related ones). | > | > | > | Don't waste your time for me about it, i would just have had a look to | see how it's done, but | i am not planning to use it soon A few people have expressed interest in it, so I'll get it scrubbed up and released. At least the next time someone asks, there's somewhere to point them to d8) -- Andrew Milton akm@theinternet.com.au
Andrew Milton wrote:
| >Yeah ugly. I don't think distributing a Product that monkey-patches ZPublisher | >would be all that warmly received d8) | | I was not talking about doing a monkey patch there, but add a feature | within the publisher.
I was referring to my code, not your code d8) [cut]
No, I didn't. There's only one CGI to handle the upload. The rest is inside the Zope Product, which tracks the state of each upload. You can call http://example.com/path/UploadManager/uploadId/percentComplete and get a number from 0.0 to 100.0. There's also methods to get error messages etc.
I'm just too lazy to write a nifty front-end to it d8) I'm sure someone else will and I can just add that to the codebase...
ah ok, if i get it right you've patched the publisher to plug your code that let the product get the upload state of a given request. so beside the CGI stuff it's pretty close to what i want to do
| >The code is quite old, so I'm currently making sure it still works, and | >sanitizing it for public consumption. Give me a day or two, to clean it up, | >add a simple demo, and write up some docs about how to use it. My days are | >currently consumed with visiting recruiters who are in the way of actual jobs | >(unfortunately not Zope related ones). | > | > | > | Don't waste your time for me about it, i would just have had a look to | see how it's done, but | i am not planning to use it soon
A few people have expressed interest in it, so I'll get it scrubbed up and released. At least the next time someone asks, there's somewhere to point them to d8)
cool, i'll watch for that :)
+-------[ Tarek Ziad? ]---------------------- | | ah ok, if i get it right you've patched the publisher to plug your | code that let the product get the upload state of a given request. It's one CGI + one Product that handles the upload state. The description in the other email describes it pretty well. There's no hooking into publisher or anything else. I'll clean it up and get it out, then you can see what I did. -- Andrew Milton akm@theinternet.com.au
participants (4)
-
Andrew Milton -
Bruno Grampa -
Tarek Ziadé -
Tino Wildenhain