configure all the widgets

Last time I briefly covered our new front end process for the sparkly listings widget. This time I’m going to explain the thought behind, and show an example of, our widget configuration in a little more detail.

file format

In short, JSON. We use JSON for almost everything at MetaBroadcast, it’s easy to construct, parse and eyeball! For the widgets we have a JSON object for each client that gets parsed by Adam’s deployment scripts, we then use a section of this same configuration to set the default values for the widget on the front end (more on this below). This approach means we have a single point of configuration that bubbles right up to the end user. A single point of configuration equals maintainability *fist pump*.

private vs. public

One of the first decisions we made was to make the configuration open to clients. We provide default values, allowing someone to dump it straight into their page, but a client can override these when they initialise the widget. While this can cause errors if the configuration is incorrectly formatted or has erroneous properties it allows clients to experiment and alter widgets themselves.

If a client enters a string for a value that should be numeric, they get some readable, sensible feedback explaining why the value was incorrect. This is especially useful for cases when one of a few accepted values is required, for example we have nav.days = [number] that defines the number of days to display. To fit with standard EPG sizes the widget only accepts a value of either 8 (yesterday, today and +6 days) or 15 (today, -7 days, +7 days), so if a client adds 100 the widget responds with an error: 100 is not a valid number of days. Please use '8' or '15'.

value structure

The structure of a configuration file is very important, it needs to be readable at a glance and uncluttered. JSON makes this easy, allowing you to nest objects and lists easily and in a human readable format. With this configuration we needed to cover various widgets of various versions with various modules, so where to start?

First of all we have an object for each widget, followed by an object for each of the major version numbers (if available for that client). Within each major version number we specify a minor version (clients automatically use the latest bug fix version), whether the client has a custom css file, a custom javascript file, an offline version available and a modules object. The modules object contains all configuration for each module of the widget.

an example!

If you have any comments or suggestions we’re happy to hear them! Next time I’ll cover the heavy lifter in the widget workflow: load.js

blog comments powered by Disqus