Jim Fulton wrote:
[snip]
The current Zope 3 distribution also contains an application that
resembles Zope 2 in many ways. There is an object tree and a Zope
Management Interface. At least up to now, when you install a Zope 3
distribution, you get an application that you can run out of the box,
for whatever that's worth. In this document, I'll call this application
the the Object Filing System (OFS).
I've found the OFS to be useful when developing Zope 3 itself. The OFS
was really the first application developed with Zope 3. There are also
certain kinds of applications that can use the OFS as a starting point.
We've built content-management systems that reuse much of it. In the
later case, we've used it less as an application than as a library.
It's not obvious to me that that the OFS has much value as an
application in it's current form.
In development I've typically used bits and pieces from the OFS as a
library. That is, I used the OFS components but didn't care much about
the ZMI user interface on top of it. I'm not sure whether your OFS is my
ZMI, but I'll talk about the ZMI here in the hope it's close enough to
what you mean. If not I hope my discussion is valuable in its own right. :)
I do think there is room for a management interface that allows you to
inspect object state and do some simple configuration, but it should be
focused narrowly and not aim to be an TTW application development
environment or content management system or a reusable user interface
framework. We are hoping to develop a management interface like that for
Grok at some point (I'm currently in Germany for grok sprint 2).
[snip]
My current thinking, FWIW:
It's not clear to me that the Zope 3 application we now distribute has
much value. I'd be interested to hear other people's thoughts on this.
I'd like to see some popular Zope 3 applicaton or applications that
people download and use to get excited about Zope 3. I don't know if
anyone is developing something like that. I hope they are. I don't
think anybody is trying to turn the existing OFS into an application
like that.
I'd like to rephrase this and say I don't think (or hope) that someone
is trying to turn the existing Zope 3 ZMI into an application like that.
I like having simple base classes like Folder and File around that I can
reuse or inherit from. We're hoping to supply these with Grok though.
Something OFS-like and simple would have its place in my view of the
terminology. :)
While I fully support Zope 3 becoming a library and toolbox of reusable
bits, I also want to emphasize that it's very important for Zope 3 to
have obvious ways to do things, preferably one obvious way to do it. Of
course the underlying system should be flexible, but the code that
people will be reading should be clear and easy to understand. This is
where popular Zope 3-based applications come in: they serve as sample
code for the applications following them (no matter whether they want to
be sample code or not).
[snip]
In summary, I'm seeing Zope 3 applications as separate entities from the
OFS. The OFS application isn't something we'll use directlty.
Instances will be instances of our applications, not of Zope 3.
I think this pattern is a good approach. I do think that it is valuable
to emphasize that each instance has some common features: you could for
instance support a debugging or management UI that can be optionally
enabled for each of them. This allows for commonality and also the
feeling that people get more out of the box than a lot of tools they may
not know how to apply effectively.
None of this should be taken as any sort of edict. I'm also not trying
to name anything. While I'd love to spur discussion, I hope not to start
any arguments. :)
The current ZMI is currently doing some things for us (however badly),
so we should analyze what it does:
* first user experience. I install zope 3 and can vaguely click around
the ZMI. Not much, but at least I have the feeling what I installed
works and is doing obscure things.
* it is a user interface that helps with installing applications.
Multiple instances of an application may be deployed under the same port
number. I think this is a valuable feature, and allows the possibility
for multiple cooperating applications without having to open new ports
for each of them. You can use the ZMI to install multiple Document
Library instances, for instance.
* it's an introspection and debugging interface. My application is
broken during development and deployment and I can go into the ZMI and
see what's wrong. I can look at various local configuration settings.
* it can be a configuration interface. Not only complicated stuff like
installing local utilities, which I hope can move mostly to declarative
code instead, but also simple stuff like which exceptions are logged can
be configured.
What else?
We should figure out what we want to (and can) keep when we dump the ZMI
as it is now, and how.
Regards,
Martijn
_______________________________________________
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
