Truer Words - A Journal

Client-Side Storage in Web 2.0 Applications

seth@macrobyte.net — Wed, 26 Apr 2006 21:21:19 GMT

This looks to be a fantastic breakthrough. I think Brian A. will get a kick out of the storage system he describes... it sounds awfully familiar. ;-)

I'm proud to announce the immediate availability of dojo.storage and a new web-based editor named Moxie.

Imagine if web applications could store megabytes of data on the client-side, in the browser, both persistently and securely. No server needed.

I'm going to have to implement this for Conversant. Soon.

(Thanks for the link, Daniel.)

Character Sets "Oops"

seth@macrobyte.net — Fri, 21 Apr 2006 14:00:04 GMT

After my last post about switching to UTF-8 for all of our content in Conversant, people wrote to say that my XML feed had problems since we made the change.

Heh. That's ironic.

Anyway, some wrote to me privately, as if a bug is something I'd be embarrassed about. "Oh no! A bug in the software! Say it isn't so!" All this time I thought my software was bug-free, like everybody else's. (What matters is how we deal with them. They're inevitable.)

Well, now the bug should be fixed. All "above ascii" text in the XML output was being automatically converted to numerical entities (like &234;), but that's no longer necessary when the output is UTF-8.

In other words, my “curly quotes” — and long dashes — should all look fine now. Feel free to give me a shout if something looks wrong, though.

Conversant Patterns Contest is Live!

seth@macrobyte.net — Mon, 10 Apr 2006 15:27:08 GMT

At long last, the Conversant patterns contest is live!

Prizes include a 60 GB video iPod with a $50 iTunes gift certificate, a 30 GB iPod, and one year of Macrobyte's "Domain Hosting" package!

This contest was originally the idea of Terry Frazier. Terry, Clark Venable, and Macrobyte are the sponsors.

We've been planning this for months. :-)

Setting Attributes on Elements in Frontier's Compiled XML

seth@macrobyte.net — Fri, 03 Jun 2005 19:33:12 GMT

Ugh, the subject is a mouthful, but the topic is very simple if you know Frontier at all.

To any Frontier developers who read my site but may not be paying attention to the kernel developer's mailing list: could you take a look at this message and tell me if you see any problems with my little suggestion?

Please, no ranting about... well, anything. It's a given that this is a feature we should have had yesterday.

The Unpublished Hack: UDDI in Mozilla

seth@macrobyte.net — Wed, 06 Apr 2005 16:31:57 GMT

This is one of the five 'hacks' that I wrote for the book, Firefox Hacks. It wasn't included in the book because it's too geeky even for most advanced web developers, and Firefox's support for UDDI is incomplete. Still, if you need to work with UDDI, then Firefox could make an excellent test-bed because it's so easy to rapidly develop a user interface, and the missing pieces are easy to download and install.

This guide is just intended to help you start working with UDDI in Firefox. It's not comprehensive, by any means. If you know nothing about UDDI, the best you'll get here is a link for learning more somewhere else.

Note that everything mentioned in this 'hack' applies equally to Firefox and the Mozilla Application Suite (a.k.a. Seamonkey).

Read Hacking on UDDI in Mozilla or Firefox.

MacMerc.com Reviews Firefox Hacks

seth@macrobyte.net — Thu, 31 Mar 2005 14:23:29 GMT

MacMerc.com: Review >> Firefox Hacks by O'Reilly

For example, in just the first hundred pages you'll learn how to migrate profiles between platforms and versions, tear web pages apart with the DOM Inspector, detail security limitations and deploy Firefox on a network. In the next couple hundred pages you'll get into advanced topics like working with XML-RPC, SOAP and other XML technologies, developing applications in Mozilla's XUL and hacking into the core of Firefox itself modifying menus and behavior. [emphasis added]

Cool! Of all the topics they could have mentioned in this book, they picked some of mine.

On that note, I'd like to remind everybody that buying Firefox Hacks through one of my links (or anything else through one of my links to Amazon, as seen on most pages on the web site) will help me raise $6,000 towards the PMC, for cancer research and treatment. So far, I haven't sold anything.

My Contributions to O'Reilly's Firefox Hacks

seth@macrobyte.net — Tue, 22 Mar 2005 17:12:48 GMT

During the final quarter of 2004, I spent about eighty hours writing five hacks for O'Reilly's new book, Firefox Hacks. (Nigel McFarlane wrote the bulk of it.)

This story, which is both a journal of my work on the hacks and a review of what I wrote, is a little too long for the home page. You can read the whole thing at Articles -> Mozilla -> Firefox Hacks.

Phil Responds (sorta) re: HTML Comments and Linking Technologies

seth@macrobyte.net — Fri, 18 Mar 2005 15:18:01 GMT

I thought Phil was ignoring me. I wrote to him on the 7th, after posting about HTML comments and embedded RDF, to ask what he thought of my suggesting regarding invisible links pointing to autodiscovery documents.

He wasn't ignoring me, he just couldn't put his brain into gear for this one. (I'm not picking on him, that's what he said!).

He asked people to comment on my idea. Unfortunately, most of the comments have nothing to do with the problem at hand, and many of the commentors apparently don't understand the issue. (They talk about everything from the usefulness of trackback to the second coming of <blink>.

For the record, and perhaps to help bring the discussion back to the real point, here's the bulk of the email I sent to him:

[SNIP]

<http://www.truerwords.net/4599>

At the end of that post, I had an idea/suggestion for linking to autodiscovery (or other types of metadata) documents that would seem to work with pages having multiple items (which has always been one of the two big problems with using a <link> elements in the head).

I realize it's not perfect, as the <a> tag doesn't actually have any identifying information that would allow the machine to associate it with a post on a page containing more than one (such as a weblog's home page). So, what about something like this?

<a rel="trackback:http://philringnalda.com/blog/2002/08/trackback_and_validation_summary.php" href="http://philringnalda.com/mt/mt-tb.cgi/55?_type=discover"></a>

The single value in the rel attribute manages to both identify it as a trackback-related url, and identify the server object it supports. It appears to be a legal value, as the spec only says that the value of rel must be a string with the space separating multiple values (but we're only providing one long value).

It's logical, too, making it very easy to automate.

Any thoughts on this? I'm interested not just for the sake of trackback, but because other technologies will have a chance to "bloom" if this hurdle can be overcome.

He didn't publish that email, which is good, but without it the people being asked to comment would really have very little on which to comment.

Hopefully he'll post a follow-up with a link to this entry, so some more relevant discussion can take place.

Cool Interview with Sheila and Brent

seth@macrobyte.net — Wed, 09 Mar 2005 17:41:18 GMT

"On the support side, the biggest challenge for me has been learning about all the weblog systems that work with MarsEdit."

That's Sheila Simmons, Brent's wife and half of Ranchero Software, in DrunkenBlog: Inside Ranchero with Brent and Sheila Simmons. Very cool interview with both both Brent and Sheila.

Sheila, in that quote, was articulating the client side of the problem I first described here, and which Simon Fell referred to as slightly uniform interfaces. (Eventually we'll get to the point that everybody has to special-case something into every feature for everybody else's bugs, or we just code to the spec and "damn the torpedoes.")

Most of the interview has nothing to do with this subject, but I had to quote something...

Creative Commons, Trackback, HTML Comments, and Embedded RDF

seth@macrobyte.net — Mon, 07 Mar 2005 23:57:15 GMT

How many years do I have to work with HTML before I stop discovering important technical points of which I should have been aware all along?

Today's rather embarrassing example regards the format of HTML comments. This completely took me by surprise.

HTML comments have the following syntax:
    
    
White space is not permitted between the markup declaration open delimiter("<!") and the comment open delimiter ("--"), but is permitted between the comment close delimiter ("--") and the markup declaration close delimiter (">"). A common error is to include a string of hyphens ("---") within a comment. Authors should avoid putting two or more adjacent hyphens inside comments.

Information that appears between comments has no special meaning (e.g., character references are not interpreted as such).

Note that comments are markup.

In other words, comments don't end with "-->". They end with "--" followed eventually by an occurence of '>'.

This explains problems I've seen for years but never bothered to dig into deeply enough. I thought that the HTML comment delimiters were simply a "balanced pair", similar to the < and > that mark the start and end of a tag. A "".

Practical implications? There are a few. The most obvious (in my world) is that one can't reliably "comment out" the results of some Conversant macros. For example, if the macro returns a user-defined string from a database (such as a message subject), that string might include a "--". If it does, then the very next '>' will close the comment.

Trackback "autodiscovery" data is RDF embedded in HTML comments. It looks something like this:

<!--
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
    xmlns:dc="http://purl.org/dc/elements/1.1/"
    xmlns:trackback="http://madskills.com/public/xml/rss/module/trackback/">
<rdf:Description
    rdf:about="http://www.example.com/example/page.html"
    dc:identifier="http://www.example.com/example/page.html"
    dc:title="HTML Comments -- They Don't Work How You Thunk"
    trackback:ping="http://www.example.com/4594/trackback" />
</rdf:RDF>
-->

See the problem? The dc:title attribute of the Description element contains a "--", and so the comment is closed by the very next '>'. That leaves the </rdf:RDF> and the --> outside of the comment, and in fact Firefox displays the --> on the web page!

Creative Commons Licenses work in a similar way: they embed licensing information in the HTML via comments. They're not bitten by this comment syntax problem, though, because they have more control over the attribute values of the tags, and can intentionally avoid the double-hyphen problem.

See Kendall Grant Clark's Creative Comments: On the Uses and Abuses of Markup for a discussion of the semantic problems with this approach, and Phil Ringnalda's throrough review of the trackback problem (years old).

I didn't see any mention, in my brief research, of using a technorati-style link to solve the problem. Instead of embedding the RDF in the html, we could link to an RDF autodiscovery file with an invisible-to-people link like <a href="http://www.example.com/mt-trackback.cgi?type=autodiscover&id=4594" rel="autodiscovery"></a>. Any reason that wouldn't work?

Comments appreciated.

Free Books from O'Reilly! (Sort of.)

seth@macrobyte.net — Mon, 21 Feb 2005 23:33:03 GMT

Last year I contributed five articles to a book that O'Reilly is publishing in March. For the insane amount of time I put into my articles, the pay was very bad. That's not a complaint: I knew what I was agreeing to from the beginning. I took it on because I'd like to do more writing, and I'd like to start developing a reputation in the area covered by this book. (How odd, then, that I'm not yet ready to say what that is!)

There was a bit of confusion when I first signed the author agreement, so I wasn't terribly surprised when the check didn't show up at the appointed time. I contacted the editor, who apologized profusely... and then more than made up for the delay by allowing me to pick out a few books.

I've had three books on my Amazon wishlist for months, so I just sent him that list: Perl & XML, Programming Web Services with Perl, and the fourth edition of the venerable JavaScript: The Definitive Guide. All three arrived today. Ehhhxxxcellent!

Over the years, my most-ever-used technical book has proven to be the second edition of JavaScript: The Definitive Guide. O'Reilly sent it (and seven or eight other titles) for helping to edit Matt Neuburg's Frontier: The Definitive Guide.

It seems a little odd that the JavaScript book is my most used, considering how rarely I talk about js here or anywhere else. I mention UserTalk-related stuff all the time, but never refer to any UserTalk documentation (I think the whole language is stuffed into my head already). JS is probably my second most used "language". Perl is next on the list, though that's just in the last couple years. (I'm not counting HTML or CSS as languages, and C comes in bursts).

Back to the original point: do they count as free books, when they're thrown in as a bonus after eighty hours of labor? ;-)

The Cheesy RSS Documentary. Dream. Thingie.

seth@macrobyte.net — Mon, 31 Jan 2005 19:23:44 GMT

Phil's dream about a documentary on the history of RSS is hilarious. He left out RSS 2.0, but it's still very funny (as long as you know a little about the subject).

Format Nazi!? Good Grief, No Wonder the Empires are Taking Over

seth@macrobyte.net — Wed, 26 Jan 2005 12:52:23 GMT

Dave writes that he thinks RSS formats should be merging instead of diversifying right now, because the aggregator developers are under attack by the likes of Microsoft and Yahoo. (They see a market and have started to consume it.) This is probably in reference to the fact that an RFC for RSS 1.1 was recently published, and is not backwards-compatible with RSS 1.0 or any of the other RSS formats.

So what happens? He allows comments on his post, and it explodes into name calling and the blame game... all without Dave saying another word. They even referred to him as a "format nazi." I can't even figure out what that means! (I assume you're keeping score, Mark.)

I happen to agree with Dave (believe it or not), that the aggregator developers are in serious trouble because Yahoo and Microsoft are building aggregators into their web site services. At the same time there's the problem of RSS-related features showing up in browsers like Firefox and Safari (under Tiger).

If you read that thread, does it really leave any doubt as to why the big guys think they can take over the show, why they can consume this emerging market? The programmers just want to fight about the technology. Dave's point is that the technology is there now, it's already implemented. RSS (or whatever syndication format you prefer) is already available everywhere. While we're contemplating our navels (thinking about how to re-write the technology to do the same stuff in a different way) and fighting with each other, the other guys are quietly packing all of the users in a big bus and driving away.

There's a lot more in this thread on Brent's site. I posted some more of my own thoughts there (quoted below), and am surprised to find that Dave twice told people to go back and read what I wrote.

I think what Phil (and Dave, actually) are saying is that we're debating a technical issue in a bubble while business decisions are being made (and markets are being consumed) around us.

We need to [find and/or go with] the solution that the biggest producers of RSS feeds will be willing to use but which doesn't leave desktop aggregators out in the cold.

WEBoggle: A Great Online Boggle

seth@macrobyte.net — Mon, 29 Nov 2004 22:06:45 GMT

While doing research for that same paper (mentioned yesterday), I also found WEBoggle, an online version of Boggle. My favorite online game is Joggle, but... man, WEBoggle is very cool.

OK, you can't do challenges, or play solo, and it's a little exhausting because games start every three-and-a-half minutes, but the technology is so well done! The page never reloads! They use XMLHttpRequest for all communication with the server. Every time you enter a word, it immediately asks the server if the word is legal or not, and scores it. The board is reloaded, the game is scored. All without reloading the page!

Very cool. Too bad there wasn't room for it in the paper (which, btw, I finished on time).

Scott Andrew: "Where I've Been"

seth@macrobyte.net — Sun, 28 Nov 2004 16:53:13 GMT

While doing some research for a paper (which, in fact, is due this afternoon!), I happened upon the home page of Scott Andrew. Scott is the author of the XML-RPC JavaScript Message Builder, one of only a few browser-based XML-RPC javascript libraries.

Anyway, his music is the only reason I'm mentioning this right now. He's really good! Good enough that I've finally used up the last few dollars of an iTunes gift certificate (thanks Clark!) to buy his album, Where I've Been.

He actually offers all of his music for free on his site. So why purchase it? Well, for starters, it was only $6. Also, go read Different Currencies, where he describes his support for P2P and filesharing. After reading that, of course I paid for it!

Adam Bosworth on Keeping Technology Simple and Sloppy

seth@macrobyte.net — Mon, 22 Nov 2004 15:56:34 GMT

Adam Bosworth gave a speech about simplified technologies. His basic message is that simple, sloppy, flexible technology is far more likely to succeed than that which is structured, tight, orderly, and rigid.

I agree with much of what he has to say, but certainly not everything.

Read my essay response or post a comment.

Attempting to Explain Mozilla's SOAP (and Related, XML-Based) Services

seth@macrobyte.net — Sat, 13 Nov 2004 18:32:26 GMT

I'm discovering -- the hard way -- that trying to tell someone how to use Mozilla's SOAP client is rather difficult. The client can only communicate with the same host that delivered the html and javascript files. Therefore, in order to test SOAP calls in javascript in html, you also need to provide SOAP services on the web server. (The soap client needs to talk to the SOAP server, but it can only talk to the same server that provided the web pages.)

Thankfully, there appear to be some exceptions to this rule that don't require setting special preferences or cryptographically signing the scripts. It looks like a SOAP server can provide a special xml file which says it's ok to access the endpoints from anywhere. This doesn't remove all security restrictions, but it does allow some cross-domain scripting. xmethods.net, for example, appears to allow full access to all of their endpoints from web scripts, and they have plenty of toys to play with in demo scripts.

Note that I didn't say this makes it easy to explain, but it does allow for some examples which you can load up in the browser very quickly without setting up your own SOAP server!

Multi-Rule XUL Templates: Not Documented

seth@macrobyte.net — Tue, 02 Nov 2004 10:36:29 GMT

One important point I failed to include in last night's post about XUL templates: the problem I finally figured out is not documented anywhere, as far as I can see. XUL template documentation is generally found online in a few different places: mozilla.org, XUL Planet, and online copies of the book, "Creating Application with Mozilla." Offline, my preferred resource is Rapid Application Development with Mozilla.

None of them mention that secondary template rules must use the same variable names as the first rule (though all of the examples work that way, nothing indicated that was a requirement). I have discovered one other place this is mentioned, though: in a single sentence in a reply to a comment at the bottom of one page on XUL Planet.

In fact, you are required to use the same container variable (the one defined on the content tag) and the same member variable (defined in the uri in the action) in all rules, although they don't need to point to the same kind of data - Neil

XUL Templates with Multiple Rules

seth@macrobyte.net — Mon, 01 Nov 2004 19:44:49 GMT

XUL Templates with Multiple Rules

I spent two days last week banging my head against an XUL template with multiple rules. My goal was a tree view which showed folders, nested folders (to any depth), and files within those folders.

Summary:

Looking for a quick answer? Ok: all the rules in a multi-rule template must use the same variables, no matter what they're matching. You can't add new variables after the first rule.

As I explained in a follow-up to this article, the real problem is that this fact is (apparently) undocumented.

Update:

Neil Deakin posted a reply in the discussion area, with a slight correction to my 'discovery'.

There was no problem grounding the 'folders' from the RDF datasource. That was functioning correctly before I even started.

In the RDF, an element representing a folder could have two types of child node (two different types of assertion): "RKM:folders" (which would point to a Seq listing that folder's sub-folders) and "RKM:files" (which would point to a Seq listing the files in that folder).

The tree would show a "folder" as a container if it had a "RKM:folders" assertion (outward pointing arc), or if it had a "RKM:files" assertion, or both. (To show something as a container means it would include the flippy triangle to expand the item. Folders without subfolders or files would not have the flippy triangle because they're empty.)

The first rule in my template was already there and functioning properly, to display the folders and subfolders. Here's how the whole tree started out (this is simplified a little from what I was actually using, but it's close enough):

<tree id="sample.sidebar.tree_groups"
   datasources="sampledata.rdf" ref="urn:sample:root"
   containment="http:\//www.mozilla.org/sample-rdf#groups"
   rows="6" flex="1" seltype="single"
   hidecolumnpicker="true" enableColumnDrag="false">
   
<treecols>
      
<treecol flex="1" id="group_name" label="groups" primary="true"/>
      
<treecol id="group_id" label="ID" collapsed="true"/>
      
<treecol id="datatype" labe="Type" collapsed="true"/>
   </treecols>
   <template>
      <rule>
         <conditions>
            <content uri="?uri" />
            
<triple subject="?uri"
                    predicate="http:\//www.mozilla.org/sample-rdf#groups"
                    object="?groups"/>
            <member container="?groups" child="?group"/>
            
<triple subject="?group"
                    predicate="http:\//www.mozilla.org/sample-rdf#label"
                    object="?text"/>
            
<triple subject="?group"
                    predicate="group:\//www.mozilla.org/sample-rdf#id"
                    object="?groupid"/>
         </conditions>
         <action>
            
<treechildren flex="1">
               
<treeitem uri="?group">
                  
<treerow>
                     
<treecell label="?text"/>
                     
<treecell label="?groupid"/>
                     
<treecell label="group"/>
                  </treerow>
               </treeitem>
            </treechildren>
         </action>
      </rule>
   </template>
</tree>

The important part, of course, is the conditions element in the rule. From the starting point, it looks for a groups assertion, and (if one is found) assigns it to the ?groups variable. Then, it's told to treat the element at the end of that arc as a container (seq, bag, or alt... it doesn't care), and the rest of the conditions apply to each element it finds in the container (a Seq, in my case): the member of the container must have a "label" and an "id", which are then assigned to variables.

The second rule seemed like it should be very simple! I wanted to do basically the same thing as for the first rule, but this time it would be matching files instead of groups. A copy-and-paste with a quick edit produced this:

      <rule>
         <conditions>
            <content uri="?uri" />
            
<triple subject="?uri"
                    predicate="http:\//www.mozilla.org/sample-rdf#files"
                    object="?files"/>
            <member container="?files" child="?file"/>
            
<triple subject="?file"
                    predicate="http:\//www.mozilla.org/sample-rdf#title"
                    object="?title"/>
         </conditions>
         <action>
            
<treechildren flex="1">
               
<treeitem uri="?file">
                  
<treerow>
                     
<treecell label="?title" properties="File"/>
                     
<treecell label="?file"/>
                     
<treecell label="page"/>
                  </treerow>
               </treeitem>
            </treechildren>
         </action>
      </rule>

Simple enough, right? Yeah, except it didn't work.

I eventually figured out that I had to update the containment attribute in the tree tag, to specify that the predicate "http:\//www.mozilla.org/sample-rdf#files" should be treated as a container, so that when the groups rule matched the row would have the flippy triangle for exansion. (Just add a space at the end of that attribute, and type in the second predicate right after the first one.)

Reload the XUL file and... nuts. Now I get the flippy triangle, but the files still aren't being listed.

Let's make a long story a little shorter. I tried a zillion combinations, and eventually discovered that the template renderer will only use variables in the second rule that were also used in the first rule. New variable names are ignored. So, even though the second rule is matching files, and the predicates can be changed (as above), the rule's variables still have to look like you're matching groups.

Yes, I think that's ridiculous.

Here, finally, is the rule that works. Compare it with the rule that didn't work, just above, and the rule for matching groups above that (which did work).

      <rule>
         <conditions>
            <content uri="?uri" />
            
<triple subject="?uri"
                    predicate="http:\//www.mozilla.org/sample-rdf#files"
                    object="?groups"/>
            <member container="?groups" child="?group"/>
            
<triple subject="?group"
                    predicate="http:\//www.mozilla.org/sample-rdf#title"
                    object="?text"/>
         </conditions>
         <action>
            
<treechildren flex="1">
               
<treeitem uri="?group">
                  
<treerow>
                     
<treecell label="?text" properties="File"/>
                     
<treecell label="?group"/>
                     
<treecell label="page"/>
                  </treerow>
               </treeitem>
            </treechildren>
         </action>
      </rule>

I wrote to Nigel to tell him what I'd discovered. He was surprised, amused, impressed, and or disgusted enough to suggest I write it up. (Which, if you know me, you know I was going to do anyway.)

XUL Templates (tease/reminder)

seth@macrobyte.net — Sat, 30 Oct 2004 19:27:11 GMT

This is just a reminder to myself (ok, and a small tease for anybody who cares about such things) to write about the significant and apparently undocumented discovery I've made regarding xul templates for mozilla.

For those who care: I plan to have it written by Sunday night (I know Nigel cares, but he may be the only other XUL developer who ever visits my site!).

XUL Tree Selection: Problem Solved

seth@macrobyte.net — Thu, 28 Oct 2004 18:16:26 GMT

The problem I was having with xul tree selections (in Mozilla) disappeared when I installed build ID 2004101105. I had been using 1.8a4.

Guess that means it wasn't a bug in my code (or in my head).

Confusion (or Bug?) Regarding XUL Tree Selection

seth@macrobyte.net — Wed, 27 Oct 2004 13:57:57 GMT

I'm starting to wonder, "Is there anything more screwed up (in XUL) than trees?"

I want a safe, reliable way to get the current selection from a dynamic, template-based tree (but it's just single selection, not a multi-select tree).

The tree is template based, and lists "foos" in an RDF datasource. If a new foo is added to the RDF, then the tree gets a new row. (Each row has two cells, one with the name of the foo, and the other has the foo's id. The id column is collapsed. When I need to act on the foo selected in the tree, I get the selected row, and then get the id for the foo from the second cell in the row.

Here's my tree template (with names changed to protect the innocent):

<tree id="bar.sidebar.tree_foos"
    datasources="" ref="about:blank"
    containment="http://macrobyte.net/bar-rdf#foos"
    rows="6" flex="1" seltype="single"
    hidecolumnpicker="true" enableColumnDrag="false">
    
<treecols>
        
<treecol flex="1" id="foo_name" label="Foos" primary="true"/>
        
<treecol id="foo_id" label="ID" collapsed="true"/>
    </treecols>
    <template>
        <rule>
            <conditions>
                <content uri="?uri" />
                
<triple subject="?uri"
                        predicate="http://macrobyte.net/bar-rdf#foos"
                        object="?foos"/>
                <member container="?foos" child="?foo"/>
            </conditions>
            <bindings>
                <binding subject="?foo"
                         predicate="http://macrobyte.net/bar-rdf#label"
                         object="?fooname"/>
                <binding subject="?foo"
                         predicate="http://macrobyte.net/bar-rdf#id"
                         object="?fooid"/>
            </bindings>
            <action>
                
<treechildren flex="1">
                    
<treeitem uri="?foo">
                        
<treerow>
                            
<treecell label="?fooname"/>
                            
<treecell label="?fooid"/>
                        </treerow>
                    </treeitem>
                </treechildren>
            </action>
        </rule>
    </template>
</tree>

Now, when I need to get the selection, something like this (which I've written out the long way here, for clarity) seems to work fine:

var t = document.getElementById( "tree_foos" );
var ix = t.currentIndex;
var rows = t.getElementsByTagName( "treerow" );
var row = rows[ 0 ];
var cells = row.getElementsByTagName( "treecell" );
var id = cells[ 1 ].getAttribute( "label" );

This works most of the time, but breaks as soon as another 'foo' is added to the RDF, even though I'm calling t.builder.rebuild() after adding a new foo (which, it would seem, should cause the row indices to be reordered).

There's a lot of documentation on trees on mozilla.org and xulplanet, but most of it is crap.

For example, look at the xul reference on mozilla.org. It says that <tree> supports an attribute (and a method!) named "selectedItems". Yet, when I try to use it, I get an error in javascript because there is no such attribute.

For another example, look at the tree selection tutorial on xulplanet. This page tells you how to get the indices of all selected items in a multi-select tree. This works in my single-select tree, but it produces exactly the same value as the tree's currentIndex property, so I end up with the same problem: the value is *wrong* after the tree has been modified by a change to the RDF.

I can't find any documentation about dealing with row-index problems in template-based trees which have been updated due to changes in the underlying RDF.

Is this a bug in Mozilla's tree, or a lack of understanding on my part, or what?

(Note: I'm working with a fairly recent nightly build of Mozilla, as well as 1.8a4.)

DevEdge's Content to be Resurrected

seth@macrobyte.net — Tue, 12 Oct 2004 17:54:44 GMT

Yesterday I mentioned that DevEdge is gone. The site simply ceased to exist, and a lot of very useful content on CSS, JavaScript, HTMl, XHTML, and XUL vanished with it.

I hadn't seen mention of it anywhere else, so I also posted about it in two Mozillazine forum threads.

As reported on MozillaZine today, Mitchell Baker (Mozilla Foundation president and chief lizard wrangler) is aware of the problem and is trying to acquire a license to the DevEdge content (as well as copies of that content, nobody has it) for the Mozilla Foundation.

Based on the comments on Mitchell's page, I'm not the only one missing the DevEdge sidebars. ;-)

Most everybody involved, myself included, thinks this sudden disappearance was a mistake (an oversight) since it happened so suddenly and without warning. Getting AOL to rectify the mistake, though, will be a lot more work. Hopefully they'll sign the content over to the Mozilla Foundation without a second thought.

Whither Netscape's DevEdge?

seth@macrobyte.net — Sun, 10 Oct 2004 22:06:59 GMT

Sometime in the last week (probably in the last three days), the two developer sites once hosted and run Netscape went off the air. DevEdge and the older developer.netscape.com both seem to be gone.

The older one doesn't matter to me so much, but I used some of the developer sidebars hosted on DevEdge nearly every day.

If this is a permanent outage, I hope that Mozilla — or someone — is planning to host those sidebars again. I've been using them for so long I feel lost without them, and keep having to look in Google for other places that might host similar information.

MetaWeblog.getRecentPosts: Conflict and Confusion

seth@macrobyte.net — Wed, 15 Sep 2004 10:18:58 GMT

MetaWeblog.getRecentPosts: Conflict and Confusion

I'm trying to fix an apparent bug in Conversant's support for the MetaWeblog and mt (movable type) api's. Conversant's Weblog II plugin can be used as a mt-compatible weblog, or a MetaWeblog-compatible weblog, or even just a blogger-compatible weblog.

In fact, all three of those api's build on each other. Blogger is the most basicc. MetaWeblog "embraces and extends" it. The mt api does the same to metaweblog. That's important to understanding the apparent conflict I've run into.

The MetaWeblog RFC has an entry point called MetaWeblog.getCategories. You tell it what weblog you want to know about, and who you are, and it returns the information about that weblog's categories. Specifically, the api documentation says:

metaWeblog.getCategories

metaWeblog.getCategories (blogid, username, password) returns struct

The struct returned contains one struct for each category, containing the following elements: description, htmlUrl and rssUrl.

This entry-point allows editing tools to offer category-routing as a feature.

So it's clearly supposed to return a struct of structs, as it says, "the struct returned contains one struct for each category..."

Yet, it seems like everybody else has implemented metaWeblog.getCategories to return an array of structs, rather than a struct of structs. Examples: XMLRPCNET and xoops.

What am I supposed to do? It wouldn't matter to me what other server software has done, since I'm not trying to interoperate with other servers, but I do need (Conversant) to work with the client software... which, of course, has been written to work with the other server software.

The metaweblog spec was written by Dave Winer, so it's safe to say that Radio (as a client app) implements the spec he wrote... yet it looks like most other applications (both client and server) have gone the other way. Ecto for Windows, for example, expects the result of metaWeblog.getCategories to be an array of structs. (However, ecto uses the XMLRPC.NET framework, so this isn't entirely Ecto's fault.)

Is there any way I can handle this to be compatible with both camps? A client app could accept either type of result (like NetNewsWire's editor probably does, if I know Brent), but most of them don't do that. Since Conversant is a server app, what should I do: follow the original spec, or follow the more common spec? The purist in me suggests the former, but the realist (the one who wants to make the customers happy) says the latter.

What a mess. Simon Fell calls this the problem of slightly uniform interfaces.