[Zope-CMF] NOW: ways to include common content

Lynn Walton waltonl@franklin.edu
Mon, 27 Aug 2001 12:43:23 -0500


I'm having a hard time putting together all the various zope/cmf/zpt compenents to
give me the ease I want for
including common content in multiple places.

I understand macros in ZPT (PageTemplate) are supposed to be for defining common
presentation, not common content.

I was going to make all my basic mostly static pages be zpt's that used my main
master macro to get basic look & feel. But Ethan Mindlace reminded me that ZPT's are
not equal to content, and encouraged me to look at the CMF.

Now, I have headed toward the direction of having these many mostly static html
documents be a type of CMFDocument so obviously it goes through the CMF skins
mechanism to get it's look and feel.

I have two different "content reuse" scenarios I want to discuss.

To understand the first one, please understand that the navigation menu we want on
all pages is built by calling an external method that determines what "levels" of
our menu list to "expand" and "highlight" to show the user a kind of "you are here"
like context in the nav. menu.  I purposely didn't choose to make use of whatever
tree mechanisms are available because I didn't always want it to be tied to the
location in the folder hierarchy, and because we have a crazy way of treating one of
our levels ... which required custom logic.  Essentially, the external method needs
passed 3 parameters that tell it how to display the menu.

So I will make lots of FU_CMFDocuments ... which are just my own content object
based on CMFDocument but adding the 3 properties that I want to pass to my menu
building external method that's called in the main_template skin.  In other words,
it is the creator of a new FU_CMFDocument's job in setting these 3 properties to
tell what part of the menu structure this "content" is in .... that is tell what the
menu expansion and "you are here" type highlighting will be for that document.

Now, some of our documents will be used in more than one context ... by context in
this case I mean more than one area of our site (represented by one menu section).
In otherwords I want the content of someDoc which would have it's own three
properties saying "show me as if I'm in the "Current Students" section, the "such
and such subsection" , etc.   Now I want to use that same content but have it build
the menu indicating it is part of the "Prospective Students" section, "such and such
subsection", etc.    I can get it if I make a new ZPT and that ZPT has to use the
same master macro as my FU_CMFDocuments and then I have to set some global variables
(or ZPT properties once I upgrade to ZPT 1.4) that allow me to tell the external
menubuilding method what three parameters to use.
Then I have to do something like
           <div metal:fill-slot="main">
           <div tal:content="structure python:
here.aFirstFUDoc.CookedBody()">junk</div>
           </div>
to get the content I want to reuse.

So for every document I want to reuse with  different menu building parameters, I
have to build such a ZPT.
I guess it's serving like a glue method .... saying glue together  " this other ZPT
macro for presentation" and "this document's CookedBody for content" with these 3
properties (unique to this usage) the presentation macro needs.

So, if I end up doing this very much, I'm not sure if I'm really much ahead in not
using all zpt's for content instead of CMF.  Since ZPT's are part of the CMF
workflow, when whoever creates one of these ZPT's used in the way described above
it's not following the publish routine that our normal FU_CMFDocuments do.  And so
it seems I have a "hodge podge" of approaches.

This leads me to think ... if I could create a CMFCompoundDocument (actually I see
someone else has already done that with a slightly different meaning in mind than I
had) where the content is really a specification of what other content to use. (and
maybe sometimes more than one other content object ) I guess that would keep it in
the CMF workflow.  But I'm not sure how to do that.  Or should I?

Now on to the second desire for reuse of content .....
Let's just say I have certain lists of things that I find are often used in the body
of other contents.   I can see if the page I'm serving up is already the result of
some logic/query, etc then it's going to have it's own zpt's or dtml
methods/documents for presentation.   But in my case I'm not talking about those
kinds of "reports" that are built for querying and using different products.  I'm
talking about the fact that I have various random html document like content that
will use these common lists ... maybe some documents use them in the top of the 3rd
paragraph, some the middle of the page, some the bottom, ...etc.  So, I can't just
put it in my main skins because the placement is unique to each document.

Again it seems that in order to control where I can put it I have to have a zpt (or
dtml doc) so I can make use of calls/logic.   But then I'm creating lot's of
individual zpt's which aren't part of CMF workflow etc again.

What all this leads me to is wishing that the basic CMFDocument  itself was a ZPT so
that inside of it if I wanted to I could throw in a little logic. A call to a macro
in the spot I want it in in THIS document.

Obviously there is always logic ... that has to glue together presentation and
content.  It just seems that for my described uses, in order to get any content
reuse I have to build a separate logic object (like a ZPT) for everytime I need
reuse.   And that just doesn't feel right.  Isn't it practical for there to be a
mechanism to express a little logic in the content?  You can express logic in the
presentation (ZPT) but it's only good for reuse if it's placement is the same in
every document which isn't the case for me.  Anyone got any good ideas on this?

Shouldn't there be some mechanism for including content available from within the
content type?

Thanks,
Lynn