[Zope] replicating stand-alone applications

[Paul Winkler]

On Wed, Oct 31, 2001 at 02:54:18PM -0800, Jerry McRae wrote:
> 1) Are the good, easy, or best way of moving or accessing a Python
> container class from a stand alone program?  The class has several
> attributes which are containers for any number of sets of complex
> structures.  Example of accessing a specific row/ column element
> directly (which I don't really do) would be:
>  Myclass.payRates['normal']['level']['table'][1,1]
> and with the Myclass.operators array, the list of objects it would
> contain would have a different format.

you lost me there... what's Myclass.operators?
 
> My idea was just to read the class in an External Method from the pickle
> file it is stored in, then have some Zope scripting to pass parameters
> to the method telling it which array to return.  But would this cause a
> re-un-pickle each time the External Method is called?

Yes. You could avoid this by wrapping your class in a Product. It's
not hard - I've done this a number of times by wrapping the Boring
product around a python class. Then your user interface just becomes
1) a web page which creates an instance of this product, and 2) one or
more pages which let the user interact with the instance. Unpickling
would only need to happen at stage 1, and if your product is
persistent, the object will still be there if the user interrupts the
session and comes back later. (Of course, if the user never explicitly
deletes the object, you eventually need some housecleaning, but that's
another issue.)

> I have not found any products, messages, or how-to's that address these
> next two questions that I have.  Are they even *possible* from a web
> application, even if the client is assured of having Python?

If the client is assured of having python, I'd bet *anything* is
possible.

> 2) I would like the option of reading the input file and permanent files
> from the *users* local hard drive, and the same for writing the output
> and permanent (modified) file.

Even without client-side python, reading is easy - just use a file
upload form. If you don't want to use an upload form in a browser,
then you need client-side programming, because HTTP defines no way to
programmatically get at the filesystem on the client side (what a
nightmare that would be!). For writing, without client side
programming, you could just store the output in Zope and give the user
a download form to get at it. You might be able to avoid saving the
output in Zope, by setting it up so that the output is streamed as
some MIME type that would (hopefully) cause the client's browser to
prompt "What do you want to do with this file?" - and then if they
click "save to disk" it'll just stream it to a file. I haven't tried
that myself.

With client side programming, you wouldn't need a browser at all.  If
your app is simple it shouldn't be too hard to write a Tkinter (or
whatever) GUI and user httplib to handle communication with the
server.
 
> 3) The calculation process is intense and could be long (1-10 hours).
> The *ideal* solution would be to have the calculation program running on
> the clients computer.  That way it isn't dependent on nor bogging down
> the server.  I would just have to pass the complex structure of
> parameters and arrays to the browser's computer.  Any ideas?

If the user has python installed, httplib should be all you need to
interact with the server.

If not, you could conceivably use jython to run applets in a browser,
but after all the web pages I've had crash various browsers on me,
I've avoided this kind of client-side programming like the plague. I
certainly wouldn't try to do a 10-hour number crunch in a browser.

I'm not sure how well I understood your application... hope I'm not
too far off base.

--

paul winkler
home:  http://www.slinkp.com
music: http://www.reacharms.com
calendars: http://www.calendargalaxy.com