I am not an expert and I've never developed a big "pure Zope 3" application,
but I have consumed a lot of Zope 3 ilbraries and concepts, from Plone on
Zope 2, and mostly that's been a pleasant experience. Zope 3 is incredibly
advanced and powerful. The concepts take some time to get used to if you are
new to it all, but as far as I'm concerned, it's miles ahead of most of the
competition in terms of architecture and specifically code re-use. 

Of course, you may find that the learning curve outweighs the benefits,
though if you've got Philipp's book, and it makes sense, that's probably a
good gauge.

Stefan Krumbiegel (Galileo Press) wrote:
> 3. Our main problem is: in our Zope2-application we stored our content in
> a
> RDBMS, we avoided ZODB for that stuff. We are definitely going to use an 
> (PostgreSQL/MySQL) for the new (Zope3 or Django)-project and still want 
> to avoid
> ZODB where possible. This architectural decision is carved out of stone.

I'm curious as to why this is set in stone?

I'd argue that the ZODB is very good if you're trying to store *content*
that may be hierarchical in nature and is not strongly structured.
Certainly, if the alternative is store HTML and Images (gulp) in BLOBs in an
RDBMS, I know which way I'd go. Metadata is more borderline, and could be
easier in an RDBMS, but the catalog provides a good solution for most use
cases if you go with the ZODB.

> Now, where should we start with it in Zope3 to connect it to an RDBMS?

SQLAlchemy seems to be a very popular RDBMS framework for Python. There is
at least one integration package in svn.zope.org. You may also be interested
in the Relational Alchemist product from Kapil; it's for Plone/Zope2 but I
believe there are no strong Zope2 dependencies. Its main premise is to turn
RDBMS table definitions in SQLAlchemy into Zope 3 interface, which can then
be fed to formlib forms and you get generalised forms support. I've not used
it seriously, though. There is a video about it among the Seattle 2006
conference videos at http://plone.org. 

> 5. The ZMI: In Zope2 we never used it.
> Do we need the ZMI in Zope 3 just if we will not use the ZODB for 
> storing our
> content objects but an RDBMS instead. According to 'Web Component 
> Development
> with Zope 3' by Philipp von Weiterhausen the ZMI is used to manage 
> content objects
> stored in the ZODB, so our assumption is, if we do not store them in the 
> we do not need the ZMI. Is that right or do we need the ZMI for anything 
> else?
> Do we need ZMI in Zope3 for administration or can we do that with 
> scripts etc.?

I'd assume you wouldn't need it. You'd probably need to write a custom
publication object that could map URLs to things in your database. I think
you'll probably be closer to the bleeding edge here than you would be in a
Django/TG world, though, because most people that use Zope also seem to use
the ZODB... normally for good reasons. But I see no reason a-priori why, if
you like Zope 3's programming concepts and libraries, you couldn't use it
with an RDBMS.

Another opion may be to use a hybrid, e.g. with users and/or static pages
and/or some configuration in the ZODB, but with views or objects to act as
proxies to the RDBMS.

View this message in context: 
Sent from the Zope3 - users mailing list archive at Nabble.com.

Zope3-users mailing list

Reply via email to