+-------[ 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