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

[Jon Edwards]

> That means putting the logic into the composite page -- all over
> the place,
> and if you don't to it correctly, your workflow is blown.

Errr... I thought the composite/compound page was the best place for that
logic, see
http://cmf.zope.org/rqmts/proposals/compounds/compoundproposal.txt/view

I'd have thought that when a user/editor creates a compound page, they would
either

a) Select manually the elements they want to show up in the page - story a,
picture b, linklist c - all of which probably would have to be "published"
to be "pickable"

b) Have some automatic method that picks the elements to be included - a bit
like a Topic, where you set criteria, which include workflow-state (which
again, would usually be "published")

Thinking about it further, that would work fine for a news-site, as
mentioned in the proposal, where you kinda publish-and-forget. But it would
be tricky for sites where content is changing regularly. 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!

Maybe you have to somehow link the workflow of the elements to those of the
composite? Could be something simple like a tag "ispublished". If
ispublished is true, you can't retract the element? But if you take Seb's
point about having composites-within-composites, you're gonna get a very
complicated chain of dependencies! :-)

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? :-)

Cheers, Jon