Comments? To create products with Python or with ZClasses
Hi, Please correct me if any assumptions in here are wrong. (You may not agree with my conclusions, but as long as my assumptions are correct, I'm happy. :) Any other feedback is also welcomed, of course. This document is also here: http://www.zope.org/Members/tazzzzz/PythonOrZClass Kevin http://www.byproducts.com - Humor and Novelties Purpose of this document May 5, 2000. Please send feedback! Zope offers two distinctly different development "environments": Python Products, and built through the web ZClasses. Though you can certainly use both in a single project, you will likely turn to one or the other as a first step when approaching a new problem. I get the feeling that the folks at DC turn to Python first, whereas I turn to ZClasses. This document doesn't go into any background about what a ZClass or Python Product is... I think other docs do that well enough. For the sake of brevity, I'll refer to Python Products as "PyProds". Speed I believe that PyProds and ZClasses are roughly the same in terms of speed of execution. ZClasses have some wrapper stuff around them, but I don't think there is much (if any) extra code that needs to be executed when calling ZClass methods. Development Tools PyProds are clearly at an advantage in terms of development tools. Creating ZClasses and propertysheets, and adding views and methods to a ZClass are certainly very user friendly processes. However, editing code in a textarea has some definite drawbacks. Since PyProds reside in the filesystem, it is very easy to use your favorite editor, CVS, grep and other tools when working with your code. ZClasses will be getting help down the line in the form of the ZopeStudio Mozilla app. Currently, you can edit your code using your favorite editor if it supports FTP. It also seems possible to create some simple tools that allow you to edit your ZClass code locally, store it in CVS, and send the changes through via XML-RPC or ZClient. Flexibility PyProds win in the flexibility department as well. In order to keep evil people from gaining access to your box through your website, through the web components can only do a subset of what Python can do. For example, you can't open files in DTML or a PythonMethod. PyProds live in the file system, and therefore have access to all Python and Zope services. It is also likely to be a lot faster to create a relatively complex object hierarchy in Python than it would be to build it up through the web. A very important flexibility issue with ZClasses is that once you've created the ZClass, there is no guaranteed way to change the base classes. There are apparently some really deep issues behind this. To give yourself the ability to change base classes later on, it is probably wise to create a Python base class for your ZClass and have that class inherit from the appropriate other classes. Then, you can just change that little bit of Python in order to add or remove a base class. This has the added benefit that you can easily make minor additions to your ZClass that would not be possible through the web (such as writing a custom object traversal handler). Ease of Programming Once you get into the swing of it, ZClasses are quite easy. Writing complicated DTML Methods is not necessarily a fun thing, but PythonMethods give you a way to avoid complicated DTML and still develop through the web. The single biggest reason that I don't develop my products in Python is the fact that you need to restart Zope to test your changes. For that reason, it is probably best to test your classes directly from the Python interpreter rather than through Zope. This allows you to see the changes much more quickly. Once you think your classes are basically working, you can fire up Zope and try it from the web. While that method certainly will get the job done, I find programming with ZClasses to be a nice fast process. You can have two browser windows going, one with the code and one where you're testing the code. The process of making a change and trying it out is very fast. I also find that Versions are very nice for minor bug repair on a production system. Conclusions Python is a great language, but I think I'll stick to ZClasses for the bulk of my web development. They really are quite fast and easy, and PythonMethods give you the benefit of using a nice, clean language for your logic as well. I am going to start using Python base classes for my ZClasses though. It is really a very small amount of work to create them, and the benefits are significant: you can easily change base classes and create functionality that is otherwise impossible through the web.
Kevin: <snip wonderful contribution to start a discussion>
Development Tools
PyProds are clearly at an advantage in terms of development tools. Creating ZClasses and propertysheets, and adding views and methods to a ZClass are certainly very user friendly processes. However, editing code in a textarea has some definite drawbacks.
Agreed.
Since PyProds reside in the filesystem, it is very easy to use your favorite editor, CVS, grep and other tools when working with your code.
ZClasses will be getting help down the line in the form of the ZopeStudio Mozilla app. Currently, you can edit your code using your favorite editor if it supports FTP.
I was under the impression that FTP'ing into the a ZClass isn't supported at the moment (I've tried it and it doesn't work still). I would gladly be corrected.
It also seems possible to create some simple tools that allow you to edit your ZClass code locally, store it in CVS, and send the changes through via XML-RPC or ZClient.
Flexibility
PyProds win in the flexibility department as well. In order to keep evil people from gaining access to your box through your website, through the web components can only do a subset of what Python can do. For example, you can't open files in DTML or a PythonMethod. PyProds live in the file system, and therefore have access to all Python and Zope services. It is also likely to be a lot faster to create a relatively complex object hierarchy in Python than it would be to build it up through the web.
A very important flexibility issue with ZClasses is that once you've created the ZClass, there is no guaranteed way to change the base classes.
Ugh. I've been bitten by this too many times to count. *.-| So I am building my Base classes in Python too.
There are apparently some really deep issues behind this. To give yourself the ability to change base classes later on, it is probably wise to create a Python base class for your ZClass and have that class inherit from the appropriate other classes. Then, you can just change that little bit of Python in order to add or remove a base class. This has the added benefit that you can easily make minor additions to your ZClass that would not be possible through the web (such as writing a custom object traversal handler).
Ease of Programming
Once you get into the swing of it, ZClasses are quite easy. Writing complicated DTML Methods is not necessarily a fun thing, but PythonMethods give you a way to avoid complicated DTML and still develop through the web.
The single biggest reason that I don't develop my products in Python is the fact that you need to restart Zope to test your changes.
I there any other was besides the pdb to test you products without restarting zope? I really think that'd be worth me trying. I wouldn't know where to start though. From what I know, Python modules can just use the "reload" command. Why doesn't Zope have that?
For that reason, it is probably best to test your classes directly from the Python interpreter rather than through Zope. This allows you to see the changes much more quickly. Once you think your classes are basically working, you can fire up Zope and try it from the web.
While that method certainly will get the job done, I find programming with ZClasses to be a nice fast process. You can have two browser windows going, one with the code and one where you're testing the code. The process of making a change and trying it out is very fast.
That's my experience as well. No substitute for this in Production where a restart makes Zope look unstable.
I also find that Versions are very nice for minor bug repair on a production system.
MTC, Jason Spisak CIO HireTechs.com 6151 West Century Boulevard Suite 900 Los Angeles, CA 90045 P. 310.665.3444 F. 310.665.3544 Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats.
----- Original Message ----- From: "Jason Spisak" <444@hiretechs.com> To: <zope@zope.org> Sent: Friday, May 05, 2000 3:34 PM Subject: Re: [Zope] Comments? To create products with Python or with ZClasses
ZClasses will be getting help down the line in the form of the ZopeStudio Mozilla app. Currently, you can edit your code using your favorite editor if it supports FTP.
I was under the impression that FTP'ing into the a ZClass isn't supported at the moment (I've tried it and it doesn't work still). I would gladly be corrected.
You're probably right about this. I haven't actually tried it. In that case, ZopeStudio or rolling a system like I mention below are probably good ways to get similar effects.
MTC,
MTC? MIDI Time Code? Kevin
participants (2)
-
Jason Spisak -
Kevin Dangoor