+-------[ Tarek Ziad? ]----------------------
| Andrew Milton wrote:
| >+-------[ Tarek Ziad? ]----------------------
| >| Andrew Milton wrote:
| >| 
| >| >The actual submission is to a small CGI that handles updating the status 
| >| >Zope via XMLRPC (you could also update a response file that the product 
| >| >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 
| >| >Zope Product so it can process them further (by spawning a worker thread, 
| >| >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 
| >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 
| >| >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 
| >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
and get a number from 0.0 to 100.0. There's also methods to get error messages 

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
Zope maillist  -  Zope@zope.org
**   No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-dev )

Reply via email to