Last time, I waxed verbose eloquent about the glories and the power of RDF. Today, I’m going to talk about how to use RDF to generate UI, in a flexible, extensible, and performant way.

Actually, I’m lying. I’m going to talk about two DIFFERENT ways to do this. One of them is flexible and simple. The other is extensible and performant. You take your pick.

But first, a quick review.

• XUL = HTML for the browser. Defines layout.
• CSS = Stylesheets, of two kinds:
• one makes things look GOOD (themeable),
• the other makes things WORK (moz-binding and functional layout).
• XBL = The wondrous binding language, essentially lets you create your own XUL elements of arbitrary complexity. This is where the magic happens.

XBL brings the power and rigor of Agile Development to the declarative, XML world. When is the right time to refactor? When you write the same code for the second time. When is the right time to make a XBL binding? When you’re going to have the same chunk of XUL twice.

Alright, that should be enough to scare off anyone who’s not going to follow the next bit. Let’s dive into the nitty gritty.

As I mentioned last time, one of the beautiful things about RDF is that it allows you to express additional ARCs to capture service-specific data or metadata, on top of the base data. Think of sub-classing a generic PERSON to a youtube PERSON, which allows us to keep track of the number of videos they have uploaded, a list of their friends, and maybe the last time they logged on.

So how can we do this in Flock?

1. Declare an inherited coop object. (In this case, it would be YoutubePerson inherits from Person).
2. Create an inherited XBL binding for the relevant UI (personcards in the sidebar, FOAFcard for browsing friends of a friend, etc.)
3. Add an overlay to the sidebar XUL, that includes a service-specific CSS file to connect the inherited binding, with the relevant elements, like so:

personbar.xul:

<overlay id="youtubePersonOverlay"
  xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
  xmlns="...there.is.only.xul">
  ...
</overlay>

Why is this cool? Or, why is this the right way to do it?

1. It works with either RDF templates, OR javascript document.createElement()
2. It means a single generic method of displaying ALL persons can output service-specific UI – Including service-specific ACTIONS in that UI.
3. It encapsulates the UI code per service, WITHOUT mashing that UI code into an xpcom service somewhere.
4. Services don’t HAVE to use specialized bindings – if they don’t define one, the generic binding will be used, which ought to just work.

No approach is perfect, however. Here are the possible drawbacks:

1. The generic binding has to assume a very low level of functionality, since it can only rely on the actions that every service will have. So many services will end up duplicating binding code for a rich-but-common set of functions. (Perhaps this could be mitigated by inheriting from a more-sophisticated, common but not default binding?)
2. Since the attribtues on the element are only those common to all PERSONs, the binding may end up needing to use coop internally to fetch the additional metadata that it needs. (This is straightforward, but it does add complexity.) Again, the template itself could be overridden with an overlay, but that spoils the elegance of this approach.
3. Hopefully, an inherited binding will still be able to take advantage of drag-n-drop handling code within the base binding, but this is definitely a point to watch out for in test-planning. Perhaps the most critical goal of this quasi-polymorphism is to ensure that the DnD behaviour is consistent across services.

This is a little more technical than I was going for, as I’m trying to keep this blog accessible and approachable for ordinary coders. But, if you understand XUL, and you understand XBL, you ought to be able to grab this one and run with it.