[Zope-CMF] RE: "generic" CookedBody - compound/composite docs

[marc lindahl]

Interesting, hadn't seen that proposal.  But notice in Event distribution
the line "Workflow and other events that happen to the compound are passed
along to the contained elements" which implies that the contained elements
have some intelligence.  My point being, the compound doc doesn't have to
wrap every 'CookedBody' reference with a bunch of workflow-state-checking
logic, which if broken could expose the wrong state of a document.

> From: "Jon Edwards" <jon@pcgs.freeserve.co.uk>
> But it would
> be tricky for sites where content is changing regularly.

And also for templates where the template may have to be viewable regardless
of content's state.

> What if you've
> created your composite page, then the owner of one of the documents in it
> retracts it to update it? Nasty gaping hole in your page!

Well, nasty gaping hole (or a message from workflow saying 'unpublished...'
or some such) is better than seeing something that shouldn't be viewable!


> 
> Maybe you have to somehow link the workflow of the elements to those of the
> composite? Could be something simple like a tag "ispublished".

I believe you can get the workflow state for any object.

>If
> ispublished is true, you can't retract the element?

It depends on the workflow (try playing with the DCWorkflow's TTW interface
-- way cool!)

> But if you take Seb's
> point about having composites-within-composites, you're gonna get a very
> complicated chain of dependencies! :-)

True, which is why having every element deal with it's own dogfood, it's
simplified.

> 
> Even so, I would think all the logic would be handled by code for the
> composite, or its workflow, not by the "genericBody" method?
> 
> Hope that makes sense? Am I missing your point? :-)

My point being, since objects have workflows, why shouldn't their Body
methods use them for how to render?  Why have to put that bit of programming
outside the object?