[Zope3-dev] Zope 3 web root

Jeff Shell eucci.group at gmail.com
Wed Feb 15 23:52:26 EST 2006


On 2/10/06, Shane Hathaway <shane at hathawaymix.org> wrote:
> Chris Withers wrote:
> > I'd flip that, because I think you and Steve A would agree on one thing:
> > The use of an object database _should_ be a choice, not a requirement,
> > but it should also be the default ;-)
>
> Actually, I disagree--I don't want an object database to be the default.
>   An OODBMS is good complexity for some projects and bad complexity for
> others.  Let people first choose the thing they're familiar with (the
> filesystem), then make it easy for them to branch out toward an RDBMS or
> OODBMS.

This is frustrating to see. At least, in the concept of 'Zope' as the
full application server it is.

Others have brought up the concept of 'Bobo', and I would much rather
see that. There are situations where I don't want the ZODB. We have
our own data management layer for very very very very complex RDBMS
interactions. We have a Zope 2 gateway to this layer right now and
then acquisition and other wonderful tricks allow templates/scripts to
be picked up and applied to the resulting data. We want to move it to
Zope 3 to take advantage of the concept of Views and, most
importantly, have all of the templates on the file system. But we
really don't need all (or most) of zope.app. Containers, Sized,
Catalog, and so on and so on and so on, really don't apply. I know
it's *possible* to not use all of that, but just *how* to do it, I
don't know.

A Zope that was basically zope.publisher, zope.component,
zope.interface, zope.schema, and tal/tales (and maybe 'transaction')
would be ideal.

Your idea terrifies and confuses me.

I think I just don't like this 'Newbie comes in and ...' talk. It's so
generalizing. These days, I find myself being THWARTED at many turns
by the magical special browser: ZCML directives that were to make life
easier for newbies. Yeah, they helped me in the beginning. And now I'm
pulling my hair out. Don't thwart me!

I'm not saying that helping new people is a bad thing. But why push
all of these new concepts on them AND seasoned developers like me?

Personally, I think that the ZODB is a terrific asset that has
achieved a greater level of usability in Zope 3. At least, it has for
us,  now that we're no longer confused about whether the ZODB should
house our persistent objects, or if it should house our icons and
scripts and code and the RDBMS should be the store. I wouldn't want to
downplay this advantage.

Anyways, I believe fervently that a totally pared down version of Zope
that was just the basic stuff as mentioned above (zope.publisher,
zope.component, etc) would be a good target. That's something I
understand. What you describe, I don't understand.

> Do you mean "_just_ an RDBMS if you so desire"?  We don't want to force
> people to use an ORM either.
>
> Flat files are everybody's land.  Our flavor of flat files will be
> engineered to ease the transition from flat files to a Python package.

Huh?

This is sounding like the "but everyone just likes and wants PHP" talk.

Maybe it's my fault for never wanting, nor changing, a 'default page'
after installing an instance home, and I'm not the target audience.

We use the ZODB for data and storage and it's so wonderfully easy in
Zope 3 to keep all of that in the ZODB while all of the templates and
views are on the file system that I've never thought much about
fssync.

- I WOULD LOVE TO HAVE EXPORT/IMPORT THOUGH! - (or fssync, but really
more for backups or data updates...)

And I guess we have the other odd requirement that we often don't have
just a single root, or a single view of any particular site root. For
our internal CMS customers, the public never sees anything close to
the content management screens. 'admin' is thought to be a separate
experience, even by our customers. But it's really just a different
skin on the exact same data. Not really a root at all. I guess it's my
fault for no longer really thinking in terms of "serving up pages,"
but rather "serving up your flight itinerary" or "serving up a list of
related articles and who wrote them."

I guess this is all kindof rambling. I just don't see any benefit to
me. I'd rather see any effort like this pick up the zope.bobo
branch/product or whatever it is right now and deliver a clean and
simple stripped down zope publisher that could run on WSGI and could
be used to show up all of those "but i can make a wiki in twenty
minutes" tutorials and have no dependence on storage of any kind.


More information about the Zope3-dev mailing list