[Zope] Can Zope Do....?

[Paul Winkler]

On Thu, Dec 02, 2004 at 12:05:09PM -0500, Alan Snyder wrote:
> I'm in love with zope from what i've seen of this Elvis Sightings
> interactive demo. It's so friggin' easy to build functionalities into
> pages. Holy smokes!!

I remember that feeling, so many years ago :-)

> Before I go further with this, I have some questions...
> 
> 1) I am creating all of these pages through the zope manager interface
> which is great, but is it possible, and if so how, to do what I'm
> doing here and update a client remotely through something like a CVS
> or some pre-packaged zope update? Is it a matter of just copying files
> and such from a folder (like the parent elvis sightings folder), or do
> i need to grab stuff from different zope config areas and work it.
> Bottom line - is there any synchronization or update mechanisms
> available that let me develop and fix sites locally and effect those
> changes on a remote server, i.e. at a client?

There are a couple ways...
If you are attached to working in the Zope Management INterface (ZMI)
and storing your code and templates in the ZODB, you can use
ZSyncer (zsyncer.sf.net) to copy live objects from one running zope
to another. However, this is just data transfer, it is NOT a substitute
for a revision control system.

To leverage your existing development tools, including CVS/SVN/whatever,
I highly recommend reading this:
http://plope.com/Members/chrism/zope_collab/view?searchterm=collaborative
... including the comments which have good points about maintenance
after deployment.

> 2) I saw in one of the chapters that each page can reference a
> template (like standard_template.something)... This looks really cool
> for giving a similar layout to pages in a "folder". Can sub-folder
> templates "over-ride" parent folder templates. 

yes.

> In other words, if i
> copy the "standard_template" file to a sub folder and slightly modify
> it will that version be picked up by those folder's pages, or will the
> parent version be used?

The former. 
the magic of acquisition means that you look in the immediate container
first, then its parent, all the way back up to the root.
(and then in any other stuff in context, but that's an advanced
topic.)

> 3) What are the items in that drop down list of things in the upper
> right corner of every folder called? It has stuff like "DTML Document,
> Mai Host..." Are those "products"? Where can I find more of those.
> They're wonderful. Also - how hard are they to install at a client?

For Products defined in fileystem code, typically all you have
to do is give your client a zip or tarball of one folder, which they
unpack place into $INSTANCE_HOME/Products, restart Zope, and they're done.

> What mechanisms are available for producing "install scripts" for
> clients who want to use the stuff I build?

If your Product needs to do more than just register itself as startup -
e.g. you want the client to end up with one or more instances of this
product and maybe do some configuration of other objects in the zodb -
that can be scripted. This is common with "Tools" for CMF (and its
descendants like Plone and CPS), which typically need to be installed
into a particular CMF instance and do some configuration on it.
To do this, the tool author usually provides an Extensions/Install.py
"external method". All the user has to do is go into their 
CMF/Plone/CPS/whatever instance, add an External Method with a 
module name of NameOfTheTool.Install and a function name of "install".
Click Test and everything in your install function gets done.


I guess the "canonical" example of this is CMFCalendar, which comes
with CMFDefault.  You could also look at my CMFBoringTool example
code which you can download from zope.org.

Another possibility, if you want to give your clients
a bunch of ready-made objects is to create them in your own zope in a folder,
export that folder, and send the clients the resulting .zexp file.
Personally I'd prefer to have my install code generate everything
needed instead so i can keep it under revision control.

-- 

Paul Winkler
http://www.slinkp.com