A few days ago, I realized, “This Verbosio project is so big, so detailed, that a high-level overview would be really useful.” These high-level ideas haven’t changed in the six or seven years I’ve held them, but there’s been no complete overview of the ideas at once. I decided, therefore, it’s time to take a step up – not back – and try to paint a comprehensive picture of what I’m really trying to do here.

(UPDATE: For those of you who don’t know, Verbosio is an attempt to build a prototype XML editor driven by add-ons – languages and user interfaces coming from extensions to the core architecture.)

I’ve tried before to explain it – and it’s helped in job interviews (more on that later) – but even a five minute summary just doesn’t capture the whole vision I have. Lengthy specification documents and blog posts don’t do it either – ultimately they end up out-of date and forgotten. So I’m going to attempt a new approach. I’m going to create an audio slideshow “fly-by” of Verbosio, explaining the concepts behind the project.

(I credit the JSConf X presentations Brendan Eich and Douglas Crockford gave as the inspiration for this. Slides plus spoken words in an online video is pretty effective.)

On Wednesday night, I wrote out an outline, in preparation for writing a script and slides. When I counted it out, seventy-five different slide items came up (give or take a couple). That’s too many for a single presentation, so as I write the script, I’ll break it up into a few smaller segments. Overall, this could easily run 90 minutes as a whole.

How serious am I about this? I bought a Logitech headset specifically for this audio slideshow, and I’ll be using OpenOffice and some freeware audio editing software to put it all together. That said, for those of you who’ve done audio slideshows before, I’d welcome any advice – including freeware recommendations – on the technical and conversational aspects. I’m dusting off techniques from my Navy Journalism classes – which were way back in 1996 – and my book, in 2001-2002. I could use a refresher course, so please: chime in on the comments!

Storing references to objects

As I’ve said before, I’m building a markup templates system. The idea is to
reduce markup into reusable patterns, and to separate output from the user
interface. The idea is that for every significant node in the output (and thus,
in the user’s markup), there’s a matching user-interface node, and vice
versa.

Keeping track of these node pairings is the challenge. In a simple case, you
have a DOM tree like this:

  <markup:template>
<markup:output>
<xul:groupbox>
<xul:caption/>
<markup:children/>
</xul:groupbox>
</markup:output>
<markup:ui-section>
<xul:groupbox>
<xul:caption>
<xul:textbox markup:xpath="xul:groupbox/xul:caption/@label"
markup:source="@value"
markup:required="@value"
/>
</xul:caption>
<markup:children markup:xpath="xul:groupbox/markup:children"/>
</xul:groupbox>
</markup:ui-section>

The markup in italics indicates one node pairing – between the output’s
caption element (actually, its label attribute) and the user-interface’s
textbox. Another pairing exists between the underlined nodes. The
<markup:output/> and <markup:ui-section/>
elements define yet another pairing.

So, ultimately, I need a way of referencing one node from the other.
(Specifically, I’d needed references to the output nodes from the
user-interface elements.) The most obvious way is to store each desired output
node as a property of the corresponding user-interface node – through the
setUserData() and getUserData() methods DOM 3 Core
provides. However, I scaled the template system upwards to include repeating
fragments (think for (var i = 0; i < x; i++) {...} in XML).
Since users can rearrange those fragments – or even create new ones and remove
existing ones – pretty soon, when sending the updates back to the output
section, it gets… complicated. Now, you have user-interface nodes in a
different order than output nodes, some output nodes without user interface
nodes (because those were removed), and some user interface nodes without
output nodes (because they were inserted).

More details in the extended entry.

Continue reading Making a hash of things →

Has this ever happened to you?

• You have this great idea.
• You understand it deeply – how it should work, how it should be used, etc.
• You can write code to implement it.
• You can write tests for it.
• You can’t quite figure out how to put it in plain English, or in a diagram easy for your audience to understand.

Yeah, this happened to me. I’m trying to emulate XUL’s broadcast/observer model, but in limited parts of a document, and not necessarily in a XUL document. (The audience for this is fellow web and Mozilla developers.)

Basically, I’m adding in the concept of a “carrier” – as in carrier frequency, or relaying tower. (As an analogy, in a XUL document with inline frames and XUL subdocuments, each subdocument represents a carrier – XUL broadcasters in a subdocument can’t touch XUL observers in another subdocument. I’m attempting a similar boundary concept.) Broadcasters and observers live in the scope of a carrier node, but don’t cross the boundaries into other carrier nodes. Also, you can broadcast and observe not only attributes, but JavaScript values.

If you really understand the last two paragraphs completely in one reading, I’d be pretty amazed. So I’m trying to come up with an illustration of what I mean.

Here, the colored backgrounds indicate a carrier that the DOM node belongs to. (No background color means no carrier.) Some nodes within that carrier’s “grouping” have properties they broadcast… and other nodes in that carrier are observing on a particular name (“foo”, “bar” in this example), and picking up the properties. A carrier can observe and broadcast as a member of a parent carrier’s grouping, but not to any of the elements inside its own grouping.

Does this make sense, with the diagram attached? If so, great, and I’d like to know. If not, well, that’s why I’m posting this. I need some help, in making this easier to understand as a concept. That will help greatly both in using and testing the implementation of this model.

You can ask for the code implementing it and testing it, but be warned: it’s pretty hefty and intricate JavaScript. (Plus, I’ve already found a bug, and I’m still trying to figure out where it went wrong.)

(P.S. Yes, there really is a good reason for me to do this. Imagine a XUL grid where each row has a different number of columns. How would you allow the user to set the number of columns for each individual row? How do you make sure your XUL control for row 3 doesn’t affect rows 1, 2, and 4? This is just the most obvious example.)