On 3/1/06, Shane Hathaway <[EMAIL PROTECTED]> wrote:
> Jeff Shell wrote:
> > - Zope 3 CA: The Zope Component Architecture. Core services. Would
> >   include zope.publisher and most other current top level zope.* things.
> >   Usable as a library, as a publisher for other environments, perhaps as a
> >   simple standalone server. Easy to deploy against WSGI, Paste.deploy,
> >   whatever.
> >
> > - Zope 3 AS: The Zope 3 Application Server. A Zope 3 CA stack using the
> >   ZODB, ILocation, and most of the zope.app services but without any content
> >   objects. Perhaps only an application server configuration skin (process
> >   management) but no ZMI. Maybe have the current configuration installable 
> > as
> >   an option.
> >
> > - Zope Suite (or Zope Web or Zope DE): This is the full "application server"
> >   perhaps Jim is envisioning. A comprehensive web based user interface, 
> > based
> >   on features (and implementations) of both Zope 2 and Zope 3 application
> >   servers and offerings.
>
> That's quite appealing, IMHO.  Could you agree with the following
> distinction?
>
> - Zope 3 CA expects the model (and the method of persisting the model)
> to be completely defined by the Python programmer.

Yes, although Zope 3 CA could also be used in non-web environments
(I've used it in an internal package manager experiment, for example).

I'd like the Zope 3 CA download to include some useful examples and/or
skeletons (possibly configured for Paste Deploy) to show some of the
different options - use with SQLObject, other template packages (page
templates would be included with the core though), etc. It could also
include some other publisher/publication objects that could show
integration with tools like Routes, for example. These extras would be
outside of the core library, of course.

For purposes of documentation and evangelizing, the Zope 3 CA can
provide improved documentation about core Zope concepts like object
publishing, without having to put Zope 3 AS expectations or terms on
the programmer, giving them an entry point to the larger world of the
Zope Application Servers without being overwhelming.

Then we (or someone else) can write "Python on What Have The Romans
Ever Given Us", which would show how you can do a rails "programming
by convention" style system using the component architecture. The CA
would automatically create adapters/views to bind
``models/person.py``, ``controllers/person.py``, and
``views/person/list.pt`` together. How those adapters are registered
and used by the publisher would show off the CA.

> - Zope 3 AS expects most of the model to be stored in ZODB and implement
> ILocation.  However, it still expects model objects to be defined by the
> Python programmer.

Yep. Zope 3 AS might also yield a solid foundation of base interfaces
to allow easier use of 'sqlos' and/or 'sqlalchemy' backed objects that
still provide a core set of useful and usable information (dublin
core, etc), and could offer the option of using one of those instead
of the ZODB while providing the caveat that use of other (third party)
'model' components may require additional work to map.

Essentially, Zope 3 AS would be the option for those who like the Zope
3 + ZODB way. So many of these other web 'frameworks' with their O-R
mappers show off applications that don't really need the full power of
SQL. If you don't need it, why go through it? The ZODB is very
credible - perhaps more so now than ever.

Zope 3 AS would also downplay or replace the ZMI. I think there should
be a skin available for configuration - ie, for adding a site (a
complete application like Schoolbell, a customer CMS, etc) and maybe
giving access to configuration options, like the stuff in ++etc++site,
but that's it. I think the current ZMI suffers from being both a
system administrator tool and application / data entry tool. I know
that security settings can filter out a lot of the administrative
features, but the interface that's left still feels a bit incomplete.
And it raises the question "should I provide for it? should I define
some zmi_menu menu items, just to be useful? should I use it as my
user interface?"

Django is killing us on automatic data (not system) administration
pages. If web based configuration/administration (add a site, set up
users, maybe select that site's skin, flush caches; process
administration) was separated, then someone could build and provide
something like Django's admin screens or Turbogear's Catwalk for doing
the data entry. But it would be an option to use that as a
view/skin/tool, and clearly marked as such.

Some applications, like many CMS's, need something like the ZMI as
they often separate the concept of data entry/management from how it
is presented to the site's visitors. But an application like
Schoolbell or a Knowledge Base may have just one skin. All data entry,
display, etc, is managed through that. Having to support (or wonder
about supporting) the ZMI shouldn't be a concern of those
applications.

It's just a point of removing distractions and concerns. This is all
doable now, of course, but it's not the default (or selectable)
behavior. It also makes documentation - particularly starting
documentation - easier. For the good old wiki example, it wouldn't
have to be explained that "you can see and edit this in the ZMI now.
But if you want to put your own interface on it, you have to do this."
Instead, "mkzopeinstance --create-skeleton-application name=wiki
aslocal=yes.. This makes the following directories, modules, and
configuration... now lets edit the standard template.. and then on to
the exploding version of the blue danube!"

> - Zope Suite (great name, BTW) defines a complete but limited model.  It
> is a simple content management system (like Zope 2 + CMF) that's easily
> extended in countless ways.
>
> Does that match what you're suggesting?  I'd hate to misrepresent your
> vision.

Pretty much. In my version of this vision, Zope Suite provides the
full meal deal. Notice that I didn't call it 'Zope 3 Suite'. Zope 2.9
would qualify as 'Zope Suite', and its roadmap would include the
transition (perhaps) from the current base to a Zope 3 CA / AS base,
while right now it would say "Zope Suite continues the Zope 2
Application Server line while bringing in support for the Zope 3 CA,
with support for Zope 3 AS planned for next winter's release".

And boom! There we have it - a component architecture / zope.publisher
/ cool core technology package that is useful and usable by many, with
appeal to Python "I don't need no XML or ODB" programmers, or those
who like Zope's concepts but have a very different data management
system; and a continuation of the Zope 3 "app server" as it exists
right now, but perhaps better defined and constrained. Both of these
keep the Zope 3 brand alive, and are distinct offerings. 'Zope Suite'
becomes the future of Zope 2. Available now, with a roadmap towards
the future where the Zope 3 features will become more prominent in the
base. The release numbers might stay where they are now, 'Zope Suite
2.10, Zope Suite 2.11' until it moves (if it moves) entirely to a Zope
3 CA based foundation. It's the Zope MegaFramework.

Writing for Zope Suite won't require any future 'jump' to Zope 3 AS.
And developers who prefer Zope 3 AS won't have to worry about run-ins
with the Zope Suite extended feature set.

Anyways, that's my vision, a little bit more elaborated. But in short,
you did understand it right :).

--
Jeff Shell
_______________________________________________
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to