Am Dienstag, den 05.07.2005, 11:05 +0200 schrieb Negroup -:
2005/7/5, Tino Wildenhain <tino@wildenhain.de>: [cut]
So best option I see is to not pass the object but rather pass the reference to the object. You can resolve it via restrictedTraverse('/path/from/form')
I think I can't apply your solution. restrictedTraverse asks for a path, and then it supposes that the object is stored inside ZODB. This is not my case. Let me provide a minimanl explaination about how my application is structured.
1. A user can uploads a zipped file via HTML form in "upload_zip" ZPT. The action of the form points to check_zip, an External Method that checks for validity of each file inside the archive.
2. check_zip returns to upload_zip a tuple containing two elements: True or False (based on the correctness of archive) and the object itself, via self parameter.
3. after the external method has been called, upload_zip shows other 2 forms that the user will use to abort operation or to continue the process. The form to continue will pass the object to another external method in order to compute the result. This is the step where I encounter the problem, I can't pass object.
This should explain why I haven't the object stored inside ZODB.
Probably the solution would be to store the uploaded object inside a temporary area of ZODB and then I'll be able to do all the tasks I need.
Any further consideration/hints?
Well yes, thats very easy. Just store your (compressed or not) HTML data (since its a string after all and not such a complex object) in a hidden form field (base64 encoded for example) -> filedata=htmldata.encode("base64") and the other parts of your form as you wish. Maybe you prepare the data in a script and call the ZPT from it: return context.yourZPT(filedata=filedata,somestatus=whatever) and use: <input type="hidden" tal:attributes="value options/filedata" type="text" /> in your ZPT. When the request returns, use: htmldata=filedata.decode("base64") alternatively you can just store the data in REQUEST.SESSION to keep it on server (but watch the memory usage) -- Tino Wildenhain <tino@wildenhain.de>