While the lawyers are dotting the i’s and crossing the t’s as far as getting the code in your hands – we’re aiming for a permissive license similar to the licenses for PhoneGap and Dojo – I wanted to tell you a little bit about it.
Mulberry lets you focus on the things that are unique to your application. It provides an underlying framework that includes a “router” for managing application state; built-in components and templates for displaying standard content types like text, audios, videos, feeds, and images; a simple API for defining custom functionality and integrating it with the system; and an HTML/CSS framework that uses SASS and HAML templates to make it easy to style your apps.
It’s the data asset that provides the most power to developers – you can create an arbitrary object, associate it with a node, and then any components that are in the template that’s being used to display the node will get access to that data.
A Twitter component offers a simple example. A node might have a data asset like this associated with it:
We could define a custom template for this page (
mulberry create_template Twitter), and tell that template to include a Twitter component:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Next, we’d define our Twitter component (
mulberry create_component Twitter), which would create the skeleton of a component file:
1 2 3 4 5 6 7 8 9 10 11 12 13
One of the things the skeleton contains is a reference to the template for the component. The
create_component command creates this file, which defines the DOM structure for the component. For the sake of this component, that template will just need to contain one line:
As I mentioned earlier, Mulberry components automatically get access to all of the assets that are attached to the node they’re displaying. This information is available as an object at
this.node. Mulberry components also have two default methods that you can implement: the
prep method and the
prep method is an opportunity to prepare your data before it’s rendered using the template; we won’t use it for the Twitter component, because the Twitter component will go out and fetch its data after the template is rendered. This is where the
init method comes in – this is where you can tell your component what to do. Here’s what our Twitter component ends up looking like:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42
Note that when we define the
data variable in the init method, we look at
this.node.data, which is an array of all of the data objects associated with the node. We filter this array to find the first data object that is the right type – this means we can have lots of different data objects associated with a given node.
Note also that there’s a property
this.$domNode that we’re calling jQuery methods on, and that we’re using jQuery’s
$.ajax – Mulberry apps come with jQuery enabled by default, and if it’s enabled, helpers like
this.$domNode become available to you. This means that very little knowledge of Dojo is required to start adding your own functionality to an app – if you need it, though, the full power of the Dojo Toolkit is available to you too.
Here’s what our component ends up looking like, with a little bit of custom CSS applied to our app:
This is a pretty basic demo – Twitter is, indeed, the new
hello world – but I hope it gives you a little bit of an idea about what you might be able to build with Mulberry. We’ve been using it in production to create content-rich mobile apps for our users for months now (connected to a web-based CMS instead of the filesystem, of course), and we’ve designed it specifically to be flexible enough to meet arbitrary client requests without the need to re-architect the underlying application.