what is your opinion of zope?

[Avery Warren]

I am investigating converting a wiki site to plone. I am having
a lot of difficulty finding good documentation programmatically
accessing the ZODB API.

A lot of the user feedback is centered on how difficult it is to
get good documentation on developing using these technologies. My
question to comp.lang.python is "what is your opinion of zope?"

For those who don't know, zope is a web application server for
python developers.

 

[Terry Hancock]

I am investigating converting a wiki site to plone. I am having
a lot of difficulty finding good documentation programmatically
accessing the ZODB API.

Well, it's really pretty straightforward to use, but you should be
able to find sufficient documentation on the zope.org site. Try
searching for "zodb" and "standalone zodb".

However, I'm not sure why you want this information. If you are
trying to import data into Zope, you are more likely going to be
using Zope, not accessing ZODB directly.

A lot of the user feedback is centered on how difficult it is to
get good documentation on developing using these technologies. My
question to comp.lang.python is "what is your opinion of zope?"

Well, I use it an awful lot. I manage all of my websites using (plain)
Zope. The largest Python projects I've been working on are Zope
applications. It seems to be a very useable framework. I've never
tried Plone, so I won't respond to that part.

It's biggest problem is that it is a *framework* (as opposed to a "toolkit"),
so it requires you to "think in Zope" when developing for it. This is
a criticism of Zope 2.x. This makes for a very steep learning curve.

There's also a lot of the framework which doesn't work very well (e.g.
Sessions? IIRC), and is largely unused. This creates red-herrings which
are also a problem for new users. There are two competing template
languages (DTML and ZPT), both of which were invented for Zope. OTOH,
there are standalone ZPT implementations (not so for DTML), and ZPT
seems to be taking the prefered new language.

It appears from what little I've played with it that Zope 3 will go a long
way towards rectifying this problem by moving to a "component"
architecture. Zope 3 will still be a framework, but you will have
much more control over which parts you use and it will be easier
to use 3rd party (and stdlib) modules with it. That is to say, Zope 3
will have a lighter framework with more of the 2.x framework moved
into "components" --- making it more like a toolkit.

I think that's a terrific idea. I still have not really started testing Zope 3
in ernest, though, so I can't really report my experience with it. I have
used the "interface" and "schema" modules from it, and I've been
very happy with using those to establish interfaces in my own software.
(This makes it much easier to delineate "plugins" or places in your
code where 3rd party development can be done, without requiring
the developer to understand your entire application in order to be
able to contribute --- if you are hoping for contributions from
user-developers on a free-software application, then this has to be a
good idea).

Without more specifics about what you are looking for, it would be
hard to reply further than this.

Cheers,
Terry

 

[Mir Nazim]

http://www.zope.org/Wikis/ZODB/FrontPage/guide/index.html
This should solve this problem.

 

[Avery Warren]

The real problem is that the version of wiki we currently use
doesn't support any concept of workflow. That is fine for the
company now but as it matures in its processes, a more mature
solution will become more and more compelling.
Various solutions include...

1. The current wiki implementation is open source, modify the
freely available and unencumbered code to support workflow.

2. Convert the wiki files to plone documents that are already
workflow enabled.

3. Write a new app that uses the current wiki docs but with the
desired features.

My inquiry to comp.lang.python is part of this investigation. I'm
guessing that writing a zope application would be mandatory
for option 2 and a desireable possibility for option 3. I'm also
just curious as to the viability of zope from a developer's perspective.

 

[Terry Hancock]

The real problem is that the version of wiki we currently use
doesn't support any concept of workflow. That is fine for the
company now but as it matures in its processes, a more mature
solution will become more and more compelling.

I don't think you quite understood my response: I wasn't asking
why you were interested in Zope, but rather why you think you
need to access ZODB directly to do what you want. It's very
unlikely that you do. Usually with Zope, you never really have
to think about the ZODB, you just know it's there, and that's
about it.

More probably, you can import what you need by scripting on top
of Zope. Then Zope takes care of talking to the ZODB for you.

While it may be technically feasible to write a script to translate files
from another source and put them directly into the ZODB database,
it probably means reinventing the wheel quite a bit.

I think you probably should be looking at how to do what you need
with Zope scripts.

ZWiki, for example, uses a pretty simple "file format" (this is technically
a bit of a fiction since "files" in Zope are really just objects in the ZODB),
which I think is defined by the Wiki standard (it resembles "structured
text" in any case --- I'm uncertain whether they are actually the same
or not).

Assuming that the format is the same as in other Wiki packages (and
I think it is), this *could* be as simple as FTPing the files into Zope's
FTP interface.

Or, at a slightly more complex level, manually adding each wiki page
object.

Or, creating a script using Zope's through-the-web interface to recursively
copy your old site using ZWiki page objects. There could be some gotchas
in there, but this is almost certainly going to be better than trying to access
the ZODB directly.

I can understand that this would not be your expectation if you were
used to SQL-backed systems. With those, the SQL back end is often
going to be a better interface point. But it's different with ZODB and Zope.

Perhaps more importantly, I think this task will be easier than you
are expecting it to be --- I'd hate for you to waste a lot of time on a
complicated solution when a "quick and dirty" one will do.

And of course, by this, I meant to go beyond what I already said. I don't
mind telling you I like Zope and/or what I use it for, but it's a big
subject! ;-)