[Zope3-dev] Zope 3 web root

[Jeff Shell]

On 2/16/06, Shane Hathaway <shane at hathawaymix.org> wrote:
> Jeff Shell wrote:
> > I agree that better integration with external data should be a
> > priority for Zope. But what does that mean? In theory, if something's
> > a Python object it should work with Zope 3 with relative ease... If
> > that's not the case, perhaps we need to look at how much work is
> > required to take some random Python object that may be created by some
> > random data access library and get it into a Zope 3 published web
> > page. If it kicks and screams and resists security and interfaces, or
> > what not, maybe we need to take a look at all of that.
>
> Let me focus the discussion: I think it's nearly always a bad idea for
> anyone, newbie or expert, to put a template or script in ZODB.  Do we
> have any agreement on that point?  I wish we did.  I enjoy ZODB for many
> purposes, but not for storing templates and scripts.

I agree, generally. For one customer, we (sparingly) use page
templates in the content space of the ZODB. But those are usually only
just one or two lines. Nothing fancy, nothing programmatic. But also
not a situation that would require a special view object in that
space.

Other than that - I completely agree. Your proposal just sounds like
you want to have things like we had in Zope 2, but as pages and
scripts on the file system that are executed/rendered
semi-automatically. And that seems like it comes back to a problem
that existed with Zope 2. Ignoring the ZODB for the moment, there's
just a bit of a gulf between "templates and scripts" and "browser view
classes/components".

> The obvious question is, "if templates and scripts are special enough to
> not belong in ZODB, what else is so special?"  It's really hard to say.
>   In fact, I can think of rare situations where I actually do want to
> put templates and scripts in ZODB.

Well, anything can theoretically be stored in the ZODB. You can put
scripts and binary images into an RDBMS just as easily. Whether that's
a good idea is a separate issue.

I think that Zope 2 suffered heavily from the "too many ways to do it"
when it came to ways of doing development, and there were gulfs
between each style. Each style had its plusses too. ZClasses certainly
had an appreciative audience who liked defining schemas and building
forms automatically through the web with little programming required.
But working with templates and scripts in  ZClasses had a bit of a
different feel and behavior than working with those things in the
'content' space of the site. And it was very different than working
with file system based products.

If there's one (and only one) dominant way of developing for Zope 3,
that story is easier to tell. Do you want to make things "easier" for
"newbies" by telling them "well, you can just put some scripts and
templates on the file system, it's that easy!" and "well, if you want
to really develop properly for Zope 3, you need to do this..."?

That's where I think this "web root makes things easier for newbies"
argument falls apart. If you want to do scripts and SQL on the file
system, there are lots of other options that do the job better than
us. I think we have more important things we could spend the energy
on.

On the other hand, if I've completely mis-interpreted your initial
proposal, feel free to ignore all of the above.

> At one extreme, ZClasses tested the hypothesis that everything,
> including code, belongs in ZODB.  I think experience has proven that
> hypothesis wrong.  The persistent code idea in Zope 3 tries to give
> ZClasses a new birth, but it seems to have turned out even more
> complicated than ZClasses.

There are certainly advantages that can be gleamed from image-based
development. I've seen some really impressive things done with
Seaside. But Smalltalk (and its developers) are used to that kind of
environment. It's less natural for Python. If persistent code doesn't
behave quite like regular Python code, then there's still a gulf that
has to be crossed when one wants to "move up" from persistent code.

So yeah, I agree - not everything belongs in the ZODB. I agree
vigorously! And that's what I'm arguing in favor of. It's so easy now
to just have:

class Article(Persistent, Contained):
    tags = ()
    body = u""

And bam - articles! No translation layer, nothing. Put those in the
ZODB and go to town happy.

> That eliminates the two extremes, so there's no need to talk about those
> anymore.  We have to choose what belongs in ZODB and what doesn't, and
> the decision is often important but not easy.

I think that the decision only gets important when one is concerned
about optimization of writes, reads, etc. IE - when does one really
want the ZODB, and when does one want an RDBMS because it has better
disk access or backup tools or supports a kind of ad-hoc querying
needed by a particular application?

I guess I saw that templates and scripts are there in the Rotterdam
skin. I seldom even see that skin any more so I guess I just don't
notice. I think I tried using a 'through the web' script once in Zope
3, and had absolutely no idea what objects I could even refer to.

Making my own persistent objects, skins, views, etc, was just the
obvious way to go when I started seriously using Zope 3 that I've
never honestly thought that another way was still being seriously
offered. It's been so easy, so uniform, whether doing a simple
application, a complex one, or a simple beginning to what could grow
into a larger and more complicated application. There's been just one
obvious way to do it, as far as I'm concerned. The results we've been
able to achieve have been staggering.

> I think the distinguishing feature of templates and scripts that makes
> them poor candidates for storage in ZODB is the fact that their life
> cycle is almost completely independent of the life cycle of a typical
> object database.  When I'm wearing the software developer hat, my
> templates and scripts get packaged and shipped, but my test database
> doesn't.  When I'm wearing the web developer hat, my templates and
> scripts go through a staging process, but my test database doesn't.
> Zope doesn't have or want the infrastructure that would be required to
> package, ship, and stage complete object databases.

Exactly. All my views and templates are, well, views. They're all on
the file system. "Scripts" are methods of view objects. Or functions.
Or whatever. They're all software. They have been since I started Zope
3 development. My object databases may be test data, or they may be
real content being prepped to ship out (which is why I want import /
export. We sometimes work on a new 'wing' of a site, with custom
software and other things behind it, and then find we can't easily
import that wing's content into the main site). But I never get them
confused with software. Ever. The bulk of my code, even, is in
non-persistent objects (utilities, adapters, views, or just plain old
python functions and objects), which makes refactoring and
restructuring fiendishly easy. Since I seldom have to deal with
anything akin to 'module aliases' any more, I feel more free to move
code around and have had very few breakages and nary a broken object
show up in the ZODB.

I thought this uniformity of a development model was the Zope 3
message. Am I wrong? I know we were still trying to provide other
messages at some point, including making things like 'sqlexpression'
and full python statements available to through-the-web ZPT templates
(and only to those, not to ViewPageTemplateFile type ones), but didn't
think they were really taken or used seriously. I couldn't get them to
work half the time anyways, so I never found use for them. I did find
occasion to use a few TAL statements here and there in content space,
but that's it. And that's only for a couple of deployments. Are others
seriously developing with templates and scripts in 'content space' in
Zope 3? Why? How?

--
Jeff Shell