[Zope-CMF] cmf dogbowl re-visited (or: looking for the 1.4 roadmap)

[alan runyan]

> >   - add Adrian Hungates CMF Product Installer
> >
> >   - most likely incorporate CMFTypes
>
> Then a CMFDefault excercising of these interfaces needs to be provided.
> I haven't used CMFTypes but I like the idea, I just can't really stomach
Plone's
> use of Javascript and CSS, so I'd like those to not end up in CMFCore ;-)

CMFTypes is infrastructure.  the "forms" it generates are pluggable(maybe
not
now but could easily be made).  currently it creates Plone forms.  but we
are
missing out on the point.  You dont have to create portal_types anymore by
subclassing PortalContent and this or that.
You subclass BaseContent or BaseFolder and add your methods.  you can
define a Type Descriptor and with this the framework can generate forms/edit
scripts.  based on the type descriptor.  But it has tons more useful
infrastructure.
such as a UID for all the content objects.  You can reference other objects
by
UID.  Autogenerates FTI.  It has absolutely nothing to do w/ Javascript/CSS.
Its infrastructure.  The fact it (by defaults) generates Plone forms - i
believe is
a non issue.  You can change this - and someone will have to change it.

CMFTypes  is *exactly* what some people expect from CMFCore.  Fundamental
parts of the system like.. Referenceable, having only 1 class to subclass
from,
generating FTI automagically, having extensible metadata.  All of this you
get for free by simply putting  CMFTypes in your Products directory ;-).

oh yeah I forgot.. the fact that you can upload Rich content objects (like
MSWord)
and have a content_driver manipulate teh data and suck it into yoru content
object.  holy jeebus its great fun.

> >   - move some of Plones functionality into CMF
> >
> >     - CustomizationPolicy
> >
> >     - make portal_properties a container of propertysheets
>
> Where are these described? I haven't used them, and it makes me (hopefully
> unecessarily) nervous.

CustomizationPolicy is a mechanism for people to "register" skins with a
Portal factory
mechanism.  It will generate the Portal and then hand it off to a
CustomizationPolicy.
Its a very very simple idea that would be nice to have.  This way people can
make
very simple Customizations and register them.  So when you create a CMF site
you
can choose what "Customizations" you would like out-of-the-box.  Read the
source
its very very straight forward.  There is even an interface declared.

portal_properties being a container should not be very scary.  Think about
how often
you wanted to create property sheet for your sites.  In plone we currently
ship with
3 propertysheets and we will be adding a 4th before 1.0 (moving out the
properties
on the Portal object into its own propertysheet).  I dont see much of a
issue with this
if we can retain backwards compatibiltiy.

> > the waist side.  The plone developers most certainly want to get
> > most of the framework pieces out of Plone - moving some into Products
> > and others into CMF.
>
> Well, I hope there'll be consensus on how to do this. Like I said, I have
> concerns because I don't use Plone for some good reasons, but if there's
good
> lean infrastructure that can be taken from it, I'm all for it :-)

of course. I think there is plenty of infrastructure that Plone and people
using Plone
have developed that can land back into CMF.  I am not interested in "feature
bloating"
CMFCore.  I think few of the things in Plone are actually "CMFCore"
components.
Plone is certainly not for everyone - as we have seen.  But there are some
warts
with the existing CMF:

  * if you are writing a component and it requires some configuration
options but you dont
have a tool - you currently have a PropertySheet just sitting in your skins
folder.  This is
kinda ugly and even more difficult to maintain.  Thus we came up with
putting them in
portal_properties.

  * if you need to add properties to members there is no good way to do this
and keep
personalize_form up-to-date with these changes a component has made. (we
need to figure
out a way around this)

  * extensible metadata

  * If you want to create a product based on CMFDefault but you do not want
to expose
people to External Method installation (maybe Adrian's installer can fix
this) and at CMF Site
creation time you want to apply configuration/customizations.

btw. we just released the second beta release of Plone.  Hopefully the next
release will be 1.0,

cheers,
~runyaga