When the team and I got together last year to discuss the things we wanted to do in Xibo v4, one of the questions we asked ourselves was “why are there not more modules, widgets and extensions for Xibo?”. Not an easy question to answer until you put yourself in the shoes of someone without knowledge of Xibo’s inner workings; then you realise… its hard!
A brief history
We thought about extensibility as far back as Xibo v1, where we had a modules folder which contained classes for database, user authentication and widgets. Back then the HTML which made up the application was inline with PHP and the player rendered all modules itself. This made for a painful developer experience, but then it was 13 years ago; a long time before the software industry was thinking deeply about these things.
Aside from a few minor improvements this remained the same until Xibo v1.8 which was the first version of Xibo to use a framework; Slim PHP v2. For the core product this meant we had Twig to separate PHP and HTML, the opportunity to allow custom middleware and a full REST API, now known as “Headless CMS”.
These changes were hugely important in our evolution because for the first time they allowed someone moderately familiar with PHP to add custom functionality / modules or integrate via the API.
Xibo v2 and v3 went on to further improve the architecture of the core product; upgrading to Slim PHP 4, building our JavaScript with webpack, expanding out the API to name just a few things.
While these improvements were happening to the core product module system for adding new widgets had some minor improvements, but you still needed a good understanding of the way the core software worked; including installation, add/edit forms, handling caching, etc.
Back to last year
After much discussion two points emerged as things we felt needed to be improved.
- Giving a module developer the power to hand craft HTML/CSS and JavaScript that gets loaded into the core product is fraught with risks on both sides.
- Expecting a module developer to understand how Xibo loads and parses forms, how caching works, how modules are installed, etc is unreasonable.
On top of this we felt that there was a lot of repetition in the widgets we provided in the core product and that having HTML/CSS/JavaScript presented to the user did not make for good user or developer experience (who wants to put HTML in a web page text box?).
A new beginning
Xibo v4 has a new widget system intended to provide an easy to understand developer experience comprising of XML definitions and well structured PHP interfaces.
For example, previously to collect information from a user you had to craft your own HTML, sanitise and parse those fields in edit, and set them on the module; now you add a <property> to your XML definition.
Previously to give the user different visualisations you had to add those as options into your form HTML and conditionally render those out in getResource; now you add a module template.
Previously to render your HTML out to the player you had to manually craft the structure, add your data, add some JavaScript to load it; now you have a set of methods you can define in your XML which are automatically supplied with data and properties.
In a nutshell: a widget is made from a Module and optionally a Module Template, where the Module controls configuration and the Module Template controls appearance; XML files are used to create modules and modules templates; and if data is needed a clear DataProviderInterface is used in a custom PHP file.
Elements
Xibo v4 is the first version of Xibo to give developers the tools needed to make reusable content blocks available to their users; called Elements. We call the old way of working “static templates”.
Elements are a special kind of Module Template which define how a single item of data should be visually represented. They can be designed from scratch or can extend one of the core global elements. Stencils are another special kind of Module Template which define elements that are added and positioned as a group.
As a developer you worry about the properties and appearance of the element, and the system worries about putting it in the right place, grouping it with others, feeding it with data, etc.
Data
Some widgets require data, some widgets don’t. We make this easy for the user to see by separating them in the toolbar. If your module XML definition has a dataType, then your widget will expect that data type to be defined and data of that type to be returned somehow.
As a developer this is when you pick up your PHP IDE and look at implementing either a WidgetProviderInterface or handling the WidgetDataRequestEvent (which you can do form a Connector or Middleware).
These are well defined interfaces with good documentation; both get a DataProviderInterface which can be used to fetch and return data for your module.
Module Templates
This new system also allows for something exciting! What if you just want a slightly different visualisation of some Currencies data, but you’re fine with using the currencies data supplied by Xibo’s preferred provider?
In that case you make a new Module Template which has a data type of currencies. This template will appear in the toolbar alongside the other core templates, have the properties required by the module, and get fed with the same data. All you have to implement is the appearance.
Wrapping up
These tools have sped up the Xibo team and we have big plans to use them ourselves to add some great new widgets and visualisations to the Xibo. That’s exciting, but more exciting is seeing what the developer community can do with them, so be sure to have a look at the new docs.
Looking into the future, these tools also pave the way for more ambitious projects, but more on that in another topic.