----- Original Message ----- From: "J Cameron Cooper" <jccooper@jcameroncooper.com> To: "Erik Myllymaki" <erik.myllymaki@aviawest.com>; "Zope user list" <zope@zope.org> Sent: Friday, September 05, 2003 6:54 PM Subject: Re: [Zope] zope zen needed...
I have a fairly large intranet site built on Zope. At first it mainly generated reports, but it is starting to be more of a web application then a
reporting
tool and I am thinking I need to make some decisions now about design.
Eventually, I would like my users to be able to access the underlying services with a client other than a web browser. Do I carry on as I am and then build a client that accesses the zope objects via XMLRPC, or do I start making an external python API that I can then access through Zope or my other client(PyQT gui, PyGTK gui, etc.), or...
Depends on your "other clients." Build your server such that they will have easiest access. If you were in the Java world, that would mean exposing things via RMI. In these parts, the best thing for RPC is probably XML-RPC, and since Zope can provide that for free (whereas a separate Python library that would communicate with Zope and the rest of the world would have to have this added), that may be the way to go. But it's not the only way: you may want to consider REST for access to your "web services". It's a natural fit with Zope, existing sites (in general), and almost any thing you might write a client in can surely deal.
http://internet.conveyor.com/RESTwiki/moin.cgi/
And, as a bonus, if you're RESTful in Zope, that stuff is still available via XML-RPC, WebDAV or whatever might be added to Zope (SOAP?) in the future.
Which is not to say that having a Python API is a bad thing either. My (still largely theoretical, granted) approach to the subject: build most of the logic in Python external to Zope (as far as possible), wrap it up in filesystem products, and expose a RESTful layer in Zope. Have your web-app (a display layer) decorate the data from that layer. Not only does this give you tremendous flexibility in data access, it gives you some nice clean lines of separation, and that's usually worth its (imaginary) weight in gold, even if it does take a bit longer to implement than putting everything in the same big heap.
Thanks for this - this is a great bit of advice. Can you explain *wrap it up in filesystem products* ...? Maybe in doing so you will help me answer the following... ...I made some external methods to access a database, make an object out of the results (result.column_names(), result.rows(), result.sql(), etc.) but can't seem to access this result object in the way I would have expected within the DTML of my pages. I little looking around in the archives suggested that external methods are not up to this task for security reasons and I have to make a *full-fledged Zope Product* if I want to access self-made objects in this manner - any further enlightnement on this...? Thanks again.