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

[Chris Withers]

alan runyan wrote:
> CMFTypes is infrastructure.  the "forms" it generates are pluggable(maybe
> not
> now but could easily be made).

I think that would be a pre-requisite of any incorporation into CMF Core.

>  currently it creates Plone forms.  

What are they from a non-Plone-r's point of view?

> 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.  

How does this differe from associating methods to types using a TIO's Actions tab?

> define a Type Descriptor and with this the framework can generate forms/edit
> scripts. 

That's the bit I think I want.

> such as a UID for all the content objects.

That path is the UID.

> UID.  Autogenerates FTI.

CMF Type objects should be another type of TIO IMNSHO.

> generating FTI automagically,

That word sends shivers down my spine.

> 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.

This sounds like good stuff, hopefully I'll get a chance to play some time so I 
can comment meaningfully...

CustomizationPolicy does sound cool, again, my scepticism could probably be 
dealt with by playing, sadly time is not on my side :-(

> portal_properties being a container should not be very scary.  Think about
> how often
> you wanted to create property sheet for your sites.  

Urm, please give em some use cases, I've never wanted to create PropertySheets 
for a site ;-)

What I'd really like is a 'mapping' property type, but that needs to go into 
Zoep core, nto even CMF...

> of course. I think there is plenty of infrastructure that Plone and people
> using Plone
> have developed that can land back into CMF.  

My emaphasis is on lean.

>   * 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.

Not with FS 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)

That's autogenerated forms stuff, as with metadata. I'm undecided on this. I can 
see Tres' point about the need to often code these by hand so they work right 
and look nice, but the shag of doing this is something I'd like to avoid ;-)

>   * 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.

I just subclassed Portal for Swishdot...

cheers,

Chris