Hi Bertrand! ----- Original Message ----- From: "Bertrand Delacretaz" <[EMAIL PROTECTED]>
> On Sunday 20 January 2002 18:12, Robert Koberg wrote: > > Should the publishing system or the content management system handle site > > promotions (dev, qa, live)? > > I think the decision about what status to give to each piece of content > belong to the cms. > > But the decision about publishing or not belongs IMHO to the publishing > system (assuming cms and publishing system share the same content database, > which makes things much easier to manage). > > Good servlet-based transactional apps do that by having a single "checkpoint" > through which all requests go, where you can put all the rules about who has > access to what. > > In this case, we want to give access rights based on *content*, for example > filtering out certain information or navigation options before publishing. > > If I had to do this in Cocoon, my first idea would be to "manually" put > an additional "access control Transformer" right after the "data acess" (i.e. > Generator) and before the actual "publishing" pipelines (other Transformers). > > This is certainly doable by making sure each pipeline include this > AccessControlTransformer (xslt or something) right after the Generator stage, > but maybe there is a better way? The idea would be to force all content > through a filter based on the request AND the content being delivered. Is something that has been published content (for example, the resulting HTML page)? Content remains unaffected when publishing in my view. Content should only be affected during development and bug fixing. During QA --> Live the content should never change (but perhaps it's location does, or not). I think we are talking about semantics here, I just want to get on the same page. best, -Rob --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
