[Zope] ZClass and Product migration issues

[Tom Cameron]

Thanks for the suggestions,

My main concern is that the particular product I am building is likely to
have many hundreds, if not thousands of instances. I dont want to have to
migrate these manually at a later date, and I certainly dont want them to
break with upgrades.

I am leaning towards a Python-based product. It will take longer for me to
do, but hopefully will give me the flexibility I need. I can always
prototype in ZClasses if necessary.

Tom

=> -----Original Message-----
=> From: zope-admin@zope.org [mailto:zope-admin@zope.org]On Behalf Of Mark
=> James Adams
=> Sent: Tuesday, 24 July 2001 1:21 AM
=> To: tom@mooball.com; zope@zope.org
=> Subject: Re: [Zope] ZClass and Product migration issues
=>
=>
=> Hi, Tom:
=>
=> On Monday, July 23, 2001, at 10:32 AM, "Tom Cameron"
=> <tom@mooball.com> wrote:
=>
=>
=> I am starting to experiment with ZClasses, and hopefully
=> eventually Products
=> in Python.
=>
=> I am wondering how easy it is to migrate at a later date.
=>
=>
=> I asked a similar question a while ago. Here is the response I
=> got from"Joachim Werner" <joe@iuveno-net.de>:
=>
=>
=> And while I'm on that topic, what are the benefits/tradeoffs
=> between using the ZMI to define products and using Python?
=>
=> Some of the main reasons to use Python-based products are
=> - much better performance (ZClasses just "emulate" object behaviour; e.g.
=> all sub-objects are actually just put into propertysheets)
=> - being able to do much more things (e.g. calling Python
=> libraries like the
=> Python Imaging Library etc.)
=> - avoiding problems with ZClasses (e.g. acquisition works not quite as
=> advertised, multiple inheritance: base classes can only be defined at
=> creation time and not changed later, inheritance does not work
=> properly for
=> propertysheets defined in ZClass-type base classes, ...)
=>
=> Also, if I decide to go with Python based products, is there any easy
=> way to turn a ZClass defined though the ZMI into a Python product? I'm
=> not to worried about retyping code, but I've defined some fairly large
=> propertysheets that would be annoying to recreate if I were to start
=> from scratch.
=>
=> It is not extremely hard to write a ZClass-to-Python code converter. But
=> AFAIK there is no such beast yet.
=>
=> If you don't need the extra power Python gives you, you might be
=> better off
=> with them. Your programming will be magintudes faster using
=> ZClasses (while
=> the resulting code will be much slower ...), provided that you
=> don't hit the
=> limitations of ZClasses.
=>
=> We at iuveno are facing similar problems and are working at
=> tools for making
=> Zope product creation much easier. Most of it is not ready for
=> use yet. But
=> I'd ask you to tell me what you would expect from a "better Zope product
=> definition framework" or whatever you'd call it.
=>
=> Just to give you an impression about our ideas, here are some of them:
=>
=> - Definition of REAL Python-based classes over the web (like ZClasses);
=> everything I mention below should also work with these new over-the-web
=> classes
=>
=> - Being able to define template-like classes (like "Meta-ZClasses"); e.g.
=> you'd have a predefined "Persons" ZClass and could use it to derive a
=> special "Co-Workers" or "Customers" class by just adding/changing stuff
=>
=> - Wizards for the basic tasks (like creating a new ZClass; you'd
=> not have to
=> click through all the definition tabs after the basic creation of the
=> ZClass); the wizards framework exists already
=>
=> - Defining basic "components" like data class, presentation class, etc.
=>
=> - A forms builder framework (with the help of Martijn Faassen's
=> Formulator,
=> this part is quite advanced already)
=>
=> - being able to define objects from UML tools
=>
=> - roundtrip engineering (from UML tools etc. to Zope and back); there
=> already are tools to get ZClass structures into the Object Domains UML
=> software ...
=>
=> - providing a lot of frequently needed basic modules to the
=> programmer/power
=> user; the Content Management Framework is a basic attempt to do this
=>
=>
=> Cheers
=>
=> Joachim
=>
=>
=>
=>
=> In any case I am expecting that the Product will be continually evolving.
=> How are instances affected when new versions of products are installed?
=>
=>
=>
=> Instances will use your new class definitions. However, new
=> member variables that you add will not be defined in current
=> instances. The trick is to define default values for new
=> variables as class variables, and override them them with
=> self.new_variable = new_value whenever you update them.
=>
=> I switched over to Python products after creating only a couple
=> of ZClasses. While getting off the ground with ZClasses is a lot
=> easier, in the long run you'll be better off with Python
=> products (depending on your level of comfort with Python).
=>
=> If you are interested in getting started with Python classes, I
=> highly recommend Max M's A very minimal Product
=> (http://www.zope.org/Members/maxm/HowTo/minimal_01/) and A
=> Minimal Product - The Sequel
=> (http://www.zope.org/Members/maxm/HowTo/minimal_02/).
=>
=> Once you've gone through these tutorials, read chapter 3
=> (http://www.zope.org/Documentation/ZDG/Products.dtml) of the
=> Zope Developer's Guide (http://www.zope.org/Documentation/ZDG).
=>
=> Assuming you don't have to many methods in your ZClass,
=> converting isn't to hard to do by hand. Just turn all of your
=> Python scripts into methods and each of your DTML
=> documents/methods into files in a 'dtml' folder inside your
=> product folder. Then import them using DTMLFile (Max M. shows
=> you how. Don't forget the .dtml extension on your DTML files!)
=>
=> As far as I'm aware, changing a ZClass over to Python will break
=> all of your existing instances, unfortunately. You could write a
=> script to convert them, blah, blah. But who wants to do that?
=> It's better to do it in Python in the first place (but get to
=> know ZClasses first, just don't put to much work into them).
=>
=> One thing I like about Python classes is the ability to add
=> custom Security Declarations (i.e., defining custom permission
=> names; the Products chapter of the Zope Developer's Guide gets
=> into this).
=>
=> Good luck!
=>
=> --
=> Mark James Adams
=> mark@raysend.com