Re: Providing configuration options for Authors

Hi All,


As some of you are aware, (Kit, Andy A) here at UCL we have a 'Silva UCL
Attribute' object (asset subclass), this allows SMI users to modify any
number of presentation variables including, type of menu to display, colour
of top banner, number of columns to site layout etc etc, this works in
conjunction with our UCLDefaultLayout to allow small amounts of
customisation within the boundaries of our corporate identity. We feel this
works well and provides the flexibility we need, however as Kit states the
id's of the objects can never be changed due to the layout code looking for
a config object using acquisition, but this was pretty simple to achieve. We
ensured the object_id in the add form was always set with a default value
and to readonly and also object renaming in the SMI was prevented with a
slight modification to tab_edit_rename.pt. 

I agree with Kit that the benefits of this object is that they're easy to
find as they're in the contents screen, however we often have a situation
where by slight modifications i.e. a different banner colour, are required
from the root attributes further up the folder hierarchy so the root
attribute needs to be duplicated and copied into the relevant folder and the
changes made to this instance. So potentially if there are slight variations
needed to each folder of a publication you can end up with a large number of
attribute objects to any one publication. 

Another issue is adding new fields or modifying existing ones, this involves
writing more accessors, modifying the forms and integrating these changes
into the layouts, not to mention updating all current instances to provide
this new functionality, all of which is time consuming business.


In reference to utilising metadata sets I can only envisage one issue at
present which could arise with modifications of metadata sets on multiple
objects with a publication. I.e attempting to locate the metadata of each
folder, publication or document to determine why something is not displaying
correctly, or appearing when it shouldn't be. Furthermore copying folders
could be problematic if the users have a metadata set on the copied object
which isn't relevant to where they're being pasted. Many users might not
think to look in the properties tab to correct it. - But I guess that's a
training issue.

Well that's my two-penneth worth (two-cents worth for US readers ;) ) for
now. Hope it all makes sense.

Cheers

Jon


-----Original Message-----
From: silva-dev-bounces-IAPFreCvJWM6s/[email protected]
[mailto:silva-dev-bounces-IAPFreCvJWM6s/[email protected]] On Behalf Of Kit BLAKE
Sent: 04 January 2008 11:03
To: silva-developer
Subject: [silva-dev] 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
silva-dev-IAPFreCvJWM6s/[email protected]
https://lists.infrae.com/mailman/listinfo/silva-dev