[Zope-CMF] Future of CMF

Tres Seaver tseaver@zope.com
Thu, 06 Dec 2001 20:35:23 -0500


Jeff Sasmor wrote:

 > I was reading the Paul Everitt atricle on Zopera.org and came across this quote:
 >
 > http://www.zopera.org/site/Members/odeckmyn/iv_paul_2001
 >
 > "Regarding CMF, we expect it to disapear in its current form, because the new component model will provide all the standard 
facilities
 >  as Services, and you will just have to use them, and not reinvent the wheel. CMF was actually a big prototype for the new
 > architecture."
 >
 > I was wondering if someone from ZC would like to comment on:
 >
 > 1. Whether or not current CMF-based products will be able to migrate to this new platform or will have to be completely rewritten.
 >



Existing Zope products will not be forced to upgrade, at least
immediately.  Zope 3.0 will allow them to work largely as they
have, while offering a number of advantages to component authors
which we expect many product authors will be very excited about.


 > 2. Whether CMF-based websites will have to be completely redesigned.


Stock CMF content objects already go a long way toward meeting
the expectations of the new architecture:

   - They declare their interfaces explicitly

   - They factor presentation and application-specific logic
     into separate, pluggable components.

We will certainly have such sites firmly in mind as we plan
for rolling out Zope 3.


 > 3.  Will future versions of Zope be able to support running the current or 'final' CMF codebase so that folks can update to
 > newer versions of Zope but still run CMF and their CMF-based apps and websites?


I don't share Paul's opinion that the CMF will "softly and silently

vanish away";  rather, much of the framework which currently
is supplied by the CMF tools will be supplied instead by what
the component architecture calls "services", many of which will
be available to all Zope applications.  The remaining parts of
the CMF (content types, specific presentations and policies, etc.)
will remain, and will support existing sites.



 > 4.  Is this why there has been no new release of CMF in so long?


The primary reason for the delay in releasing CMF 1.2 (tomorrow's

beta will be about two months later than planned) has been resource
contention.  The Zope 3 effort has been only a minor part of that;
paying work, and the sales engineering which brings it in, have
accounted for most of the demand.

A subtler effect of Zope 3 on the CMF is that we have begun to
feel reluctant to take "big bites" against the Zope2 architecture,
largely because we can see how much nicer things will be when
Zope 3 lands.


 > 5. (OFF-Topic) Is it a bad thing to make Zope more complicated? IMHO, I think part of Zope's growth curve and rate of adoption
 > has been because of it's ease of use.  In spite of such things as _['sequence-item'] and other DTML dark corners, it is
 > relatively easy to use; hence, Zope itself is easy to use, if you take the time to learn it. Folder-centric inheritance of
 > attributes and so on (acquisition) is also not too bad.


We get beaten up fairly often about the steep part of the Zope

learning curve, which frustrates even seasoned Python programmers.
Zope 3 and the component architecture are aimed squarely at making
the component author's tasks simpler, easier, and more explicit.

 > If future users will be required to use  ZPT and Component Architecture which may be better but harder to understand (for newbies),
 >  will people just tend to 'bounce off' Zope and go elsewhere?  I hope the docs for these features are voluminous, comprehensive,
 >  and well written; and that the people who have been writing books on Zope are kept up to speed on the changes so that learning
 >  materials can be quickly updated!  Here's to making Zope better in the future (I wouldn't want to see it become stagnant,
 > that's not what this is about.)


PageTemplates, wrapped up as presentation components, seem both
simpler and clearer to me than DTML-with-acquisition (and I was
one of the firmest supporters of keeping implicit acquisition
around as a tool).

While a Zope 3 product will tend to have more classes (and
interfaces!) than an equivalent Zope 2 product, each class will
have a much more focused set of responsibilities, and should be
much easier to write.  For instance, in Zope 2 the product author
has to make a number of what Jim calls "burnt offerings" to get
a simple content type to work in the ZMI;  Zope 3 will require
vastly less "magic", in exchange for more explicit (but
overridable!) declarations.


 > Sorry about the rambling, I have a cold...


No problem -- hope you are feeling better soon.

BTW, I am cross-posting this to a new "zope3-dev list",

   mailto:zope3-dev@zope.org

The listinfo and archives are at:

   http://lists.zope.org/mailman/listinfo/zope3-dev

Please follow up only on one list or the other, depending on

the focus of your replies.


Tres.
-- 
===============================================================
Tres Seaver                                tseaver@zope.com
Zope Corporation      "Zope Dealers"       http://www.zope.com