Zope problem with directory structure

[Ken Egervari]

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.

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.

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
>
>