On 3/2/06, Max M <[EMAIL PROTECTED]> wrote: > Jeff Shell wrote: > > >I think this keeps Zope 3 as we know it alive, keeps the Zope brand > >intact, and offers a future for Zope 2 and similar caliber desires for > >a Big App Server while not interfering with the more "pure" and simple > >concepts that makes Zope 3 appealing for developers like me. > > I think its an absolutely terrible idea! > > The most succesfull Zope 2 "product" out there is most likely Plone. And > it has everything and the kitchen sink in it.
Yes it does. And I hate it. At Bottlerocket, we're a very small company. We look at Plone and go "alright, how do we make it do less? how do we turn this thing off, and this thing off, and this thing off, and this thing off? why is it so slow? and it still doesn't do the page we need to do. Let's just write our own CMS". Real conversation, real decision. The second one made us feel more in control. Plone is great, but it's incredibly overwhelming. Contrast that with Zope 3, where already we've been able to take advantage of some small components out of other projects -> schoolbell.relationship, zc.catalog, hurry.query, hurry.file. In Zope 2, some of those things would have ZMI interfaces. Some would be standalone applications. Some would only be really configurable and usable through the web. Some wouldn't. Let Plone be Plone. But let me easily write and use things that are not Plone. I don't need all those features. I don't need all those features. I don't need all those features. I don't need all those features. And the more I have to wrestle with turning them off (tell the 353 some odd lines in my average browser zcml file that it's all just a matter of configuration), and having to painfully extract the core usable concepts out of other libraries, the less appeal it all has. And again, I have to say that I'm a little grumpy as I ended up working late chasing down how vocabularies and renderer factories get initialized and set up so I could "do the right thing" and write a unit test to prove, figure out, and solve a bug in my own code. That was a long and twisty maze, and I basically lost a day of work to it. Tell me a larger and more feature rich system is going to help me. There's nothing wrong with having a lot of features. But there should be simpler options with lower barriers to entry as well. > I fear that loosely coupled libraries does not make an app server. I can > just imagine the upgrade hell when one package requires two different > packages, and another package requires the same two different packages, > but in different versions. > > Canonical releases of compatible package collections is a *must*. > Splitting it all up in small chunks that are out of sync would be a > disaster. > > Releases that contains a *huge* compatible collection of packages is the > most effective way to move forward in an unified way. That's why I want three simple packages. I'd expect that most of them would be released at the same time, with same or similar version numbers to show that 'Zope 3 3.3 AS builds on Zope 3 CA 3.3' A package can then say "requires Zope 3 CA", "Zope 3 AS", or "Zope Suite". It won't be "requires zope.interface 3.25; zope.tal 1.48; zope.tales 2.33;...." I don't want that either. > Plone products works together because Plone is so well defined. > Sometimes this feels like a straightjacket. On the othe hand, in plain > Zope 2 it is practically impossible to reuse other peoples products on > your own site because the playing field was too loosely defined. Plone is a product and a finished application. Zope 2 could be a standalone finished application out of the box, or a base toolkit to start building web sites, or a framework for building web applications, or all of the above. Zope 2 serves many masters. I've written hoardes of different applications in it over the years, serving very different markets and customers and architectures. If you use Plone, you're running Plone. Plus, I've seen arguments against Plone lately as having lost focus from content management and into being its own little development environment. It always happens when you try to make a generic tool for everybody that's also feature rich and complete. "Great! Awesome product. I wouldn't change a thing. Except.. We have a double editor process and my boss has a weird thing against tabs and we really want it to look like our corporate branding..." > But just like you don't have to learn every Python library to use > Python, you should not have to know every package in the app server. > That is not a question of making seperate releases though, it's the age > old programming problem of structuring code with few interdependencies. > So throw everything into the release. heck even throw Zope 2 in there if > you have to. But dont force the programmers to use it before they need > the functionality. I just fear people having the discipline or understanding of when to use feature X and when not to or if it's even an option not to. Using Zope 3 is not like using a library. Components need to be registered and configured. You can't just show a simple example about widgets without having to start loading the ZCML in zope.app.form.browser, and who knows what else that requires and loads up? Who knows how to do it manually? Why did I lose a day setting up a vocabulary to make a test harness to solve a very small bug? (bug fix - three lines of code, one line of ZCML, a huge amount of imports and harnesses in the test.. It's not proper 'unit' test, but it wasn't something I could break down to a small unit of work) As I've mentioned here, we have an application system that we want to move to Zope 3. When it's in Zope 3, it won't need the ZODB at all. It won't need zope.app.container at all. It definitely won't need any of the dublin core, content objects. We want view objects, URL traversal, page template files, and that's about it. It should be possible to do this, but the method of going about it isn't clear. _______________________________________________ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users