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... Any advice appreciated.
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. --jcc -- "My point and period will be throughly wrought, Or well or ill, as this day's battle's fought."
----- 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.
Can you explain *wrap it up in filesystem products* ...?
For a Python class to become a Zope object (in Zope 2, at least), it requires all sorts of decoration. At the least, it must inherit from certain Zope classes, provide a web interface, and make security declarations. What you can do is to write a class without all this, and then another one, with a slightly different name (customarily a 'Z' prefix) that inherits that class plus has all the Zope attachment points and signatures and whatnot. You'll also put in those bits of functionality that depend on the Zope API or behaviours. This is sometimes counter-productive or useless; in products that are meant to modify Zope's behaviour, interact closely with the ZODB, or are small or trivial you'll probably want to just write one class/file. But often it gives you a nice separation that you can use to keep things clean or to break the code away from Zope.
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...?
I've never tried to return a naked object from an ExternalMethod. Seems like it might work, but I really can't say. If you can't do this, then you can certainly do it with Zope product that defines a (non-persistent?) object like you want. If you're dealing with a relational database, Zope has a lot of facilities already for that. I'll assume there's some obstacle to using ZSQL objects and/ Zope Database Adaptors. If not, take a look there (especially at Pluggable Brains and the Result object): I've provided links on those in the past, so search the archives. If you want to create a Python product, take a look at the Zope Book http://zope.org/Documentation/Books/ZopeBook/ Boring product http://www.zope.org/Members/gtk/Boring Zope Developer's Guide http://www.zope.org/Documentation/Books/ZDG/current maxm's tutorials http://www.zope.org/Members/maxm/HowTo/minimal_01 http://www.zope.org/Members/maxm/HowTo/minimal_02 and especially mxmEasyProduct http://www.zope.org/Members/maxm/HowTo/easyProduct --jcc -- "My point and period will be throughly wrought, Or well or ill, as this day's battle's fought."
On Thu, 2003-09-04 at 08:12, Erik Myllymaki wrote:
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.
For my money, the single best design decision you can make at this point is to rigidly separate your presentation from your logic. Use Python for logic. Don't do anything more than layout in DTML or ZPT. The transition from HTML delivery to XML (or whatever) delivery will be way easier if all you need to change in Zope is your presentation layer. HTH, Dylan
participants (3)
-
Dylan Reinhardt -
Erik Myllymaki -
J Cameron Cooper