Re: Providing configuration options for Authors

Hi,

Just got time to take another look at this,

Like the idea of option 2 Andy, anything to reduce code.

Regarding your third thought, when making a template selection on the
'template' tab does this refresh the page to display the metadata settings
form below or would these settings be accessible through the properties or
settings tab?

Fourth thought: - could this not be achieved using javascript?

Ok, if I understand correctly I think I like the sound of your fifth thought
best Andy. 

So should we aim to achieve something like this?

Create a template that contains a metadata set of layout options, when a
single template is installed a new 'Template' tab appears in the smi, this
has a select list of all the template types installed. Selecting an option
from this list would ideally refresh the page to display the metadata set
options associated with this template. This new tab would appear on
publications, folders, and documents (silva news too). Layouts and settings
are acquired but can be overridden higher up. 

Notes: 
The user should be prompted if overriding default layout options higher up
the container hierarchy.

Only managers and chief editors should be able to add templates and modify
settings at the root of their publication or higher up. Authors can view the
settings.

How about if we had 1 template metadata set of configuration options for
your default organisation template, usually applied to your silva root? This
would have has global setting options that are universal across all
templates and any additional settings for templates further up can either
override these or extend the existing set.

Well that's all for now.

Cheers

Jon

-----Original Message-----
From: silva-dev-bounces-IAPFreCvJWM6s/[email protected]
[mailto:silva-dev-bounces-IAPFreCvJWM6s/[email protected]] On Behalf Of Andy Altepeter
Sent: 10 January 2008 17:47
To: silva-dev-IAPFreCvJWM6s/[email protected]
Cc: Kit BLAKE
Subject: Re: [silva-dev] 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



















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