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 - [email protected] http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
