Backwalking the Breadcrumbs

If you're the nosy type like me, you've probably been guilty (on more than a few occasions) of navigating a site by popping successive pieces off the tail end of the URL. In other words, if you've found yourself at http://www.somedomain.com/c/b/a/great.txt, you may have been curious about what else is at http://www.somedomain.com/c/b/a, so you hand-excise "great.txt" off the URL in the browser address line and hit Go. After that, you're curious about http://www.somedomain.com/c/b so you hand-remove the /a, etc. Repeat until carpal-tunnel syndrome.

A linkbar button with some Javascript behind it is a lot easier than clicking into the URL, highlighting text, deleting it, hitting Go or Enter, and so on, over and over again. Here's the Javascript that will do this (prefaced by "javascript:" so that it'll run in the address field of the browser):

javascript:ar=location.href.split('/');
if(ar.pop()=='')ar.pop();
u=ar.join('/');
location.href=u;

Remember that for this to work as a bookmarklet, it all has to be on one line. I've broken the code apart here for illustration purposes.

All we do is make array out of the individual location elements of the current URL by breaking it at forward slashes, then pop the tail element off, re-join() the array with '/' delimiters, and make the browser go to the newly formed URL.

Works like a charm.

I keep this script in a link button (called "Peelback") on Firefox's linkbar. It's handy as heck when you've landed on an interesting web page and you want to further navigate a given URL via the ancestor axis.

XSS: Digg This

According to a recent Digg post, BestBuy's website (allegedly) contains a cross-site-scripting (XSS) vulnerability.

Which is doubly ironic when you consider that until recently, Digg itself was reportedly an XSS risk.

Note: Every verb on this page should be considered to be prepended by "allegedly" unless otherwise indicated.

Unipage

Someone on Slashdot wrongly called Unipage a possible replacement for PDF. It has no relationship to PDF whatsoever. It's also not a file format.

So what is it, then? It's simply a way to serialize a web page and its contents, making the page 100% self-contained (with no reliance on outbound links). Images are stored inside the page in data:url format (see RFC 2397), which of course makes the whole scheme incompatible with IE. Then again, the Adobe SVG plugin for IE does support data:url, so it may be possible for some clever soul to write a script that uses embedded SVG islands to work around this IE limitation in semi-transparent manner. So to speak.

The Firefox SVG Code-Bloat Crisis

Fellow Novell-er and longtime Mozilla contributor Robert O'Callahan penned a blistering (yet obviously well-intentioned) philippic the other day on code-bloat in the Firefox SVG engine. For a minute there, I didn't think anyone else still cared about code size or memory usage. Happily, that turns out not to be the case. O'Callahan worries about code size at the bit level.

But code size is not the only issue. O'Callahan dives quite deeply into the architectural waters and comes up with refreshingly brash statements like "XPCOM is a disease ... people acquire it by being exposed to infected code." He bristles at the notion that a single SVG <rect> element requires 1.2 Kbytes of pointer storage and carries around empty transformLists. (One wonders what he would say about Java, wherein a mere JPanel has 330 methods.)

The real problem, of course, is the SVG spec, which defies any attempt at elegant implementation.

Bring on sXBL with a <canvas> binding.

Javascript Source-Code Viewer for Firefox

JSViews is a Firefox plugin that does a code-dump (into one or more new browser windows) of remote ".js" code referenced by any web page. I don't know yet what the limitations are, but it's definitely a worthwhile plugin. I recommend you install it right now, restart Firefox, go to http://www.cnn.com, right-click on the page, choose View External JS, and watch about a dozen Javascript source-view windows open (some containing ad-tracker code).

Novell Open-Sources FLAIM Database

Novell has decided to donate its high-performance FLAIM Database Engine (and the XML-savvy version, XFLAIM) to open source. FLAIM is not new and is not meant to compete with MySQL. It's a platform-neutral, massively scalable, very-high-performance transactional database, written in C++ as a persistence back-end for Novell eDirectory. (It is also used in GroupWise.) The XFLAIM version uses XPath for a query language.

The fact that there are Novell customers with well over 100 million objects in their FLAIM-backed eDirectory trees should tell you how scalable and robust the FLAIM technology is. (It should be robust, after nearly 20 years of development!)

If you want to get a feel for what XFLAIM is all about (given that I can't do it justice here), go to the documentation.

Is this Novell's first step toward open-sourcing eDirectory? Quite honestly, I don't know. (If I did know, I couldn't write about it here.)

AJAX Toolkit Framework (ATF) Project

This announcement describes the new proposed AJAX toolkit for Eclipse 3.2, which is actually "tooling to enable tooling" in the sense that it's a pluggable AJAX IDE framework meant to wrap any of Dojo, Zimbra (Apache Kabuki), or OpenRico. And possibly others, later on.

It's obvious that something like this is sorely needed and will be widely used (and abused). I give the ATF proposal ten thumbs up.

While I expect ATF to sail through Creation Review (and thus become an active Eclipse.org project) with nary a hiccup, I can't say the same thing about the newly proposed Kabuki Project for incubating Zimbra at Apache.

The Kabuki Proposal has not been 100% warmly received over at ASF. The debate has included criticism of Zimbra's code (for being too Java-like, poorly namespaced, bloated, not working correctly out-of-the-box) as well as criticism of Zimbra's lack of community presence, inability to find non-salaried committers, etc. One gets the impression that Zimbra expected that Apache.org would jump on any well-established AJAX framework donation. Evidently not.

What's ironic is that the IBM guys took the ATF Proposal to Apache first before putting it in front of the Eclipse.org WTD group. (I can't recall IBM ever taking an Eclipse technology to Apache for incubation. Can you?) Gory details here.

AJ4X

My new invented term for AJAX-using-E4X. Quick, somebody trademark it! (Not.)

Javascript, XML, and Element Names

So as E4X finds increasing use in the AJAX world, a potential stumbling block comesinto focus around hyphens and other non-word-characters in element names.

The issue is this. E4X has a dot-syntax for XML objects that allows expressions like root.x.y to obtain the y element under an x element under the root. But when an element name contains a hyphen, this syntax breaks. Consider:

var fragment =
<content>
<field>
<display-label>Please approve.</display-label>
</field>
</content>;

// Now try to access the display-label value
var value = fragment.field.display-label;  // ReferenceError!

The interpreter treats a hyphen as a minus-sign, of course, and since label hasn't been declared, it's undefined and unusable. If a variable named "label" does happen to exist in the current scope (e.g. you used var label in place of var value above), you won't get any error at all, since subtraction on two defined entities is always a legal production in Javascript.

The Workaround

Fortunately, E4X supplies an alternative syntax we can use.

// Instead of this:
var value = fragment.field.display-label;  // ReferenceError!

// Do this:
var value = fragment.field["display-label"];  // "Please approve."

There's one more syntax breakage to deal with, and that involves the descendant-retrieval syntax. E.g., root..y returns a list of all y descendants under root, regardless of what level in the tree each one is at. This syntax obviously breaks down if y is something like data-item.

The workaround is to use the E4X descendants() method.

// Instead of this:
var allLabels = fragment..display-label;  // error!

// Do this:
var allLabels = fragment.descendants("display-label");  // list of nodes

Similar breakages and workarounds exist for E4X attribute syntax, the details of which are left as an exercise for the reader.