Seattle's wish for the New Year
Sorry. Being born & raised there, I just couldn't resist.
Over the years, one of my more fundamental tasks has been to make sure information goes from one page to another. In the land of HTML, I did this with a fairly detailed tutorial on JavaScriptKit.com. The article is over five years old, but still relevant for people beginning in the business.
Since then, I've learned a few things. Chrome windows can discover each other through the window watcher. There are observers (which I do not have a firm grasp on). Chrome windows have full control over content, which lets GreaseMonkey do nice things.
Content windows still live in a sandbox, though. For very good reason! Still, I find myself wondering how I can get a message from a JavaScript function in the content window into a JavaScript function in its container chrome window.
The problem is simple: let's say you have a string A in your content window. Function B in content gets called to change A. The chrome window has a function C which is designed to run when A changes. How can B call on C? Also, when the content window unloads and a new window / document pair loads (the user clicked on a link), how can A be made available to the new window?
Put another way: A content page does something (executes a JS function, or changes a value) without loading a new page. How does the chrome window find out about it and react to it?
I've come up dry on every idea I have. Right now, I only have two decent ideas left. One is to use a load event listener (which is the only one to bubble from content to chrome) to set up a secondary event listener or JS watch on related window objects. The other (thanks to timeless) is to implement a component that registers itself as a global object, such as window.sidebar. (nsSidebar.js was the example given to me.) Unfortunately, I also need a good interface, and would prefer to implement one that Mozilla already has (as opposed to creating a new one).
Help wanted! I need this both for XUL Widgets and for corporate use.
UPDATE: bz to the rescue again! Read comments for details.
ManyOne Networks, Inc., and the Digital Universe article I pointed out a few days ago has hit /. (This latest incarnation is through zdnetasia.)
I believe that's the second time something I've worked on has ended up there (Mozilla itself notwithstanding, where at best I'm on the fringes of development). Last time, I didn't even notice until one of this blog's readers pointed it out to me fourteen months ago. That's what started me actually reading Slashdot, ironically. Considering I'm not a developer in the mainstream, twice in two years isn't too shabby.
Oh, and happy birthday to me. I'm 28 today.
Following up on a previous blog entry about extending current toolkit widgets, I have just landed a good amount of new code to XUL Widgets.
Many thanks to prefiks (give me your real name & e-mail, so I can thank you properly!) for the idea of using regular expressions on textboxes. That's one of the improvements obvious enough that I had to include it.
Dialogs (with xulwidgets="true") now check for invalid="true" attributes, as does serverpost. However, in case an invalid XUL element is hiding in an invisible xul:deck panel, I created a xul:deck extension that vetoes any hidden invalid elements.
I've deprecated and removed menudeck, in favor of a more flexible widget called controldeck. This one lets you use any XUL element that implements selectedIndex as a selector for the deck. You have to make the selector a child element of a <xul:selector/> element, and that in turn becomes a child node of <xul:controldeck/>.
Several new testcases have been added, including a main index page for all testcases within the package. chrome://xulwidgets/content/tests/tests.html
Still to come: the testcases for DOM utilities, preconditions, and user error boxes. Also, the XUL Widgets manual (which I would have gotten done today if I didn't have so many failures of the testcases initially... but the testcases pass now). The latter I hope to have up tomorrow.
If you try to download the latest XUL Widgets version, and it comes back as 0.0.0, reject it! The latest version number is 0.1.1.
Never mind the fact it's not really a tag... but this page is funny.
The current set of XUL widgets in the Mozilla toolkit is quite nice. For the most part they are stable, simple, and work well. That isn't to say I'm not interesting in making them more useful.
I've filed a number of enhancements to current widgets. Once in a while, I even get some fixed. More often, though, ideas I consider good just aren't adopted by mozilla.org code. This isn't to say the mozilla.org code base is bad. More accurately, the case is that I haven't made a strong enough effort to see these enhancements through, especially in seeking reviews and confirming that mozilla.org actually wants them in their code base.
With that said, one of XUL Widget's goals is to lower the barrier for creating new functionality for current widgets. Hopefully, these widgets will be useful enough for other developers to bring some of them back to the mozilla.org code base. Whether that will actually happen or not, I don't know. There's a pretty solid chance my place of employment, ManyOne Networks, Inc., will be using some of XUL Widgets' functionality, so it will be supported. (One idea I haven't yet explored is a tabbrowser with multiple rows of tabs. That ought to be fun to implement. It's a request from a fellow developer at ManyOne.)
Probably in the next couple of days, I'll start showcasing these widget improvements through XUL Widgets. They'll build on current functionality, through a special attribute, xulwidgets='true'. That way, the original widgets will still be available simply by omitting the attribute (or the XUL Widgets bindings stylesheet). I'll also move certain common constructs into DTD entities, so they may be reused. My goal is to enhance current features, not to replace them.
XForms has standards for validation. Web Forms 2.0 has proposed standards for validation. XUL? Not so much.
One of the goals of XUL Widgets, as yet unstated (because I haven't written the manual) is to come up with some kind of convention for validating input from XUL. Now, in 99% of the cases you may not need much; how hard is it to validate a checkbox? But at least for <xul:textbox/>, I know of no standardized procedure for validating what the contents of it are. Likewise, I know of no standard way to disable the OK button of a <xul:dialog/> when there is something wrong with the inputs, other than by force from JavaScript.
Again, it may not be strictly necessary. But it is a nice-to-have option for XUL. So I'd like to ask readers: how would you standardize XUL input validation through the XBL bindings? I'll consider your answers, and probably try to incorporate them into the XUL Widgets project. I have my own ideas, of course, but they're not necessarily correct, and probably are incomplete. Also bear in mind validation may be extensible to widgets that don't exist in the current toolkit yet.
Every now and then, I hit a regression bug which exists in one version of a file (or project), and doesn't exist in another, for reasons that are not easily deduced. It's maddening when diffs of a particular file offer no clues as to the cause of a bug.
I have a tried-and-true method of isolating such bugs:
Logically speaking, sooner or later you will eliminate all the incorrect causes of failure and arrive at the correct cause. Or, you will identify a much smaller set of possible regressions to look through.
Now, could someone find or write a Perl script to generate the "state C" sources for me (and possibly invoke another Perl script to run the test)? In the first bug I had this problem in, the set of changes was assumed to be all directories one level below the mozilla source directory. In the second bug, the set of changes was XBL methods and properties in a single XML file. It wouldn't be easy. But it would be doable. (I've written a Perl script for the first testcase, but it was somewhat hackish.)
Sir Arthur Conan Doyle, and I, would thank you.
As a follow-up to my original post suggesting a XUL widgets project, I finally launched it. Right now, it collects most of the widgets I've written in a generic format. In the next twenty-four hours, I hope to have a XUL Widgets Manual written for project development and for users.
So if you have a XUL element you've created and think others might be able to use, come on in! I would also welcome compentent reviewers to point out obvious mistakes.