[Zope] ZClass and Product migration issues
Mark James Adams
mark@raysend.com
Mon, 23 Jul 2001 11:21:15 -0400
--Apple-Mail-881687286-3
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
format=flowed;
charset=us-ascii
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
--Apple-Mail-881687286-3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/enriched;
charset=us-ascii
Hi, Tom:
On Monday, July 23, 2001, at 10:32 AM, "Tom Cameron"
<<tom@mooball.com> wrote:<color><param>0000,0000,DEB7</param>
</color><excerpt>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.
</excerpt>
I asked a similar question a while ago. Here is the response I got
from"Joachim Werner" <<joe@iuveno-net.de>:
<excerpt><color><param>0000,6363,1212</param>And while I'm on that
topic, what are the benefits/tradeoffs
between using the ZMI to define products and using Python?
</color><color><param>0000,0000,DEDE</param>
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, ...)
</color><color><param>0000,6363,1212</param>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.
</color><color><param>0000,0000,DEDE</param>
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
</color></excerpt>
<color><param>0000,0000,DEB7</param>
</color><excerpt>In any case I am expecting that the Product will be
continually evolving.
How are instances affected when new versions of products are installed?
</excerpt>
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 =3D 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!
--=20
Mark James Adams
mark@raysend.com=
--Apple-Mail-881687286-3--