[Hippo-cms7-user] Plugin settings, confiugration, preferences and context

Bart van der Schans b.vanderschans at onehippo.com
Wed Jun 8 11:30:34 CEST 2011


Hi Mathijs,

On Tue, Jun 7, 2011 at 11:02 AM, Mathijs den Burger
<m.denburger at onehippo.com> wrote:
> Hi Bart,
>
> I like the idea of better settings management! But: what do you mean with
> "plugins"? CMS plugins? HST components?

All of the above and more ;-) The idea is to have a general abstract
way of storing settings that is provided through an api that can be
bundled with the repository api package. This api can be used by
"anything" that needs to store settings in the repository. That could
also be standalone rss feeds, importers, eventlogging, external
integration settings, etc.

> Both already have a way of storing settings (the IPluginConfig interface and
> the HST component parameters). The default configuration values are often
> hardcoded in Java, while the plugin configuration values and HST component
> parameters in the repository act as 'preferences' that can be changed via
> the console or (for HST components) via the HST configuration editor in the
> CMS.

CMS plugins can/should use IPluginConfig interface. For HST components
I'm not aware of something similar. Both mechanisms do not have ways
to deal with context, preferences and cluster nodes. Also note that a
plugin that has a CMS and HST part has to deal with two different
mechanisms. The IPluginConfig interface is only available through the
CMS. This leads to devs creating custom "config folders" for things
like importers. I've seen this in many projects.


> The messy part right now seems to me that it is pretty hard to figure out
> which preferences have been set in a context (e.g. "which parameters have
> been changed from the default values on the production server"). Storing
> them separately would make it a lot easier to identify the customized
> preferences, and should also make upgrades easier.
>
> As for the interface: why would every setting consist of _multiple_ string
> values? I'd expect a simple (String key, String value) pair per setting.

A lot of settings seem to deal with multiple values. It's quite easy
to store a single value in a multivalue. It's quite hard to store a
multivalue in a single value.

Regards,
Bart


>
> -Mathijs
>
>
> On Thu, Jun 2, 2011 at 5:54 PM, Bart van der Schans
> <b.vanderschans at onehippo.com> wrote:
>>
>> Hi all,
>>
>> Currently there is no clearly defined way for plugins to store
>> settings. Some plugins seem to have some mechanism of their own, some
>> don't. This has the potential to become very messy as the number of
>> plugins is growing. So I'll take a first stab at a
>> concept/architecture for this so people can shoot holes in it.
>>
>> -- settings, configuration, preferences,  context and nodes, definitions:
>>
>> - setting: a key-value combination used by the plugin
>> - configuration: the initial default, read-only plugin configuration.
>> This can always be cleanly overwritten and replaced by the plugin
>> itself.
>> - preferences: a value that is changed for the specific installation
>> - context: also called environment in DTAP, this will usually be prod.
>> acct, test, etc.
>> - nodes: identifies a specific node in the cluster, usually the cluster
>> node id
>>
>> Why do we need these definitions? This is easiest explained by some
>> examples.
>>
>> The configuration contains information that should not be changed and
>> the defaults. For example when you have a plugin that shows a list, it
>> can contain certain class name of the plugin and an default value of
>> the list length for pagination. Having the default values in the
>> configuration will make it easy to "restore" the plugin's defaults by
>> just removing the preferences.
>>
>> The preferences contain settings that are different from the defaults.
>> Usually this will be either installment specific settings, like
>> changing the page list length from the previous example. The
>> preferences should be context aware. So an email address a certain
>> form can be different in test from production. It should also be node
>> aware, for example you might want to run an importer on a certain
>> node, but not others, so you want to specify the crontab config only
>> for a certain node in a certain context. As a bonus, configuring a
>> setting for a certain node allows you to "test" and setting on a
>> certain node which could be excluded in the loadbalancer, without
>> interfering with other settings.
>>
>> As you will have noted there is a hierarchy to this. The most specific
>> the setting should be used. So node specific settings override context
>> specific setting which override general preferences which overrides
>> the (default) configuration. This hierarchy should be hidden from
>> plugins itself. Therefor a plugin settings api is needed which should
>> be very simple to use: It's methods could look something like:
>>
>> void replcateConfiguration(String plugin, Config config)
>> String[] getSetting(String plugin, String key)
>> void storeSetting(String plugin, String plugin, String values[])
>> void storeSetting(String plugin, String values[], String context)
>> void storeSetting(String plugin, String values[], String context, String
>> node)
>> String[] listPlugins()
>> String[] listPluginKeys()
>>
>> (whether is an String[], a list of Strings or an iterator is an
>> implementation detail imo)
>>
>> With this api it should be very easy to build a generic settings
>> manager plugin in the CMS and very straigth forward for plugins to
>> provide a configuration and fetch and store settings. I explicitly do
>> not include type safety in this api like the java Properties). Imo
>> that would just clutter the api, It would require for alll store and
>> get setting method to have singe and multivalues and those again for
>> all primitive/boxed  types. I think we would be better off by
>> implementing a simpler settings helper class that cleanly converts
>> between primitives and and strings. But this approach is of course
>> debatable.
>>
>> Also note that there is no JCR stuff in the api. Imo plugins don't
>> need to know the storage implementation (details).
>>
>> The settings manager, that takes should take care of storing and
>> retrieving the settings. Therefor it should be aware of context and
>> nodes. The storage itself could be quite easily mapped to JCR. For
>> example with a structure like:
>>
>> /plugin:configurations/<plugin name>
>> /plugin:preferences/<plugins name>/<context>/<node>
>>
>> The settings itself would be stored as multi valued strings on the
>> <plugin name>, <context> and <node> nodes.
>>
>> So, that's basically the idea, thanks for reading so far ;-)
>>
>> How would other people feel about such a settings architecture? Did
>> somebody already build something similar? Would it cover all/most
>> plugin needs? Is it too simple/complicated/strict/loose or utter crap?
>> I would like to hear your thoughts!
>>
>> Regards,
>> Bart
>>
>>
>> --
>> Amsterdam - Oosteinde 11, 1017 WT Amsterdam
>> Boston - 1 Broadway, Cambridge, MA 02142
>>
>> US +1 877 414 4776 (toll free)
>> Europe +31(0)20 522 4466
>> www.onehippo.com
>> _______________________________________________
>> Hippo-cms7-user mailing list and forums
>> http://www.onehippo.org/cms7/support/forums.html
>
>
> _______________________________________________
> Hippo-cms7-user mailing list and forums
> http://www.onehippo.org/cms7/support/forums.html
>



-- 
Amsterdam - Oosteinde 11, 1017 WT Amsterdam
Boston - 1 Broadway, Cambridge, MA 02142

US +1 877 414 4776 (toll free)
Europe +31(0)20 522 4466
www.onehippo.com



More information about the Hippo-cms7-user mailing list