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