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.
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'.
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?
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: