On 7/13/05, yuppie <[EMAIL PROTECTED]> wrote:
> > * However, are you / we confident that we've found the best patterns
> > for utilities / adapters yet?  I'm not!
> 
> Maybe we should first see what people want to contribute and decide
> later if we call it CMF 1.6 or 2.0.
> 
> > In addition, I have a number of more ambitious thoughts about the CMF,
> > which don't necessarily relate to Zope3 - relating, for example, to
> > schema-driven development,

> You can use schema-based Five content with CMF 1.5.2.

Yes.  I mean that we need decent patterns for the use of schema-based
content. See below for an attempt at a better explanation.

> > or XML in the presentation layerl.
> 
> Not sure what you mean exactly by that.

I'm talking about exploring the possibilities for moving content
delivery out of the Zope/CMF stack and using XML and XSLT instead. 
See, for example, Paul's Deliverance proof-of-concept:
http://codespeak.net/svn/z3/deliverance/trunk/INSTALL.txt.

I think Lennart put it better than I: for CMF2, perhaps our energies
are better focussed on some broader categories, as we already have
Five and can integrate with it incrementally.

One thought is that perhaps we should turn our attentions to
CMFDefault rather than CMFCore.  This has been a bugbear of mine for
some time.  We have a really great framework, but very few people use
it directly.  When people install it, they naturally take CMFDefault
as a starting point.  It kind of sucks, so they either dump it, or go
and use Plone (which originally was pretty much a CMFDefault skin) or
CPS.  I think it would be better for the health of the entire CMF
ecosystem (including Plone and CPS) if people were encouraged to
experiment more with building their own systems from core components
and, more importantly, a richer set of best practice examples.

Here's one way of approaching it: we could rename CMFDefault to be
"CMFPortalExample", and we could create another example system called
"CMFPetShopExample", and maybe another called
"CMFLocalTownWebsiteExample".  They would all be availble bundled with
CMFCore, or separately.  These would allow us to experiment
collaboratively on building on best practise applications of CMFCore
and find new targets for CMFCore development based on approximately
real-life requirements.

One real-life requirement that some people have is the separation of
content management and content delivery, hence my XML/XSLT example. 
At Jamkit, we've been talking about this for some time.  Paul
Everitt's been pimping it for about 2 years.  I know a number of other
companies think it's a promising approach.  If there was a space
within the CMF to develop the idea, with Tres as a neutral pope,
perhaps it could go somewhere?

I realise my comments aren't necessarily helpful coming from someone
who's not contributed anything to the CMF community for 2 or 3 years. 
But FWIW I do think a direction like this would really encourage more
people to come on board, and possibly re-invigorate the community
around the CMF.  OTOH if this proposal does turn out to be of interest
to others, I think it would take quite some time for things to
crystalise, and in the mean time, further Zope3 integration seems a
reasonable interim goal.
_______________________________________________
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

Reply via email to