Zope problem with directory structure

[kosh at aesaeion.com]

On Mon, 10 Sep 2001, Ken Egervari wrote:

> Actually, all I do is OO stuff.  I'm not a procedural programmer at all -
> even if I have used PHP, I most certainly too PHP's OO model to its extreme.
> I'm very good at designing OO systems since I've been doing it for a long
> time, but even Zope confused me as doing things in OO has nothing to do with
> structuring your directories.  It seemed that many of my objects would still
> go into / because they are used throughout the entire site.  Consider many
> Relation database factories and data access components.  If you have a
> database of about 20 tables, you'll probably have 35 or so classes that
> contain all the sql queries to create, find and delete from the database.
> These are used from various areas in the site, so you have to make them
> 'global' to all the site's content of course.  Let's not forget utility
> scripts and what not.

The problem with this seems to be that an RDB is really not OO. ZOPE is a
architecture around an OODB. If you are dealing with ZOPE you already have
a fully persistant, versioned, acl controlled etc database at your
fingertips. The problem is an OODB is not at all like an RDB and that is
what causes the problems for a lot of people. I think I was lucky to have
had only minimal work with RDBs before using ZOPE since the RDBs did not
change my way of thinking of the data.

However in zope you could make a folder called sqlMethods and then call
yoru methods as sqlMethod.methodname etc. It can find it that way since
it looks for nearest resolving match. the ZODB seems to be a pretty nicely
designed OODB and the interface to it is very clean from any python app.
What I really like about working with zope is getting rid of the entire
RDB system. I find I tend to make items that auto update catalogs so they
can be queried on certain kinds of information and that most queries
actually happen within the objects automatically. ie why store a product a
customer has bought in an RDB when you could just store a ref to the order
in the customer object? That makes it extremely fast to pull up the
relevant data since no SQL or similar query has to be made. You already
have the object reference so it is a simple matter of just pulling up that
object.

> What I mentioned before to solve these problems was to somehow include all
> these classes in the base python path.  That way you could just create these
> small python scripts that called the higher interfaces of the objects in
> your class library - basically the facade design pattern in the GOF book or
> designing some other higher level interfaces.
>
> I think Zope might have problems accustoming how OO is designed in
> traditional languages that didn't have an application framework around it
> like Zope does around Python - or basically the programmers that designed
> these OO class libraries this way will have problems adapting to Zope.
>
You can use relational stuff with it but that does not seem to fit really
well. I have thought of ZOPE's ability to hook to an RDB as a backwards
compatibility kind of feature for when you couldn't just leave everything
in the OODB.

> Ken
>
> <kosh at aesaeion.com> wrote in message
> news:mailman.1000086912.13328.python-list at python.org...
> >
> > On Sun, 9 Sep 2001, Ken Egervari wrote:
> >
> > > So is Zope more of a RAD tool for making quick sites?  I can see where
> it's
> > > nice if you want to make a small site - but how good is really for doing
> > > something like amazon.com?  heck, even something along the lines of any
> site
> > > with dynamic content from databases.  It just seems that they've made
> this
> > > completely new way of developing, that it might only cater to a narrow
> set
> > > of programmers.
> > >
> > ZOPE is most properly an OODB driven app server that happens to be very
> > good at http stuff. I do a lot of dynamic database stuff with ZOPE but
> > none of that stuff is stored in an RDB all of it is stored in the ZOPE
> > ZODB. You have full access control lists, persistance, searching etc all
> > built and and the system is very powerful. However it is very strongly OO.
> > It is pretty much OO to the point that doing non OO stuff in it is a lot
> > harder. Pick up the book Object Oriented Methods and read through it. I
> > think it will give a better understanding of ZOPE if you understand those
> > systems better.
> >
> >
> > > A lot of my links and page urls aren't based on the Folder model, but
> are
> > > based on database information to generate menus, all types of sections
> and
> > > sub-sections and language information for content.  This just seems like
> a
> > > harder model to implement in Zope.  What are your comments on this?
> > >
> >
> > Depending on how you want to do things it could be harder. For many things
> > if you do things properly it is easier. For example when working with
> > multiple languages why not build an object that keeps all the languages in
> > it and gives the client the one that you want it to have or gives a
> > choice? Folders don't literaly exist in zope more approriately you have
> > container objects when the entire OODB is a set of containers and items
> > and containers can contain items or other containers. What many find is
> > that it takes a while to grok ZOPE especially if you have done lots of
> > highly procedural stuff.
> >
> > <snipped for brevity>
> >
> >
> > Kosh
> >
> >
>
>
> --
> http://mail.python.org/mailman/listinfo/python-list
>