[Zope-CMF] Re: Our CMF-CMS Demo (LONG!)

[Jon Edwards]

> -----Original Message-----
> From: seb@lenin.jamkit.com [mailto:seb@lenin.jamkit.com]On Behalf Of Seb
> Bacon
> Sent: 04 July 2001 10:28
>
> > just brief "back-of-a-cigarette-packet" notes?

Thanks Seb, that helps a lot.

That's a big cigarette-packet, what are you smoking? ;-)

> That's pretty much what I meant, although I'd go further and say a
> standard should the basis for a community implementation, too.

Sorry, I didn't mean to imply that only people currently working on a CMS
should contribute

> I see a need for a community / DC standard for a CMF-based CMS,
> which takes the best from all worlds.  It should follow the principles
> DC has layed out for the CMF - a framework, not an application[1].

So, in layman's terms, we're trying to produce a spec for a "portal_CMS"
tool? Different people can produce different versions (just as they can with
the portal_workflow tool), but as long as they all adhere to that spec,
users will be able to pick and choose which one they use?

Actually, to use your examples below, you might have several tools -
portal_layout, portal_navigation, portal_compdocument, etc. In an ideal
world, it would be great if they were all interchangeable (so you could use
one CMS' portal_layout with another CMS' portal_navigation), but that's
maybe a bit over-ambitious for now? :-)

I'm not qualified to design the underlying API structure (to me, "Design
Patterns" are what my girlfriend looks at when she's choosing new curtains)
but I've added my thoughts below, in the hope that they might help!

Personally, I subscribe to the "Lumberjack" methodology of software design -
keep hacking till it falls into place! ;-)

Warning : What follows is very long, cos I've tried to explain how we do it
now, and how I think it should be done (or how I intend to rewrite it)

> The main problems, I think, are:
>
>  - Page composition.
>
>  - Template (layout) editing.

In our system (see the original post in this thread if you want to login as
an editor and play along!), I think we're working along the lines you
describe for Page Composition. Each page is a folder, with properties that
determine what it looks like and what it contains.

The main ones are -
------------------------------------------------------------------------
Layout choice -

- which page template/skeleton to use. Properties for everything except the
central "body" of the page are stored in the layout - handy for quickly
creating consistent pages, but means you have to create a new layout even
for small changes (like having a different header-colour for different
sections of your site, for example).

I'm thinking of storing more of these properties at the page-level, then
when you add a new page, it automatically pulls its properties from the next
above it in the hierarchy. That way you, hopefully, get the best of both
worlds - quick and easy to add new pages that fit the look of the rest of
the site, but with the ability to tweak them if necessary.

-----------------------------------------------------------------------

Stylesheet -

- the combination of being able to pick from several different layouts and
stylesheets solves one of the problems of the "portals within portals"
discussion - different sections of your site can have different layouts and
colour-schemes, but you can still inherit things like headers or news-box
from higher up, giving some consistent elemnts across all your
"sub-portals".

See also the ideas about making stylesheets more editable (and creating a
Site StyleGuide) in the thread about the wysiwyg editor.

-----------------------------------------------------------------------

Section choice -

- a picklist of which method to show in the central "body" of the page. If I
had composite-docs, this is where I'd see most use for them - composite docs
created anywhere on the site would be included in the picklist (perhaps with
some filtering according to what section you are in, and what permissions
the page editor has?).

At the moment, each one is a dtml-method (which functions a bit like a
composite-doc would). I think every one of the methods in the list will work
from any page in the site, so feel free to try a few! Though some of them
may give an empty page, depending on whether there are any content-objects
in the folder you are playing with.

All the methods live happily together in a folder in skins, and when you
choose one, you are not copying anything into your page-folder, just calling
the method.

Gregoire, I think this solves the problem you mentioned for "portals within
portals", where you want some content to be "syndicated" within the site,
without the hassle of RSS? For example, you can select the "PCG
Announcements" option for any page in the site. The content will be the
same, but the page-layout of that section may be different, and the
stylesheet properties may be different, so that it fits in with the local
design.

These methods are of three types -

1. Methods that do something with the content-objects stored in the actual
page-folder itself - "List all items", "List selected items", "Members
Weblog", and "Sub-folders list". "Members Weblog" for example, isn't a real
weblog! It just displays all the documents in its folder, in reverse order
of last-modified date. (a quick hack for now, until I get time to play with
Blark properly!)

2. Methods that display contents from a "hidden folder" - "PCG
Announcements", "Logolinks", and "Self-help page". Normally, whenever you
add a new page, it will automatically be shown in the menu on the left. But
if you go to the Home Page, then click "Folder Contents", you'll see
"xannouncepage", "xlogolinkpage" and "xselfhelppage". These have an extra
"ishidden" property to stop them being displayed by the menu (and I prefixed
them with "x" in case someone added one with the same name, by accident -
must find a better way to do this!). If you click on xannouncepage, for
example, you'll see all the documents that are displayed by the "PCG
Announcements" method. Add a new document here (nothing rude please!), and
it will be shown by that method, wherever it is used in the site.

3. Methods that pull content from outside the portal - most of the "News"
sections are just displaying methods that live in the root of the site,
above the portal (so that they can be used in any portal) - this may change
once we get the incoming-syndication tool, but it's a handy trick for
sharing content across several portals.

-----------------------------------------------------------------------

Introduction -

- a text property of each pagefolder. This text gets shown at the top of the
centre/body of the page. For simple pages, you could actually just type all
your content in here. It's also handy when you are using the "internally
syndicated" methods mentioned above, as it means you can have a custom intro
above the standard content.

------------------------------------------------------------------------

To improve the structure of it all, I wonder if we need an extra object -
something like "Content-object-style"? Describes how a content-object should
be displayed in a particular context, just as a CSS-style describes how a
chunk of text should be displayed in a particular context. You'd use these,
somehow, to define how content-objects should be displayed in composite
docs/layouts. Another half-baked idea! :-)

-----------------------------------------------------------------------

<Example>
After logging-in to the demo, go to the Home page.
Click "Change Folder" on the actions-bar at the top.
This form shows you the properties stored for the page.
Most should be self-explanatory, "Section choice" tells it which method to
display in the body of the page.

With the "Layout choice" dropdown, select option 5.
(N.B. Don't try layout 1 - it's one i hacked for a demo, that won't work on
most pages)
Click the "Change" button, then "View"
(OK, it's a very similar layout, but you get the idea! ;-)

Click "Change Folder".
Click the "Edit Page Layout" link next to the dropdown.
Try different colours and borders, but don't change the "Content" settings
or you'll break it (I need to make a select box for these of allowed
content).
Click "View" to see your changes.
Also try different stylesheets and then click "Edit Stylesheet" to play
around with different fonts and colours.

Change the "Content" setting for "Cell 1" from "pcg_pagesmenu" to
"pcg_pagesmenu2".
"View" the page, and the menu on the left will now be a tree-menu
(autogenerated by looking at the folder hierarchy underneath)
</Example>

In terms of the "portals within portals" issue, the one thing I haven't done
is the ability to restrict searches to sub-portals only, rather than the
whole site (this would also apply to the news_box). There was a recent
thread on this, but I haven't tried any of the suggestions yet. So if anyone
has tried them and found one that works nicely, I'd be glad to hear!


>  - Navigational control
>    We need a standard framework for creating navigations, so they can
>    be 'dropped in' to any site.  A natural one is to use the Zope
>    folder hierarchy, and build navigations by walking the tree(s).

This is how I do the auto-generated pcg_pagesmenu/pcg_pagesmenu2 that shows
in the lefthand column.

I think RadioUserland has a kind of central database/list of pages on your
site. Perhaps something like this could be used for more advanced
navigation? Might also be handy when you are adding links to pages to be
able to call up this list somehow, to save you having to surf off, find the
page you want to link to, go back to where you were, then copy in the url?

> Other (simpler) issues, some one which are not necessarily
> 'framework' problems, are:
>
>   - UI (edit items in situ, or from a different location)

I'm not sure what you mean by this Seb?

>
> Well, that'll do for starters :-)

Ditto! ;-)

Apologies for the length of the message!

HTH

Cheers, Jon