Re: Providing configuration options for Authors

Hi Kit,

I have a lot to say about this, but I'll try and respond inline to your email:

On Friday 04 January 2008 05:03:11 am Kit BLAKE wrote:
> 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).

And the news category filter does affect content.  However, I could see 
possibly being a metadata set on containers.  What I don't like about that 
direction is that the metadata set would be listed in the properties tab of 
_every_ container, even within publications / sites that aren't using 
SilvaNews.  That is, so long as SilvaNews is installed in the site's Silva 
Root.
>
> 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.)

And another further restriction is that there can only be one in any given 
container.  
Regarding name changes...I wonder if it would be possible to query the catalog 
for config objects within the current model's hierarchy?  Basically this 
would be "acquisition via metatype".  Or (thinking specifically of SilvaNews) 
the News Service could hold information (object, path) for each of these 
config objects.  The nearest config is looked up using this service, rather 
than acquisition.  But, either method possible seems a bit too much work just 
to allow renaming the content objects.
>
> 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.

Actually, since they're Silva Content objects, one could query the catalog for 
the config object's meta type and get all of them.
>
> 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.

I'm glad the category feature SilvaMetadata, and how one can take advantage of 
it, is now partially documented.  I've wondered about how one can leverage 
the category of a metadata set.  Hmmm...interesting.  More on this in a bit.
>
> 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.

And one could argue that using a metadata set for long-term template/layout 
settings is just asking for trouble, since template/layout settings _will_ 
change!  IMO, this lack of future-support is a big drawback to using 
metadata...if only there were tools that could assist silva managers / 
template developers in changing metadata.  A ZMI service (perhaps built into 
the metadata service) that would allow you to search metadata (it would need 
to be indexed in the catalog) and replace values for a field that are no 
longer valid would be very nice indeed.
>
> 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.

I agree.  But I think that you don't see the acquired value if you have a 
value set?
>
> 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.

Yes, also very nice.

>
> 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.

I've found that SilvaMetadata isn't documented well enough for silva managers 
to be able to leverage this.

Is it possible to have access restrictions such that editors+ can change the 
metadata set, but readers+ can view it?  When dealing with template/layout 
settings, I think this is important in order to enable authors to make more 
informed decisions when creating content.
>
> 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?

I have a few more.  I'm going to respond to Jon Bowlas' comments here, as 
well.

First, here's an idea.  It has been stated that using a config object is a pro 
because it exposes the fact that this container is config settings.  And, 
using metadata is a con because it is difficult to locate where a particular 
setting is actually set (jon explains this case very well).

Think about this: 
Let's define a new metadata category, say "template".  Template/Layout 
metadata sets are created using this category.
Sets with this category are edited by clicking a new 'middleground' button on 
the properties tab, next to 'settings', called 'template'.
The middleground of other tabs (like the contents and edit tabs) have 
a 'template' button that only displays if the current object has settings in 
this metadata category.
Pros: 
1) there is no config object
2) the metadata system is used
3) it is easy to locate objects that have template settings defined locally, 
because the 'template' button will appear in the first tab of the content 
object in the middleground.
Cons:
1) it may be confusing to see a 'template' button in the middle ground of the 
main tab on only some objects.  But, this should easy enough to get used to.
2) determining if the current object has locally defined template settings may 
potentially slow down the rendering of those tabs.

Second idea:
During ongoing development of Bethel's cms, I've touched most of the core 
Silva objects, and developed in-house a number of custom ones.  This 
conversation has brought up the fact that a good number of these content 
objects' edit tabs just display metadata (that controls how the public view 
functions).  BUT, internally it's not represented as metadata.  Jon points 
out that:
>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.
These content types _all_ have distinct accessors that get to these metadata 
attributes.  Let's look at the AutoTOC object as an example.  AutoTOC (as of 
Silva 2.0) has many configuration settings (types to dipslay, depth, display 
description, show icon, sort order).  All of these are represented in the 
code in three places:
1) __init__ defines the private variable
2 and 3) a getter and setter
All of this could be done using metadata.  And the metadata set could have a 
special category name of, say, 'content', that would make it not appear on 
the properties tab, and only on the 'edit' tab.

Code could "significantly" be reduced using this method.  No more accessors at 
the python level, and the edit tabs could all use the same macro for 
rendering.

Third thought:
Bethel's templating/layout system is very flexible.  We added a 'template' tab 
to all containers to handle the templates.  On the template table for a 
container that has a template set, you can choose between the multiple 
templates Bethel uses (internal template, external template, and a few for 
special-case websites).  The template settings use formulator, so basically 
they're already metadata sets.
The one big advantage this system has over using metadata sets is that there 
is no 'metadata' clutter.  If each of these was a metadata set, they'd all 
appear on some tab.  But, the template manager only cares about the template 
settings for the current template on a container, so there is no clutter.

Fourth thought (related to the third):
The formulator forms are really quite flexible.  But, I don't know if metadata 
sets expose the same flexibility.  Let me explain.  Our public template has a 
number of settings.  Some of the settings are only relevant if a different 
setting is enabled (i.e. has a value of 'yes').  So, they depend on the value 
of another setting.  
Example:  A "display left nav menu" setting.  If set to yes, then you also see 
the following: "left nav header" and "left nav footer", for content that will 
appear above and below the left nav.  You don't need to see these two 
settings if 'display left nav menu' is set to "no". 
This is possible using formulator, but unfortunately you have to click "save" 
before the dependent fields will display.


Fifth thought (related to multiple switchable templates):
I suppose going forward the way to switch templates is to define/register each 
template as a SilvaLayout.  You then switch between them on the settings tab.
The big 'con' for this is that you probably have different metadata associated 
with each layout, but if you're using metadata sets, how do you only display 
the one for that layout?

I don't know the best way to do this, other than associating a layout metadata 
set with a layout (perhaps when the layout is registered).  I would recommend 
that the layout setting (which is in the settings tab) be moved to 
this 'template' tab.  When SilvaLayout is installed, the template tab 
displays a choice of registered templates, and below that choice the metadata 
set for the template.

Well, now I'm out of breath.

Cheers,
Andy