[Zope-CMF] Documentation request

Jon Edwards jon@pcgs.freeserve.co.uk
Thu, 2 Aug 2001 14:54:02 +0100


> Most of my site, like the http://cmf.zope.org/ homepage, doesn't really
fit
> that mold. It's rather static content, probably typed by me, and doesn't
> need the "Created by" label or the last modified datetime. But the content
> should be searchable. Presumably, this content is added as a regular DTML
> Method from the ZMI (Zope Management Interface).
>
> So it seems there are two types of content here (merging all CMF-specific
> stuff together). People coming from regular Zope (like me) are familiar
with
> DTML Methods and Documents. We need some information about taking what we
> know and fitting it into the CMF model

<offtopic rant>
This is why I think it's important to retain DTML skins (even if they're
only basic ones), after the conversion to ZPT - there will be lots of people
converting over from "vanilla Zope", who may never have used ZPT, but have a
good knowledge of DTML. Playing round with the methods in portal_skins is
IMHO a great way to learn CMF, and will ease the learning curve for these
people.
</offtopic rant>

A couple of points (and a silly metaphor) that may, or may not, be helpful
;-)

1. The portal_catalog is the heart of the CMF, the DTML-methods and
Python-scripts in portal_skins are the muscles and blood-vessels, metadata
is the skeleton, portal_types are the flesh. You're Dr Frankenstein, hacking
and gluing those raw materials together to build your monster!

2. 90% of what you want to do will already have been done somewhere in
portal_skins. Think of them as examples of what you can do with CMF, rather
than fixed-in-stone parts of the product. Have a dig round and customise
things a bit, take bits from different methods and combine them in different
ways. Most of it is DTML, so you don't even need to know Python to be able
to achieve a lot!

The "portal_types" define the different sorts of content that can be stored
in your system - documents, images, links, etc. There's nothing to stop you
using "old-fashioned" DTML methods or documents for content, but I think
you'll kick yourself in a couple of months if you do! You may not need all
the metadata elements at the moment, but they may come in handy later.

For example, your post about using the Types-Tool to create a "How-To" type,
based on Document is perfect (and a great idea IMHO). But suppose, in a few
months, you have hundreds of How-To's and you need to make sense of them.

You could easily create a "What's New" page, by copying-and-hacking the
news_box method (in portal_skins/generic) so that it finds the latest 10
How-To's, displays the Title and Description, and a "read more..." link to
the full text. If metadata has been used sensibly, you can find all the
How-To's where the Creator == 'Tres', or where the Subject == 'Portal
Catalog'... and so on.

All of this depends on the Catalog, and the Metadata that is used to
describe your content objects (which is stored in the Catalog).

If you click on "portal_catalog" in the ZMI, then the "Catalog" tab, you'll
see which objects are being stored. Click on one of the objects, and a new
window will open, showing you all the metadata that is stored for that
object.

If you look in the "portal_types" tool at Document, and click on the
"Actions" tab, you'll see that every Type has a View action (amongst
others). This is what is used, by defualt, whenever you call an object of
that type. So, taking the example test document on your site, you can change
the way it (and any other Document) is displayed by finding the
"document_view" method in portal_skins/content, and hacking it around (by
using the "Customize" button).

You might, for example, put <h2><dtml-var title></h2> at the top, and move
<dtml-var content_byline> to the bottom. Now, whenever a Document is viewed,
it will have this new layout. Note that "content_byline" is itself a DTML
method in portal_skins/generic, so you can change it to display whatever you
want, or delete it from "document_view" altogether.

Hope that helps :-)

Cheers, Jon