[Zope3-dev] IMPORTANT RFS: Through the Web Site Development

[Shane Hathaway]

Casey Duncan wrote:
> You are a web gui god 8^) But at the end of the day thats a lot of work and 
> its still just a web gui. In some respects "web gui" is an oxymoron. But 
> since I will not be making it and likely not using it much, I will simply 
> smile and look the other way.

I think we're talking about different things.  By web GUI I mean an 
explorer-like interface so you can see your folders, a way to add 
services TTW, a way to replace the default view with a customized view, 
etc.  I mean nothing more than what Zope 2 offers in the way of "GUI". 
I don't mean any kind of built-in text syntax highlighting editor. 
That's not a necessary component of all this.

What we're trying to achieve in this proposal is much simpler.  Say 
you're a new Zope user and you download and install the content 
management add-on.  Then you set up a site, tweak a few forms, and 
adjust some knobs.  You put the site into production and it works out 
well.  (Very similar to Zope 2.)

Then, based on new requirements, you start making a lot more 
customizations.  You don't have to write any code yet, but your 
customizations are extensive enough that you'd like to package them up 
so other people can use them, or so that you can keep development 
separate from production.  As a bonus, a new version of the content 
management becomes available and you'd like to base your configuration 
on the latest version.

You don't want to switch to filesystem-based development.  That's more 
than you want to learn.  You really want to just package up what you've 
done and ship it to someone.

That's where Zope 3 packaging come in.  For each customization you make, 
be it a component, a knob adjustment, a property change, or whatever, 
you have the opportunity to declare what package that customization 
belongs to.  Then you can just export that package and import it 
elsewhere.  (We don't have to decide on a package serialization format 
for Zope 3.0, but it could be a tarball with ZCML and supporting files.)

Persistent modules are the icing on the cake.  You write persistent 
modules on the filesystem, but they run from the database.  Because 
persistent modules are local to a package, you have a very good 
guarantee that the configuration and software fit together as intended. 
  Persistent modules also replace the need for Zope 2's "refresh" 
mechanism: you just update the database and you'll start running the new 
code on the next request.

> And the heart of my argument is not whether we should do this. I know Jim is 
> commited to the idea heart and soul, so it will happen. The question is 
> whether this is crucial to Zope 3.0.0. It seems like a big risk to me.

I think once you understand the narrow scope of what's being proposed, 
you'll see that most of it is done already. :-)

Shane