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 > RDBMS > (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 > ZODB, > 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. Martin -- View this message in context: http://www.nabble.com/Zope3-with-RDBMS-%28avoiding-ZODB%29--tf3308983.html#a9204651 Sent from the Zope3 - users mailing list archive at Nabble.com. _______________________________________________ Zope3-users mailing list Zope3email@example.com http://mail.zope.org/mailman/listinfo/zope3-users