Martijn Faassen wrote:
Martin Aspeli wrote:
I think your thoughts resonate quite well with my own observations and/or
confusion. I would, however, caution against becoming over-zealous in
breaking things up. Zope 2, CMF and Plone are successful in large part
because people get started quickly. If it takes fifteen trips to the
shop to understand how to get a page to say Hello world, I'm not sure
would bother. Most likely, that's solved by having use-case focused (and
real-world tested) bundles or distributions that provide meaningful
functionality of starting points. It's also solved by having some
customisable "best-practice" components that are closer to the user.
Learning from such examples is probably the main way people pick up new
technologies and conceptualise how they can solve their particular use
Just splitting stuff up into little flexible pieces won't attract
people. If our goal is to attract Zope 3 developers we need to make it
easy to get started. We can also say that Zope 3 is componentized and
flexible and all that, and this will attract developers too, but if the
first bit is too hard all our talk about flexibility will lead to nothing.
So, we need to do both: make it easy to get started, and componentizing
for greater flexibility later. If we just do the first, we make Zope 2
style mistakes and end up with a monolithic system that should be easier
to develop with. If we just do the latter, we make Zope 3 style mistakes
and end up with a well componentized system that isn't used a lot.
Agreed, we need both. We should understand though that the thing I'm
calling (soley for the sake of discussion) is probably not a good
starting point. IMO, it could be if someone was working on it.
I also think that it would be a find project on it's own. Or maybe
there's another project that would serve better. I don't know.
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714 http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
Zope3-dev mailing list