Good Object-Oriented Design Approaches For Zope Development?
Hello Everyone, I am VERY new to Zope development, having come from a mainstream Java Struts and Perl CGI web development background. I've been looking at the source code for various Zope Products and applications, and haven't seen a lot of classes used. The applications and Products I've seen define one or two application or Product classes, and consist of a lot of ZPT's that are essentially forms paired with, or posting to, PythonScripts. I wonder - am I missing something? It seems like the applications are organized almost exclusively around ZPT's and PythonScripts, with no use of business objects/classes, for example. Is this the unusual approach? Can anyone point me towards some applications that are considered well designed - make good use of programmer defined (espcially domain) classes? How about some articles on good Zope application design practices? Thanks!
On Thursday 20 May 2004 10:19 pm, Allan Miller wrote:
The applications and Products I've seen define one or two application or Product classes, and consist of a lot of ZPT's that are essentially forms paired with, or posting to, PythonScripts. I wonder - am I missing something? It seems like the applications are organized almost exclusively around ZPT's and PythonScripts, with no use of business objects/classes, for example. Is this the unusual approach?
I think you'll find it's fairly common for products that started life as ad-hoc collections of scripts created using the "through-the-web"=TTW interface. And because that's pretty easy, it wouldn't surprise me to find a lot of them. But there are certainly some very popular products that use OO design. And Zope itself is very OO.
Can anyone point me towards some applications that are considered well designed - make good use of programmer defined (espcially domain) classes? How about some articles on good Zope application design practices?
Please understand that I'm probably at least as clueless about Java as you are about Python. ;-) So I'm not sure I totally follow you -- there are somewhat different object-oriented design philosophies that prevail in the Python community compared to the Java community. And some terminology doesn't translate well. In Python you'll find that objects (specifically "class instances") are sometimes used where you would probably use a class in Java. There's less distinction between the two in Python, since objects can dynamically add and remove methods and attributes. The "Interface" concept has been introduced into Zope and is used to fill the role of what you might call an "abstract class". I don't know about "considered well designed", but my VarImage product (SF download available from: http://sourceforge.net/projects/narya-project ) is a fairly small example of an object-oriented Zope product (at least it's more OO than your description of products you've seen). It also demonstrates a simple form of component architecture to handle operator plugins -- kind of an experiment I used to teach myself the concept, actually. There's also the "poll" example in the ZDG and some other tutorial products that demonstrate the general approach I've used. (Narya itself is a much larger OO product, but as it's not yet functional, I wouldn't recommend it as an example -- too many broken things). No doubt other people can find other examples of OO product design. You will of course, want to check out the products that come bundled with Zope -- I suspect most of those would qualify, too. Cheers, Terry -- Terry Hancock ( hancock at anansispaceworks.com ) Anansi Spaceworks http://www.anansispaceworks.com
On Thursday 20 May 2004 11:21 pm, Terry Hancock wrote:
On Thursday 20 May 2004 10:19 pm, Allan Miller wrote:
The applications and Products I've seen define one or two application or Product classes, and consist of a lot of ZPT's that are essentially forms paired with, or posting to, PythonScripts. I wonder - am I missing something? It seems like the applications are organized almost exclusively around ZPT's and PythonScripts, with no use of business objects/classes, for example. Is this the unusual approach?
I think you'll find it's fairly common for products that started life as ad-hoc collections of scripts created using the "through-the-web"=TTW interface. And because that's pretty easy, it wouldn't surprise me to find a lot of them. But there are certainly some very popular products that use OO design. And Zope itself is very OO.
Can anyone point me towards some applications that are considered well designed - make good use of programmer defined (espcially domain) classes? How about some articles on good Zope application design practices?
Please understand that I'm probably at least as clueless about Java as you are about Python. ;-) So I'm not sure I totally follow you -- there are somewhat different object-oriented design philosophies that prevail in the Python community compared to the Java community. And some terminology doesn't translate well.
In Python you'll find that objects (specifically "class instances") are sometimes used where you would probably use a class in Java. There's less distinction between the two in Python, since objects can dynamically add and remove methods and attributes. The "Interface" concept has been introduced into Zope and is used to fill the role of what you might call an "abstract class".
I don't know about "considered well designed", but my VarImage product
(SF download available from: http://sourceforge.net/projects/narya-project )
is a fairly small example of an object-oriented Zope product (at least it's more OO than your description of products you've seen). It also demonstrates a simple form of component architecture to handle operator plugins -- kind of an experiment I used to teach myself the concept, actually.
There's also the "poll" example in the ZDG and some other tutorial products that demonstrate the general approach I've used.
(Narya itself is a much larger OO product, but as it's not yet functional, I wouldn't recommend it as an example -- too many broken things).
No doubt other people can find other examples of OO product design. You will of course, want to check out the products that come bundled with Zope -- I suspect most of those would qualify, too.
Cheers, Terry
-- Terry Hancock ( hancock at anansispaceworks.com ) Anansi Spaceworks http://www.anansispaceworks.com
Terry - thanks for your clear, helpful, and very thought-provoking response. I will definitely look at the resources you mentioned in your message. What you wrote made me see that I have to learn to start "thinking in Zope," understand specific Zope idioms and approaches to problem solving. I think my original question wasn't specific enough. Perhaps an example would would make things clearer. One category of products I looked at were Zope discussion board products. I expected to see classes such as User, Forum, Posting, etc., that model the objects that comprise a discussion board. Instead, I often saw a ZPT form for adding a user, and a PythonScript - something like addUser.ps - that builds a dictionary of user properties (username, password, country, etc.) and adds it to the container (folder?) in which the PythonScript resides. Maybe I need to get used to the idea of systems being built around Zope in folders, but I was looking for at least a User object to encapsulate the properties that were stored in the dictionary, as well as some methods to access them and model User "behaviors." I'm not trying to be an abstract O-O "purist," I just think that having classes that reflect the problem domain makes it a lot easier to understand, and hence modify or extend the system. Thanks again for your response.
On Thu, 20 May 2004 23:48:44 -0700 Allan Miller <amiller@a2software.com> wrote: [..]
Terry - thanks for your clear, helpful, and very thought-provoking response. I will definitely look at the resources you mentioned in your message. What you wrote made me see that I have to learn to start "thinking in Zope," understand specific Zope idioms and approaches to problem solving.
I think my original question wasn't specific enough. Perhaps an example would would make things clearer. One category of products I looked at were Zope discussion board products. I expected to see classes such as User, Forum, Posting, etc., that model the objects that comprise a discussion board. Instead, I often saw a ZPT form for adding a user, and a PythonScript - something like addUser.ps - that builds a dictionary of user properties (username, password, country, etc.) and adds it to the container (folder?) in which the PythonScript resides. Maybe I need to get used to the idea of systems being built around Zope in folders, but I was looking for at least a User object to encapsulate the properties that were stored in the dictionary, as well as some methods to access them and model User "behaviors." I'm not trying to be an abstract O-O "purist," I just think that having classes that reflect the problem domain makes it a lot easier to understand, and hence modify or extend the system. Thanks again for your response.
In Zope there are basically two modes of development: - Instance space development (as you describe above) takes existing "framework" objects like folders, files, property sheets and glues them together with templates and scripts. Also many instance space apps use relational databases to store and retrieve data via ZSQL methods. - Filesystem product development describes the model using classes, by inheriting from framework classes rather than just reusing instances. There is also an instance-space way to do this via ZClasses, but these are best avoided IMO. On top of these model classes, templates and scripts are used for the "view" and "controller" aspects of your application. These scripts and templates are typically "environmentally inherited" using Zope acquisition. The CMF contains a "skins" mechanism which formalizes this a bit more and makes it more controllable. Most problems can be mapped to either space. In general instance space is good for prototyping or one-off mini applications. Products are best for generalized components (or even whole applications) that can be reused. The two techniques are often (maybe even always?) used together in Zope. You start with a filesystem model and layer policy and look and feel on top of it using templates and scripts. These scripts can be in the ZODB or the file system (if you use CMF skins). To use Zope effectively you must know both techniques. Often people start with instance space dev and either never leave it or move on to filesystem coded products. The latter is more formalized and thus may better fit what you may be used to from Java. Pretty much all of it is more formal and structured then Perl CGI ;^) hth, -Casey
As a Java developer for several years and Python/Zope developer for about half a year I would advise you to look at the file-system-based approach with ZPT. This comes closest to Java-style programming. You can use classes, unit tests, assertions, what-have-you with this approach. Be aware, that in Python files represent modules, while in Java they represent classes. Thsi may cause confusion. For the rest, get used to Python with the help of the cookbook ("pattern catalog"): http://aspn.activestate.com/ASPN/Python/Cookbook/ and don't forget that Python is much more dynamic than Java, with all its pros and cons. regards Andre Casey Duncan wrote:
On Thu, 20 May 2004 23:48:44 -0700 Allan Miller <amiller@a2software.com> wrote: [..]
Terry - thanks for your clear, helpful, and very thought-provoking response. I will definitely look at the resources you mentioned in your message. What you wrote made me see that I have to learn to start "thinking in Zope," understand specific Zope idioms and approaches to problem solving.
I think my original question wasn't specific enough. Perhaps an example would would make things clearer. One category of products I looked at were Zope discussion board products. I expected to see classes such as User, Forum, Posting, etc., that model the objects that comprise a discussion board. Instead, I often saw a ZPT form for adding a user, and a PythonScript - something like addUser.ps - that builds a dictionary of user properties (username, password, country, etc.) and adds it to the container (folder?) in which the PythonScript resides. Maybe I need to get used to the idea of systems being built around Zope in folders, but I was looking for at least a User object to encapsulate the properties that were stored in the dictionary, as well as some methods to access them and model User "behaviors." I'm not trying to be an abstract O-O "purist," I just think that having classes that reflect the problem domain makes it a lot easier to understand, and hence modify or extend the system. Thanks again for your response.
In Zope there are basically two modes of development:
- Instance space development (as you describe above) takes existing "framework" objects like folders, files, property sheets and glues them together with templates and scripts. Also many instance space apps use relational databases to store and retrieve data via ZSQL methods.
- Filesystem product development describes the model using classes, by inheriting from framework classes rather than just reusing instances. There is also an instance-space way to do this via ZClasses, but these are best avoided IMO. On top of these model classes, templates and scripts are used for the "view" and "controller" aspects of your application. These scripts and templates are typically "environmentally inherited" using Zope acquisition. The CMF contains a "skins" mechanism which formalizes this a bit more and makes it more controllable.
Most problems can be mapped to either space. In general instance space is good for prototyping or one-off mini applications. Products are best for generalized components (or even whole applications) that can be reused. The two techniques are often (maybe even always?) used together in Zope. You start with a filesystem model and layer policy and look and feel on top of it using templates and scripts. These scripts can be in the ZODB or the file system (if you use CMF skins).
To use Zope effectively you must know both techniques. Often people start with instance space dev and either never leave it or move on to filesystem coded products. The latter is more formalized and thus may better fit what you may be used to from Java. Pretty much all of it is more formal and structured then Perl CGI ;^)
hth,
-Casey
_______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
On Thu, 20 May 2004 23:48:44 -0700 Allan Miller <amiller@a2software.com> wrote:
I think my original question wasn't specific enough. Perhaps an example would would make things clearer. One category of products I looked at were Zope discussion board products. I expected to see classes such as User, Forum, Posting, etc., that model the objects that comprise a discussion board. Instead, I often saw a ZPT form for adding a user, and a PythonScript - something like addUser.ps - that builds a dictionary of user properties (username, password, country, etc.) and adds it to the container (folder?) in which the PythonScript resides.
Yes, and I agree that this is bad design. It is not uncommon, but not very Zope-ish, and there is nothing in Zope that makes this a good idea.
Lennart Regebro wrote:
Yes, and I agree that this is bad design. It is not uncommon, but not very Zope-ish, and there is nothing in Zope that makes this a good idea.
Depends whether you like lightweight or heavyweight design. I quite like using PropertyManagers (File's usually) and BTreeFolder2's and then scripting the rest... Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Allan Miller wrote:
I am VERY new to Zope development, having come from a mainstream Java Struts and Perl CGI web development background. I've been looking at the source code for various Zope Products and applications, and haven't seen a lot of classes used.
For applications, you won't see too many classes. Products are usually built using classes though...
The applications and Products I've seen define one or two application or Product classes, and consist of a lot of ZPT's that are essentially forms paired with, or posting to, PythonScripts.
That's about right.
I wonder - am I missing something? It seems like the applications are organized almost exclusively around ZPT's and PythonScripts, with no use of business objects/classes, for example. Is this the unusual approach? Can anyone point me towards some applications that are considered well designed - make good use of programmer defined (espcially domain) classes? How about some articles on good Zope application design practices?
Can't help there really. In Zope, you can be as regid or as flexible as you want with your development. If you want formality, lots of classes, etc, then you can develop a disk-based python product to solve your problem. This is more powerful (not always a good thing) but often slower to develop. The more pragmatic approach used by most Zope developers is to re-use standard Zope objects in new and interesting ways (ZCatalog, Folders, BTreeFolder2's and PropertyManagers are your friends here) and tie them together with scripts and page templates organised using folders and obtained using Acquisition. cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
participants (6)
-
Allan Miller -
Andre Meyer -
Casey Duncan -
Chris Withers -
Lennart Regebro -
Terry Hancock