[Zope-CMF] Re: [dev] CMF 1.5 roadmap?

Janko Hauser jhauser at zscout.de
Wed Feb 25 06:31:54 EST 2004


On Wed, 25 Feb 2004 08:36:15 +0100
yuppie <y.2004_ at wcm-solutions.de> wrote:

> Hi!
> 
> 
> alan runyan wrote:
> > I think portal_properties would be good to make containerish.
> > Tres had no problems with changing this as long as backwards
> > compatibility was kept.  Its a obvious place to put propertysheets
> > for websites.  Whether or not its a good approach is up for
> > debate.
> 
> Never missed that in CMF. But if someone wants to make
> portal_properties containerish I can live with that.
> 
> How ever this is decided: It's a minor issue regarding the AT
> debate.
> 
> > AT is complex ;-( it does a whole lot.  But it does drastically
> > reduce the amount of time spent developing content types in CMF. 
> > Add the reference engine and you have 90% of what people are
> > consistently asking for (besides having all content in RDBMS).
> 
> But it's still worth to discuss possibilities to reduce AT
> complexity for CMF integration.
> 
I also would like to discuss the inclusion of AT in CMF. I see this as
a difficult discussion, as the discussion will look at the current AT,
but the AT which will be included in CMF will look different, as there
will be some refactoring needed.

Taken from a README in CPS the fundamental difference between AT and
CPS-Schema is the creation of complete objects with AT versus the
provision of tools to generate data fields for objects with
CPS-Schema.

My current usecase is the creation of a content-repository which
should keep objects, described by some schema. The descision to go
with a central repository is driven by the need to have a massive
multisite setup, with content reuse and to keep versioning out of the
actual sites. For this a pure description of a datamodel, like
CPS-Schema is doing it, is much simpler than the complete object
approach AT is following.

I have the feeling, that AT would put versioning as yet another magic
into some layer.

How do others see the difference?

> >> Integrating Archetypes (and CMFFormController and
> >PortalTransforms)> drastically increases the complexity of the
> >package.
> > 
> > 
> > CMFFormController probably should not go in.  PortalTransforms
> > is a problem.  Not sure what to do about it.
> 
> I hope we can do without CMFFormController.
> 
> If you ask me PortalTransforms is not a problem. I'd love to see it 
> integrated into CMF. It's mature enough to go with the CMF release 
> cycle, it's useful in plain old CMF and CPS uses it as well.
> 
> Even if AT doesn't make it into the next CMF release we should think
> 
> about integrating PortalTransforms, an UID tool and the references 
> machinery into CMF 1.5.
>

+1 for these.
 
__Janko



More information about the Zope-CMF mailing list