developing with zmi: how to move a patch from data from devel to live?
hi, my problem is the following... imagine that you develop something for the customer using zope. while developing you use the ZMI a lot... to set some settings, to create python scripts and so on. you do this on the 'devel' server. then you deliver the solution to the customer (to the 'live' server). you can simply copy the data.fs stuff to the live server. after some time the either customer wants some new features, or there's a bug to fix or something like that. now you create the fix/improvement on the devel server. but now how do you move the improvement/fix to the live server? you cannot just copy the data.fs over. the customer already has some content/data in it... one way seems to be to not use the ZMI at all. you create an install python script, which calls the methods of the ZMI interface. this way works, but it seems for me to waste my time. finding the right method that the gui calls to call it from the install script seems stupid for me. but it solves the problem. with the script i can really make the changes i need on the devel server. so, is there a solution where i can use the ZMI? how do you solve this kind of problem? gabor
On 20 Jun 2005, at 07:35, gabor wrote:
now you create the fix/improvement on the devel server.
but now how do you move the improvement/fix to the live server? you cannot just copy the data.fs over. the customer already has some content/data in it...
one way seems to be to not use the ZMI at all. you create an install python script, which calls the methods of the ZMI interface. this way works, but it seems for me to waste my time. finding the right method that the gui calls to call it from the install script seems stupid for me.
but it solves the problem. with the script i can really make the changes i need on the devel server.
so, is there a solution where i can use the ZMI?
how do you solve this kind of problem?
The problem is that you develop using the ZMI. It's a bad pattern. Don't do it. jens
Jens Vagelpohl wrote:
On 20 Jun 2005, at 07:35, gabor wrote:
now you create the fix/improvement on the devel server.
but now how do you move the improvement/fix to the live server? you cannot just copy the data.fs over. the customer already has some content/data in it...
one way seems to be to not use the ZMI at all. you create an install python script, which calls the methods of the ZMI interface. this way works, but it seems for me to waste my time. finding the right method that the gui calls to call it from the install script seems stupid for me.
but it solves the problem. with the script i can really make the changes i need on the devel server.
so, is there a solution where i can use the ZMI?
how do you solve this kind of problem?
The problem is that you develop using the ZMI. It's a bad pattern. Don't do it.
well, it's the opposite. i (our company) don't develop using the ZMI. i'm using an install script. so when we install our program, no gui editing is needed. but last week i've seen a presentation which used a CMS system called Typo3. and a guy showed us how he can build a CMS only with gui tools. it was very fast and effective. and then i thought.. wow, you can work sooo fast in typo3. and we're so slow to develop with zope (plone/cmf/whatever). and then i remembered. but wait, we don't use the gui tools (zmi) at all! maybe we should! an example: for the next version of the program, we decided to change an action what happens when you click on a TAB in the CMS. in gui, i would do it like this: go to the portal_actions object, find the correct tab, change the python-script associated to it. but we had to dig thru the source code, to find out how the ZMI does it, and follow the same process when we did it programmatically in the python install script. it took us let's say 4-5hours (partly because that part of the CMF was badly documented, and used a quite inconvenient way to handle that) compare that: 1minutes in the ZMI or 5hours in a python-script. which one is better? well, or let me ask the question a different way: if i should not use the ZMI, then why is it there? gabor
On 20 Jun 2005, at 10:16, gabor wrote:
well, or let me ask the question a different way: if i should not use the ZMI, then why is it there?
The ZMI is great for maintenance tasks, but not great for software development. You already ran into the first issue, replicating changes to other machines. Then there is no way to apply sane software development techniques, like using version control software and developing in a team. jens
gabor wrote at 2005-6-20 08:35 +0200:
... but now how do you move the improvement/fix to the live server? you cannot just copy the data.fs over. the customer already has some content/data in it...
This is possible as long you have a strict separation between content (created on the life server) and infrastructure (created in the develoment system). Configuration may be partly controlled in the life and partly in the development system. In this case, you need again a strict separation between these worlds. If this separation respects object boundaries (i.e. no updatable object contains both life and development controlled parts), then you can use Zope's export/import mechanism for the synchronization. The use of "export/import" can be automated as demonstrated by "ZSyncer" (others already suggested this solution). "ZSyncer" integrates a local export and the corresponding remote import in a single Web transaction. However, knowing your application, you can integrate such exports and imports for all your development controlled objects. If the separation crosses object boundaries, you cannot use export/import (as it would vipe out the life controlled parts of the object). We extended the basic "ZSyncer" mechanism to also synchronize partial objects. It essentially works by defining "_zsyncer__getstate__" and "_zsyncer__setstate__" methods that extract and import partial content. @Paul: let me know if you are interested in this ZSyncer extension. -- Dieter
participants (3)
-
Dieter Maurer -
gabor -
Jens Vagelpohl