On Thu, 02 Mar 2006 00:42:14 -, Jeff Shell [EMAIL PROTECTED]
wrote:
Personally, I still find it hard to know where the line goes between the
ZMI and my own UI code, if I should be extending the ZMI or replacing it.
Perhaps because I'm tainted by Zope 2's idea of the ZMI, though.
Personally, I think it's insane that Zope 3 still has TTW scripts and
templates enabled by default. :-)
Personally, I think that Zope 3-the-CA would be the useful in a Zope 2
+ Five context, at the very least, which is where a lot of interest will
continue to come for.
Without understanding the detailed implications of your vision, I must say
it's quite attractive. Perhaps the difference between the AS and the Suite
may be hard to explain and keep clean, though - I'm really not sure.
But less-is-more is a good concept when it comes to frameworks like the Z3
CA. The less stuff I have to learn and understand that's not relevant to
me (e.g. as a Five-focused developer, or as someone with lower
requirements) the better. Should be easier to document it in these stages,
too... And I like having distinct names for the different parts of that
puzzle.
Martin
We've been through a lot lately. You know it, I know it. Zope has a
reputation. Sometimes it's good, sometimes it's bad. This has affected
Zope 3, since Zope 3 is very much not Zope 2. But it's affecting
Zope 2 as well, as Jim has brought to our attention. Zope 3 is Mature.
Zope 3 sounds like Zope 2+1. Zope 2 and Zope 3 have very different
concepts. Zope 3 has restricted its audience, for now, to developers;
while Zope 2 is appealing to many different kinds of end users and
programmer types. Five offers a bridge so that Zope 3 as a library may
be used in Zope 2, and the Zope 2 core has started making use of some
Zope 3 concepts.
But it's obvious we have a name problem. Even within Zope 3, there's a
name problem, between Zope 3 as Application Server and Zope 3 as
cool collection of packages.
Today, I wrote a much longer message in response to the Two Visions
thread. But I was in a bit of a bad mood, having spent many hours
trying to set up a test harness to test one little thing in my own
code that was causing problems - a one little thing that depended on
quite a few components being set up, and it was painful. And I'm still
not done. And I realized, as I stewed away, that I like Zope 3 as an
Application Server... But I'd like it with less. And this option
hasn't been proffered, so far as I can tell. It seems like Jim's
Vision might be two options - zope as library and big zope
application server with all of the object file system and probably
through the web stuff and so on and so on and would be largely
compatible with both Zope 2 and Zope 3 as they stand today.
Personally, I'd love to have the first option. I also, personally,
don't care if I have the second option, but I recognize the need or
desire for it, and the desire to get out the message that Zope 2 and
the applications on it actually do have a future even though they may
not have a future with Zope 3 as Zope 3 is currently known.
I'd like a third option: the Zope 3 Application Server as it is right
now, but with less. No Rotterdam skin, perhaps no ZMI. No content
objects at all, except maybe for some example file and image objects
to show how to do BLOBs. It would still be ZODB based. It would still
be ILocation based. zope.app.container would be prominent, and
zope.app.folder would not be a distraction. It's the basis for
building applications like Schoolbell/Schooltool, custom content
management, itinerary managers, knowledge bases, whatever. Catalog,
local sites/utilities, all still there. But without the distraction of
should I support the ZMI? use it as my user interface? should I use
the TTW page templates?. IFolder and IContainer... What is the
difference and which should I use? Which should be my base class
(because at Bottlerocket, we chose Folder when we shouldn't have, we
found out much later). Maybe that stuff would still be in the library.
Maybe it would still be available as a 'mkzopeinstance' option. But
the Zope 3 Application Server would probably work best if it promoted
custom development via persistent objects, views, and custom skins, as
the default way of working with it. It's easier to write documentation
for, it could be easy to write mkzopeinstance commands for (to
generate a basic starting point with skeleton code and a site.zcml
setup that loads the custom skin). There's not this other User
Interface and other objects providing a distraction. I'm making a
wiki. How does SQL Script apply? I18N File?.
And then I thought about Taligent, for some reason. I'm not going into
the history of the company/project, whose products never really made
it out into the light of day. But at some point, they broke their
product (which was to be a new object oriented operating system) out
into a small set of distinct offerings: TalOS (Taligent Object
Services), TalAE
