Providing configuration options for Authors

Hi,
There's been some discussion in other channels about how to provide site 
or page configuration options for Authors. This mail moves the 
discussion into an archivable format ;)

There's two ways to go with this: write a configuration object that can 
be added to the SMI and then edited, or make a metadata set that will 
present editable settings. My preference is for the latter, but first 
some arguments about the former.

The main thing that bugs me about having a configuration object is that 
it looks like content. All the other things an Author sees in the SMI 
contents screen are content types (well, there is one asset that 
manipulates content, news filters, and they *are* a gray area).

Another disadvantage is the config object must have a specific id. This 
is because code (either presentation code in templates or maybe file 
system code) will be looking for a config object using acquisition. So 
we must force Authors to use a specific id, and hope they don't ever 
change it. There are various ways to rename content objects in the SMI, 
and we can't prevent an object from having it's id changed, so this 
remains a danger. (One can point out that there are services that need 
specific names, but those are in the ZMI, only accessible by managers, 
and when we create them we specify an id that can't be edited at 
creation time.)

One advantage of the config object is it's easy to find for Authors, 
since it's in the contents screen. In a big site it might be possible to 
find them all with a Zope search.

Creating a metadata set has pros and cons too. Let's start with a common 
use case: prefixing the html title (as in the title tag in the html 
head). Many site managers are happy to use the Silva title of the 
current content as the title, but like to have it prefixed so when 
visitors bookmark it, the suggested title for the contact page is not 
"Contact", but "Prefix: Contact", where prefix is the name of their 
organization. The prefix can be changed at lower levels of the site so 
the title becomes "Prefix Section: Title". Or it can be configured to be 
blank.

This one-field metadata set is content related, so it probably should 
appear in the properties screen of the SMI. It'll show up below the 
standard Silva sets, Silva Content and Silva Meta. Authors can then fill 
in the prefix field and the template that renders the public page will 
use it.

If a set is created that offers layout options, which aren't content, we 
can give the set a 'layout' category (<category>layout</category>) and 
it'll appear in the settings screen, below the renderer and feed 
configurations.

Creating a metadata set means creating a formulator form in the metadata 
system. There's a small learning curve to this, and the ui could be 
friendlier, but it's not something that happens often. That's also one 
of the advantages; you can add fields later without messing up anything 
(changing default values of existing fields is asking for trouble 
though). So in our use case we'd make a set with one string field, Title 
Prefix, and make it acquirable.

Metadata fields can be set to be acquired or not. If they are acquired 
and there's a value set higher in the content tree, the Author can see 
that. This is a big advantage.

Once created, a metadata set must be mapped to content types. This means 
it can be applied to, say, the Silva Root, publications, folders, and 
documents. When you go to the properties screen of any of those types 
the set will appear, but not for images, files, etc.

Metadata sets can have access restricted by role. You can make a set 
that will only appear for Editors, or Chief Editors, or even Managers.

Metadata sets are xml. Look in the 'doc' directory of the Silva product 
to see the standard sets. This means they can be imported and exported 
across sites using the metadata system. No restart required.

Because they're xml they can be checked into svn for version control.

By using the metadata system the developer is utilizing existing 
infrastructure and doesn't have to maintain any custom code. This is a 
huge advantage :)

Any other pros or cons?

-- 
Kit BLAKE · Infrae · http://infrae.com/ + 31 10 243 7051
Hoevestraat 10 · 3033 GC · Rotterdam + The Netherlands
OpenPGP 0xE67AD0F2 · Contact = http://xri.net/=kitblake

_______________________________________________
silva-dev mailing list
[email protected]
https://lists.infrae.com/mailman/listinfo/silva-dev