Anyway, here's what the institutions said:

Originally this was going to be a more exciting post...but I guess I was too optimistic

On the bright side, it makes me happy to be a customer of Vanguard's, now. Their response was the only one that wasn't simply "thanks, we'll forward that to the appropriate party". Even though their answer was pretty much "no", it came back quickly and concisely -- it took only like two hours turnaround, whereas most of the others took 2-3 days.

Also, Bank of America/CapitalOne/Chase sort of piss me off in that they *require* you to use their crappy internal messaging system, even for interacting with the company in as mundane a way as this. Not only that, but I wasn't even notified when they'd replied. Am I really supposed to sign into my bank website every day to check for messages?

Does your bank plan on supporting OAuth? Let's raise the awareness a bit so we can get even more cool online tools for managing finances!

The process: for a given page (say, a search page), pull the data out of the database that you need in the controller and then output all the raw data as XML needed to generate the page in the template.  For a search page this would be the search results, the user's name (if signed in), etc.  Then you have your XSLT stylesheets.  Since this is all client-side, each one you have generates a request.  If you have one stylesheet that renders the initial page, and that stylesheet requires 4 other stylesheets...well, you have 5 requests right there just to display the page.

These other stylesheets should be mostly static, I'd hope.  In my mockup I didn't have to make any of them dynamic, but then I wasn't trying to do anything super advanced.  Anyway, Thin is smart enough to send 304s for the unmodified XSLTs, so at least that's good...

Other notes: one can do server-side rendering, but that's not the point of this exercise -- I want to do pure non-Javascript client-side rendering.  Unfortunately this also rules out XSLT 2.0, which was only finalized in January 2007 and would probably ease some of the pain.

Anyway, time for Code!

Code

Adding HTML elements based on data

...is a pain.  See here for my solution of preserving dropdown selections after a search (i.e. you search in a particular category and that category shows up in the dropdown on the end page).  Grotesquely verbose?  Why, yes it is!  I don't think there's a better way, either -- it would be acceptable to have a function that outputted XHTML instead of a template, but I think that's that's a 2.0-feature only.

Changing values based on data

This one isn't quite so bad, actually.  As with the previous example, though, you'll notice that you can't pull data in from the query parameters -- it has to be pulled in from the XML.  The original request has access to the query parameters, immediate requests could have access to the query parameters (since the original request url is passed in to immediate requests as the referrer), but non-immediate requests couldn't have any access to the query parameters at all whatsoever.

So what does this mean?  All data needs to be in the XML.  Not just product search results and personalization data, but also what the search query was, what the category was, what the sort order was, etc. if you plan on displaying any of that information.  Ugh!

Preserving query parameters in links

Guess what, more fun!  Check this out.  This is for pagination of search results -- all parameters needs to be preserved except for the page, which obviously changes.  Since this time the data needs to be stored in the attribute of another tag, we have to capture the template call into a variable first.  Cool, huh?

If anyone knows of a better way to do any of this with XSLT 1.0, please do let me know.  I am quite the novice and am just posting my discoveries thus far.  No guarantees of completeness.

Other issues

Javascript/jQuery

I was trying to figure out how to pull data from the original XML sheet via JavaScript, but it seems that JavaScript only has access to the rendered XHTML.  I could do an AJAX call to re-fetch the XML sheet and operate on that, but that seems silly to me.  I've tried looking for a cross-browser non-plugin solution but I don't think jQuery offers anything in this way.

Discussion

In regular HTML, you have HTML, CSS, and JS -- typically referred to as Structure, Display, and Behavior.  But really, HTML is typically structure and data combined, plus elements of display.  XML+XSLT is nice in theory because it explicitly breaks up structure/display and data.  But how much does that really buy you?  On modern MVC-style web frameworks, the controller passes data to the view/template so that the data can be rendered.  But with XML-XSLT the controller renders XML so that the client can transform that XML using the XSLTs you provide.  What's the point of emitting XML when you could just emit XHTML?  Frankly, data and structure don't *need* to be separated -- if you want just the data, then you need to set up a web service.  Frameworks like Ruby on Rails make this trivial.

So I guess the main benefit of separating data and structure the way XML and XSLT does is it means for the same XML, you can have different sets of XSLTs.  But wait...actually, you can't.  You embed the references for stylesheets for the XML file IN the XML file itself, i.e. the XML file says use this XSLT to render me.  So...if you want to switch XSLTs, you have to modify the XML file, which means you have to make the XML file content dynamically generated, which means you might as well use a fully-featured templating language on the server side.

Conclusion

XML+XSLT may have its uses, but general web applications is not one of them...

Check it out. Someday I'll create a screencast for something useful.

Requirements: Firefox, Greasemonkey Plugin

Check it out here: GitHub repository

Here's a picture: Picture

You don't have to understand it to see that it's at least a bit interesting, so check it out:

http://www.nutriscan.org/jquery_optimization/

It documents a bunch of different ways of doing similar things, and compares them in terms of performance. How much are you really losing by using the jQuery convenience method?

And for once, that's a good thing, because by "done for now" I mean..."done" pending more ideas. It's thoroughly documented and tested, and I think I might just set it aside for now until I find other features it needs to interact with Merb better. Which may be never.

On the bright side, Minirequest/Solitary Part came out of it and is now living in its own repository. It's like half done, but doesn't have tests or much documentation. Also I'd like it to work with partials, which it currently doesn't handle at all. After that though, it's on to my next project...

Enter jquery_merb, or jquery.merb.js.

This library takes on a different role; rather than generating javascript for you (ew) it's meant to be a collection of helpers that assist your coding in interacting with your Merb server. For instance, if you want to use AJAX to perform CRUD operations on a resource, instead of hacking together an ajax call you can say this:

$.merb.resource.read({resources: 'notes', id: 5, dataType: 'json'})

Neat huh? The interface isn't quite as clean as it could be, but alas, that's because of the inescapable fact that resources have singular and plural forms which can't be resolved programmatically in JavaScript.

The thing I've been working on for the past couple days actually does dip into the merb side, but only just. I think it would be cool to be able to easily reload a part (using AJAX) that you use in your view, without a lot of extra work from you (no special controller methods or templates, or even writing an ajax call). This would mean something as simple as $("#my_part").merb_reload(); and the part would reload with, say, the most recent blog posts. See here for more details.

So that's what I'm working on these days...

But, in the end, I think CouchDB is not the best way to solve this problem...

CouchDB is what's called a document-oriented database. This is as opposed to relational databases, like MySQL, PostreSQL, Oracle, even sqlite. For convenience I'm going to abbreviate each as DOD and RD, respectively.

How they differ:

1. DODs are schema-less. This means there are no columns/fields to speak of with size constraints. A "document" is a record in the database, which is essentially a hashmap (or associative array if you prefer) with a couple other little features (i.e. revisioning).
2. There are no "queries" in DODs (CouchDB, at least). If you were curious about how something without rigid structure could be fast, this is how. Instead of queries, you have "views", which are only slightly related to views in the RD sense. There are two types of views -- permanent views and temporary views. A view is the result of calling a user-defined function on every record in the database -- if the function evaluates to true, the record is included in the view. Permanent views are stored in the form of design documents within the database itself. Every time you add or modify a record, every view function is called on that record to (re)evaluate whether that record should be included in a particular view. Temporary views are the basically the same, but not stored permanently in a design document -- they disappear after they're used.
3. Some other things, see Wikipedia or their official page.

So here's the problem. You can't just say "Show all blog posts by user X", because that would require you pass a variable. Not a big deal; you create a view that returns true if the blog post belongs to that user. But still, you have to create a view for every single user if you want to be able to select all the blog posts by any particular user -- I'd imagine that could take up a lot of space, and CPU cycles. Alternatively, you could have a view that just returned all blog posts, and then filter through those in your application. Neither would be that good though, I feel, but I might be missing something.

Similarly, in a log file, you can't say "Give me all records with session ID Y" -- you'd need a view for that, and a temporary view would have to be generated on the fly, and the permanent view...well, you'd want a permanent view for every session ID, and there could be tens of thousands of those. Plus every time you add a new record, you'd have to run the view functions for all those on it, and that could take a while.

On the bright side, CouchDB doesn't have any locks in it (helps that it was written in Erlang). This means that no matter who or how many are reading or writing, nothing will ever get blocked. Additionally, I guess you can seamlessly distribute the contents of the database across multiple servers and get redundancy pretty easily, but I haven't looked into that tooo much. Also, CouchDB is technically Alpha, so all of the functionality hasn't actually been implemented yet, like interfacing with Apache Lucene (a full-text indexer search thing).

So CouchDB looks like it has a lot of potential, but I'm not exactly sure for what, unless you never have that many documents in the database or not that many different parameters you want to be searching on.