[Zope] ObjectManager example needed

Dylan Reinhardt zope at dylanreinhardt.com
Tue Nov 25 12:17:03 EST 2003


On Tue, 2003-11-25 at 07:23, Dennis Allison wrote:

> The mapping of your music spreadsheet database to RDBMS tables is
> straightforward if not trivial.  

Precious little is "trivial" in any significant RDBMS.  Any time you're
working on a system that executes dynamically-generated code, several
issues loom large... maintenance surely among them.


>   Zope's integration with
> RDBMS systems like MySQL is exceptionally straightforward, clean,
> powerful, and flexible. You can then use Zope to handle the user
> interaction and presentation.

PHP is every bit as powerful and flexible but requires a far-smaller
footprint.  If you want to develop RDBMS-bound web apps, It's not clear
what makes Zope the best tool for the job.


> 
> If you choose to do the whole thing in Zope, you'll end up having to
> implement in Zope a subset of the relational query mechanism you'd have in
> a RDBMS. 

With Zope providing acquisition and arbitrary traversal, there's hardly
anything left for you to do.  Just make one object's id a property of
another object.  If you can find one from the other, you have all the 
relationship you'll ever need.  

Using my data model, let's say Aida has a "piece_composer" property of
'Verdi' and there is a Verdi object in the Composers folder, a peer to
the Pieces folder.  To render useful composer information in a Piece
object's interface, all you need to do is something like:

-----

<B>Composer</B>:
  <dtml-call "REQUEST.set('compsr_obj', _[piece_composer])">
  <a href=Composers/<dtml-var "compsr_obj.getId()">
  ><dtml-var "compsr_obj.title"></a>

-----

And you're done.  Each piece displays its composer and links to the
composer detail screen.  Data management is practically transparent.
     

> It'll probably be educational for you , the resulting product
> will be complex and difficult to maintain, it will take a lot of time and
> effort, and you'll have to worry about scalability and performance.

IMO, these are the leading reasons to choose ZODB development *instead*
of RDBMS.  I sell support contracts, so I'm only able to stay in
business by achieving short development time & low TCO.  

Zope eats through a *lot* of technical resources, but it's pretty good
about consuming human resources... the only kind I really care about.
Having developed both ways, I'm not the least bit tempted to go back.  

YMMV, of course.  I know mine does. :-)

Dylan





More information about the Zope mailing list