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.)
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.
(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.)