[Zope-dev] hurry.workflow class based work flows.
Hello,
I have been working with hurry.workflow in a project and had some
questions about making hurry.workflow work with different work flows.
For this project each class can have a different work flow with it's own
set of states and transitions. All of the instances of a given class
share the same work flow.
To create these different work flows I have registered a utility for
each class. The utility has a factory that creates instances of
hurry.workflow.workflow.Workflow initialized with the correct set of
transitions for that type. The utilities are named, to allow more than
one utility to register for the hurry.interfaces.IWorkflow interface.
With many IWorkflow utilities the WorkflowInfo implementation can not
find the utility it needs. So I changed the WorkflowInfo behavior by
having it look for a named utility based on the class name of the
instance. For example the work flow utility for the class 'Cat' is
registered with the name project.workflow.Cat which I selected the
pattern project.workflow.{className} to try and avoid naming conflicts.
This solution seems to work well for the project I am working on,
however I am quite new to Zope and this is the first time I've made
these kinds of modifications.
Does anyone have any thoughts about how this implementation could be
improved, it doesn't feel like I'm taking the best advantage of the
component model? If I could come up with a set of patches, would the
change to a class based work flow be useful to include in hurry.workflow?
Regards,
Michael
--
Michael Shaw
Developer
Nunatak Systems Pty Ltd
15 Princes Street
Sandy Bay Tasmania 7005
Australia
P: 61 3 6223 7875
F: 61 3 6226 1887
e: michael.s...@nunatak.com.au
w: www.nunatak.com.au
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] hurry.workflow class based work flows.
Hi, 2009/6/23 Michael Shaw ms...@nunatak.com.au: Hello, Does anyone have any thoughts about how this implementation could be improved, it doesn't feel like I'm taking the best advantage of the component model? If I could come up with a set of patches, would the change to a class based work flow be useful to include in hurry.workflow? I believe this sort of thing has been discussed on grok-dev: http://mail.zope.org/pipermail/grok-dev/2009-May/008052.html Regards, Paul ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Zope Tests: No messages
Summary of messages to the zope-tests list. Period Mon Jun 22 12:00:00 2009 UTC to Tue Jun 23 12:00:00 2009 UTC. There were no messages. ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZODB moved class upgrade script Was: zope.testrunner import location notifications
Hi, On Mon, 2009-06-08 at 09:49 +0200, Christian Theune wrote: Hi, On Tue, 2009-05-26 at 12:42 +0200, Martijn Faassen wrote: Hi there, (in particular Christian Theune) What's the status of the 'import location' notification functionality in zope.testrunner? What's the status of the ZODB migration code? Done. I just released the package `zodbupgrade` on PyPI providing a tool and some documentation how to apply it to your databases I got the idea of also providing a way to describe renames/moves (possibly using entry points for hooking up the declaration) and that can manipulate databases when the code is gone already so we can migrate in one go instead of using intermediate releases. I've released the second version of this tool which I consider stable. It is now called ``zodbupdate``. The major shift is that it allows to provide a pre-defined set of class-renaming rules and can rewrite pickles in ZODBs without having the actual code activated in the Python interpreter. It does this by dis- and re-assembling the pickles. I consider the ZODB migration code project to be finished with this. @Martijn: Did we have a place somewhere in the documentation that needs to be updated to reference this? Cheers, Christian -- Christian Theune · c...@gocept.com gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 7 · fax +49 345 1229889 1 Zope and Plone consulting and development signature.asc Description: This is a digitally signed message part ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] RFC: ZTK custom publications, zope.app.publication, and zope.traversing
On Jun 22, 2009, at 2:51 PM, Martijn Faassen wrote: Jim Fulton wrote: [snip[ I made it possible to override proxying by overriding the proxy method. At this point, I think zope.app.publication provides a pretty reasonable base class for custom publication implementations, although the module arrangement could be made a bit simpler. Cool. :) I propose the following: In phase 1 reduce the scope of zope.traversing: - Move path traversal code to zope.tales I'm very much +1 for anything that moves ZPT-only traversal to places where it's less likely to confuse the reader of the code into thinking it's URL traversal. - Move the URL traversal code used by zope.app.publisher.menu to zope.app.publisher.menu. Refactor it to use the request.publication. Deprecate definition of menu items without permissions. I'm worried about how this affects dependencies. I wouldn't want, say, zope.container, zope.app.pagetemplate and zope.site to start depending on zope.app.publisher where now they depend only on zope.traversing (which is much more lightweight in the dependency department). They wouldn't. They don't use the URL traversal code. Non-URL traversal code would move to zope.tales. zope.container would depend on zope.tales rather than on zope.traversing. If you can do this without making zope.container depend (indirectly) on zope.app.pagetemplate and the like, or, say, zope.site on zope.contenttype, then I'm +1. This means that we shouldn't make zope.traversing depend on zope.app.publisher at any stage, as this would completely screw up all graphs. The dependency for backwards compatibility should ideally be a loose one, not marked in the setup.py dependencies and only required if backwards compatibility is needed. OK. Thoughts? Please do watch those dependencies... The z3c.recipe.depgraph buildout recipe can help you generate dependency graphs. Please watch the scc graphs to see whether you aren't inadvertently creating more cycles. OK. Jim -- Jim Fulton Zope Corporation ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] RFC: ZTK custom publications, zope.app.publication, and zope.traversing
Jim Fulton wrote: They wouldn't. They don't use the URL traversal code. Non-URL traversal code would move to zope.tales. zope.container would depend on zope.tales rather than on zope.traversing. For my own education, I would like to understand why it makes sense for zope.container to depend on zope.tales. This dependency suggests people need to understand ZPT in order to understand container relationships, which seems wrong to me. Shane ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] RFC: ZTK custom publications, zope.app.publication, and zope.traversing
On Jun 23, 2009, at 2:36 PM, Shane Hathaway wrote: Jim Fulton wrote: They wouldn't. They don't use the URL traversal code. Non-URL traversal code would move to zope.tales. zope.container would depend on zope.tales rather than on zope.traversing. For my own education, I would like to understand why it makes sense for zope.container to depend on zope.tales. This dependency suggests people need to understand ZPT in order to understand container relationships, which seems wrong to me. Because it provides traversal adapters needed soley by zope.tales. Keep in mind that these adapters are currently for interfaces defined by zope.traversing, but these interfaces are only (or should only be) used by zope.tales. Of course, these adapters could be moved elsewhere. In fact, it would be best to move these adapters to zope.tales as well, as they will work for any mapping object, not just containers. There are also publishing adapters in zope.container that could probably move elsewhere, since they too will work with any mapping. I suspect when I really wade into this, I'll be able to propose some other cleanups. Jim -- Jim Fulton Zope Corporation ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] RFC: ZTK custom publications, zope.app.publication, and zope.traversing
Jim Fulton wrote: On Jun 23, 2009, at 2:36 PM, Shane Hathaway wrote: Jim Fulton wrote: They wouldn't. They don't use the URL traversal code. Non-URL traversal code would move to zope.tales. zope.container would depend on zope.tales rather than on zope.traversing. For my own education, I would like to understand why it makes sense for zope.container to depend on zope.tales. This dependency suggests people need to understand ZPT in order to understand container relationships, which seems wrong to me. Because it provides traversal adapters needed soley by zope.tales. Sorry, you lost me on the first sentence (and the rest doesn't make sense yet to me as a result). You first said that zope.container is going to depend on zope.tales. Now you're saying zope.tales is going to depend on zope.container. If you meant the latter, then I understand. :-) Shane ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] RFC: ZTK custom publications, zope.app.publication, and zope.traversing
On Jun 23, 2009, at 3:02 PM, Shane Hathaway wrote: Jim Fulton wrote: On Jun 23, 2009, at 2:36 PM, Shane Hathaway wrote: Jim Fulton wrote: They wouldn't. They don't use the URL traversal code. Non-URL traversal code would move to zope.tales. zope.container would depend on zope.tales rather than on zope.traversing. For my own education, I would like to understand why it makes sense for zope.container to depend on zope.tales. This dependency suggests people need to understand ZPT in order to understand container relationships, which seems wrong to me. Because it provides traversal adapters needed soley by zope.tales. Sorry, you lost me on the first sentence (and the rest doesn't make sense yet to me as a result). You first said that zope.container is going to depend on zope.tales. Now you're saying zope.tales is going to depend on zope.container. If you meant the latter, then I understand. :-) Where did I say that zope.tales is going to depend on zope.container? It would have been more precise if I has said that it provides traversal adapters used soley by zope.tales. zope.containers provides adapters to do path traversal. ZPT is the only thing that does path traversal. Jim -- Jim Fulton Zope Corporation ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] The future of Zope{2, 3} and Plone in Debian and Ubuntu
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Fabio Tranchitella wrote:
Zope 2 and Plone
Zope 2 and Plone are obviously related, so the future of one of the two
influences the other one.
The main problem for Zope2 is that the current stable upstream branch
(2.12) still requires python2.4.
Incorrect: Zope 2.12 is supported only on Python 2.5 / 2.6. The
INSTALL.rst[1] file says:
Prerequisites
-
System requirements when building from source
- A supported version of Python, including the development support if
installed from system-level packages. Supported versions include:
* 2.5.x, (x = 4)
* 2.6.x
- Zope needs the Python ``zlib`` module to be importable. If you are
building your own Python from source, please be sure that you have
the headers installed which correspond to your system's ``zlib``.
- A C compiler capable of building extension modules for your Python
(gcc recommended).
This is not acceptable in Debian and
Ubuntu, and Zope 2 is right now the only stopper for the removal of
python2.4 from both Debian and Ubuntu.
Even worse, the current stable Plone releases requires Zope 2.10, which we
suppose will never support anything but python2.4 in the foreseeable
future. The new major upstream branch (Plone 4) is still far from being
released, which means
that the only way to support Plone and Zope 2.x in Debian and Ubuntu is to
keep python2.4 in the distribution.
Plone 4.0 is slated be released this year, with an explicit goal of
running on Zope 2.12 / Python 2.{5,6}][1].
For this reason, together with the upstream suggestions to use the unified
installer and zc.buildout as primary tools for deploying Zope 2 and Plone,
the Debian/Ubuntu Zope Team decided to drop support for Zope 2, Plone and
all the other Zope 2 products. We will file requests of removal for all the
Zope and Plone packages from the archive.
In the short term, I would just update the existing packages to use
Python 2.5, which is known to work with Zope 2.10.
[1] http://svn.zope.org/Zope/branches/2.12/doc/INSTALL.rst?view=auto
[2] http://article.gmane.org/gmane.comp.web.zope.plone.teams.framework/2767
Tres.
- --
===
Tres Seaver +1 540-429-0999 tsea...@palladion.com
Palladion Software Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFKQTj2+gerLs4ltQ4RAksHAJoDgFLtBHjATSgNhIstWOjWeHSuAgCfevxM
v0hySbVNf1nbrL8GzyBqKcU=
=w/ik
-END PGP SIGNATURE-
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] The future of Zope{2, 3} and Plone in Debian and Ubuntu
On Tue, 23 Jun 2009 16:15:12 +0200, Fabio Tranchitella wrote: Hello all! In the last couple of weeks Brian Sutherland, Matthias Klose and I worked together to improve the Zope packaging for Debian and Ubuntu. This e-mail summarizes the problems we faced, the decisions that have been taken and the changes that we will upload to experimental and unstable in the next weeks. Short summary = We switch from a monolithic Zope 3 package to individual packages for the libraries that are part of the ZTK (Zope Toolkit). Zope instance management tools are not supported anymore, as we suggest the use of WSGI. We also drop support for Zope 2 and Plone in Debian and Ubuntu, asking for the removal of the packages from the distribution. I am certainly one person that did use the Debian packages at the time when people first started to suggest against it. I dropped this habit when I needed to work most of the time with custom Zope and Plone versions that were too new or too rare to be in Debian yet. But I'm still using Debian's python2.4 right now to bootstrap my buildouts. The main problem for Zope2 is that the current stable upstream branch (2.12) still requires pthon2.4. This is not acceptable in Debian and Ubuntu, and Zope 2 is right now the only stopper for the removal of python2.4 from both Debian and Ubuntu. What's the reason for the removal of python2.4? Is there a technological reason, or is this a policy decision? Don't forget that Plone users, who are also the biggest consumer group of Zope / ZTK, still will be users of 2.4 for a while. The unified installer is not the only installation method used for Plone, in fact many users and the majority of deployments use python + buildout. These users will need to read documentation and do installation to be able to bootstrap their buildout, which is not exactly a reason for them to choose Debian / Ubuntu in this case. -- Balazs Ree ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] The future of Zope{2, 3} and Plone in Debian and Ubuntu
Hello, * 2009-06-24 07:30, Balazs Ree wrote: What's the reason for the removal of python2.4? Is there a technological reason, or is this a policy decision? Don't forget that Plone users, who are also the biggest consumer group of Zope / ZTK, still will be users of 2.4 for a while. The unified installer is not the only installation method used for Plone, in fact many users and the majority of deployments use python + buildout. These users will need to read documentation and do installation to be able to bootstrap their buildout, which is not exactly a reason for them to choose Debian / Ubuntu in this case. We already have python2.5 and python2.6; after the release of stable (either Debian or Ubuntu), we have to provide security support for all the packages, and supporting three different versions of python is too much work. -- Fabio Tranchitella http://www.kobold.it Free Software Developer and Consultant http://www.tranchitella.it _ 1024D/7F961564, fpr 5465 6E69 E559 6466 BF3D 9F01 2BF8 EE2B 7F96 1564 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
