Paul Winkler wrote:
On Wed, Aug 21, 2002 at 04:44:29PM -0500, Evan Simpson wrote:
Obviously, this may not work for you if you have a different model for user interaction with content. If you can, I advise using the CMF.
This brings up an issue I'm dealing with currently...
I've got largish amounts of content objects which need to be managed by a small (under 10) group of people internally, and viewed (not managed) on the internet. We're moving to using CMF-based solutions for management, but for presentation to the outside world, the "portal" metaphor isn't really that relevant - our site is not personalizable (is that a word?), nor can the general public log in. And we have a design for the site which doesn't look anything lke an existing CMF skin.
I see two options:
1) Create a skin for the public which hides all the management stuff (and, in fact, looks & feels *completely* different from the management skin).
2) Create a separate section of our site which is purely for presentation, and pulls content out of CMF. (love that CookedBody() method!)
Has anyone gone down either or both of these paths? Any comments on pros & cons of either approach?
I have a feeling that option 2 might be easier to manage in terms of security.
Paul, its sound like you never used the CMF in a project, and are therefore in a situation like me some months before. Even if not, I'll just write down my experience when using CMF, maybe it's informative for someone else . I always heard how cool CMF is and what nice solutions you get when using it - and everytime I looked at it/installed it, it looked like a framework for community driven slashcode sites. Only when I had the problem of giving users several "intelligent" templates to work with, freely interchangeable even after creating the content, I got the tip to look at CMF. I had to use a fs-based product from the beginning and first looked at the CMF-equivalent (roughly) of the nice mxmEasyProduct - don't remembe the name ATM, to see what stuff a CMF product has to implement. I didn't like the CMF mgmnt-interface, so I wrote a "hybrid" product of some sort, because it uses the ZMI for its interface. I think of this memberstuff and skin stuff as services, and the stock CMF stuff as an "maximal" example application which just tries to show off anything the CMF has to offer. Arguably not in an optimal form - the stock ZMI interface is really more convenient than the CMF interface IMO. But that this represents the "portal" metaphor is not surprising, because the concept of a portal aims to use any technology which is available to enrich its content. But using the CMF is really a joy and is probably not limited to building community sites, it's really zope-as-a-publishing-system taken to the next level of existence. Just replace _all_ of the standard skins with your own, and you are as productive as with a zope python product, just much more flexible. cheers, oliver