[Zope3-dev] Re: Some thoughts on Zope 3, Zope 3 applications, and Zope 3 instances

[Martijn Faassen]

Martin Aspeli wrote:
> 
> 
> Jim Fulton wrote:
>> I'll make some small comments below, but I want to make a big
>> comment to start.  Zope 2 and Plone are both examples of
>> extensible applications.  In my note, I was trying to make the
>> point that I think such applications have value.  I'd like to
>> see them exist.  I'd like to see them done well.  I think Zope 2
>> did it very well, in it's time.  I think Plone and other applications
>> have carried that forward successfully.
>>
>> At ZC, for better or worse, we are no longer in the business
>> of applications that are extensible in that way. We build
>> applications that are used directly by our customers.
>> I think this is true of many Zope developers.  *We* use Zope 3
>> as a library for building applications.
>>
>> Both uses are valuable and should be supported.
>>
>> The application that I've been referring to as the "OFS"
>> (again, a more or less random name) is a pale imitation of
>> Zope 2.
>>
> 
> This is very much what I read into your comments and I think it is an
> impotant architectural decision whether we're building an application or a
> framework (Plone itself struggles with that decision sometimes); The strong
> "framework" leaning that Zope 3 has adopted is probably to its benefit, and
> is almost certainly the main reason why we are able to benefit from Zope 3
> at all today in the Plone universe (via Five).
> 
> However, Zope 3 should not be and is not just a library that ZC and a few
> other people with deep investment in the framework use for their
> applications. To grow, stabilise, mature and become a good vehicle for
> selling work ("I trust you because you're using Zope 3", rather than, "I
> don't trust you becuase you're not using J2EE") the community needs a
> constant influx of new developers and interested parties - the first
> instance, users of the framework.
> 
> The general direction that web frameworks are moving in, led by Rails and to
> a certain extent Django, Pylons, TurboGears and arguably Plone in some
> circumstances, is that getting started must be quick, results must be rapid,
> the tools must support "agile" working practices and the learning curve must
> be managable. Most people don't have the time to bet that reading a book or
> two will be worth the investment (of time) before they start doing something
> useful and productive.
> 
> This to me is where we can learn from the success that Zope 2 and Plone have
> enjoyed (or been the victim of, as it may be architecturally speaking). The
> main reason people think about building applications "in Plone" at all (a
> somewhat self-contradictory notion) is that if they can re-use all the
> pretty UI and HTML/CSS primitives and user management and navigation
> elements and security and workflow from Plone, turning off the portlets and
> content types and junk they don't need and turning on the custom
> look-and-feel and extra content types and portlets and forms they *do* need,
> they get something up and running quicker, to a higher standard, than if
> they start from a palette of components and a blank .py file.
> 
> In other words, as Martijn has said, I believe it is very important for the
> community to support meaningful distributions/app servers/higher level
> frameworks (singular or pural) that show off what Zope (3) is good at and
> how it's done, that can be customised and (this is where the CA approach
> really kicks ass) where future upgrades to this means you benefit, not that
> you need to re-fork it for your own needs.
> 
> I would be worried if I felt that the Zope 3 community became only about
> components and left this "real world but generic assembly" work to "someone
> else" when no "someone else" would be interested or skilled or emotionally
> invested enough to care. In the Plone world, we have the focus of
> Plone-the-application that implies we have to make Plone-the-framework
> better. If things become *too* scattered, where is the focus of Zope3?
> 
> (note: I'm exaggerating here, I think things are moving in the right
> direction not the wrong one, I'm just playing devil's advocate and exploring
> what I've seen from the Plone side of the fence)
> 
> 
> 
>> Note that there is nothing inherently hierarchical about ZODB.
>> Of course, ZODB makes modeling hierarchies (and other graphs) much easier
>> in many ways that working with non-object databases.
>>
>> Of course, I'm a big fan of the ZODB and would use it for all sorts of
>> "non-content-centric apps", whatever that means. :)
>>
> 
> Like I said, I'm quite tainted by Zope2/CMF/Plone. I like to model
> (many/some) problems as hierarchical data structures with concepts like
> one-to-many relationships as folders with content. I agree the ZODB isn't
> necessarily hierarchical, but all the use cases I've ever seen for it have
> been. :)
> 
> 
> 
>> Well, fortunately, thanks to setuptools and tools like easy_install and
>> zc.buildout, you should only need one trip to the cheese shop (or
>> wherever)
>> and the dependencies should come along automatically.  I'm also working
>> on ways to automate packaging and app and all of it's dependencies
>> together.
>>
> 
> That would be another useful step. I still find it a bit scary that I won't
> be able to visualise (as someone else in the thread said) how the pieces fit
> together. I would worry that there are great pieces out there I simply don't
> know about. :)
> 
> Anyway - I hope these perspectives are useful. I'm certainly not disagreeing
> with what you're saying or with the direction you're pointing out. I think
> we just need be mindful that there were some good things about the past
> approaches as well as problems (not that you're not).
> 
> Cheers,
> Martin