colin dellow's bln

I just noticed, when viewing my blog, that the ads displayed on it were about Cocoon and other XML-related technologies. Very nicely done, Google and blogspot.com.

So, CIBC has kindly informed that after assessing the information Equifax rendered unto them, I'm probably not their ideal candidate for a credit card. Ouch. So, the conspiracy-theorist question becomes: If I had supplied my SIN number along with my application, would things have ended up differently? I understand the desire to get my SIN number - it's a powerful key to link databases together and give them more knowledge to make better decisions. But, on the other hand, I'd prefer not to be a number. Regardless, the application has a small note, with a veiled threat in it indicating that it's in your best interests to give them a SIN number. Where do I go from here, I wonder? I've never particularly liked CIBC -- I needed a parent to open up (and to cosign on!) my account when I was 17, I needed a parent to get cheques drawable on my account, and now this. Plus, a friend of mine recently applied for their Classic for Students credit card as well - they confused this with their Classic credit card, which required higher minimum income levels. In the process of sorting it out, one of their "Credit Specialists" ended up being suspended for a week without pay due to obstinancy and rude treatment of my friend. Is this an organization I want to do business with? Perhaps it's time to evaluate this whole banking scene now that I'm a little bit older and am wanting more services from them.

Also, yay for Cocoon. I've finished the client creation/modification/listing/deleting system, and am looking at refactoring the code for optimal reuse and style.

Hmmm, so as it turns out, it is ridiculously straight forward to pull data from Xindice into flowscript . Just take the demonstration code from the XML binding example in the samples/woody/ directory, then change it so the URI uses the xmldb pseudo-protocol...You end up with a Document object -- that's the DOM of your data. "Well, that's it. Easy, peasy, Japanesey. Any questions?"

What is not so straight-forward is how to delete collections using the query tag parsed by the XMLDBTransformer. I've started poking around in the cocoon source, but that will probably wait until tomorrow for a really thorough investigation.

Well, happy birthday to QE2.

Twas a remarkably productive day, considering I woke up at 2PM. Added delete/edit party functions to my web app, got the knack of doing sleazy tricks with Cocoon and am feeling like future progress should be much more rapid.

Then off to Brett's for a bbq with him and Chan and some general hanging out. Ah, barbequing on top of a car hood. Almost like keeping beverages in the garbage to keep them cooler.

Tho I didn't get to speak with Jenn, since she was out at her own bbq thing for the day. (Granted, I *was* up til 5 talking to her...)

...is almost as bad as MSIE's client-side javascript debugger. At least IE tells you a line and a column reference (even if they're totally bogus, and let's not even mention the way IE chokes on debugging external scripts). While coding, I accidentally put new newList = new Array(); instead of var newList = new Array();.

It blows up with org.apache.avalon.framework.CascadingRuntimeException: Invalid assignment left-hand side.. No hint of a line number, mind you. That'd be too useful. In this case, I was lucky -- the error message itself pretty much tells you what to look for. But in more subtle coding errors, this is a major flaw in the Cocoon framework. It's not "rapid application development" if you're spending an hour debugging silly JS mistakes that the server is too dumb to help you with.

As an aside, I think I've solved the problem of having multiple submit buttons. Here's the use case: I'm adding individuals to a client account. I want the user to be able to delete/edit parties they have already added to the client listing. But due to some issues with WoodyTemplateTransformer, you can't dynamically use JXTemplateTransformer to generate extra submit buttons on the fly -- they won't be recognized as real submit events.

My (half-baked?) solution: In your form binding, define two submit buttons, one for edit, one for delete. Also, define a field to indicate which party you wish to edit. In your layout, make the party indicator a hidden field. Then display the same edit/delete button for each party, but make them set the party indicator on onclick. Works beautifully.

You are a GRAMMAR GOD!


If your mission in life is not already to
preserve the English tongue, it should be.
Congratulations and thank you!


How grammatically sound are you?
brought to you by Quizilla

Sure, technically correct but can't really *communicate* for a damn. That seems to fit the idea of an engineer, I think.

Student of science that I am, I conducted a null hypothesis test. Selecting the first option for each of the 20 questions generates:

You are a MASTER of the English language!


While your English is not exactly perfect,
you are still more grammatically correct than
just about every American. Still, there is
always room for improvement...


How grammatically sound are you?
brought to you by Quizilla


Ouch, baby. Very ouch.

...is really easy.

In your source file, you just put, for example:
<cinclude:includexml>

<cinclude:src>xmldb:xindice://localhost:8080/db/lawoffice/clients/#//party[@id='1']</cinclude:src>

</cinclude:includexml>
So, pretty straightforward. Address of XML resource, # symbol, XPath query to execute.
(For my application, this extracts the data for the first party of each client.)

Then in your sitemap, toss a <map:transform type="cinclude"/> in the pipeline for your source file and you're laughing. You will need to add <map:transformer name="cinclude" src="org.apache.cocoon.transformation.CIncludeTransformer"/> to your <map:transformers> section if it's not already present.

The output from the command will look something like this, assuming only 1 nodeset matched:

<xmldb:results xmlns:xmldb="http://apache.org/cocoon/xmldb/1.0" query="//party[@id='1']" resources="1">
  <xmldb:result docid="1">
    <party xmlns:src="http://xml.apache.org/xindice/Query" id="1" src:col="/db/lawoffice/clients" src:key="1">
      <name>
        <first>Colin</first>
        <middle>L.</middle>
        <last>Dellow</last>
      </name>
    </party>
  </xmldb:result>
</xmldb:results>


So I'm really getting annoyed at the entire collection of XML-related software tools. Do you really need to preface everything with an X? Xalan, Xang, Xerces, Xindice, Xupdate, Xquery, Xpath... I'm also annoyed at how the documentation for Cocoon sucks. And don't give me the usual open source trash about how I can go fix it if I don't like it -- I don't understand it enough yet! (Perhaps one day...) I especially enjoy how the Cocoon Wiki has a nice smattering of articles, each relevant to a different Cocoon release. Taken on the whole, they probably just screw over newcomers to the Cocoon scene more than they help. Someone with experience should scan through it and cull the outdated stuff.

The good news: I've finally got Cocoon 2.1.4 and Xindice 1.1b4 playing happily with each other. It even supports XUpdates, which is nice.

I'm a bit confused - the problem manifested itself as an exception compiling the xupdate query due to the fact that the xmlns:xu attribute was being clobbered in one of the pipelines... but I have no idea where or how. I ended up just hacking the queryDocument() method in Collection.java. First, declare the following constant in the class declaration area:
protected static final String SEARCH_STRING = "";

Next, near line 1232, right after the public final NodeSet queryDocument(String style, String query, NamespaceMap nsMap, Object key) declaration, insert the following piece of sleaze:

query = query.substring(0, query.indexOf(SEARCH_STRING)) +
"" +
query.substring(query.indexOf(SEARCH_STRING) + SEARCH_STRING.length(), query.length());


Now the next thing to look at is how to get arbitrary fragments from Xindice included into random documents. The CInclude transformer and xmldb pseudo-protocol are looking mighty useful for that right about now.

Yaaaay, such goodness.

Yesterday I left work early to catch my bus...to Toronto. Since Lindsay was passing through the centre of the universe on her way home to the Creek, Tyler planned for the two of us to swing by and spend the evening with her and Heather. For $23.67 return, that's a pretty damned good deal. Go Greyhound! I really liked getting out of the loo and seeing la famille. Yay for Tyler.

Oh. And Graeme broke the build, not me. Yay, free donuts.

And when you're biking home from the bus depot at 1:30AM, there is absolutely no traffic and you can really make good time. A little under 20 minutes for 4 miles uphill. I was happy. Such a good day!

Apparently, I have an eensy, weensy, tiny bit of an Internet usage problem.

(Tip: Match the final bill to the Software Engineering administration with the charges assigned to `cldellow' after the subsidy.)

So I felt bad enough with putting the cheesy pun in the site's title. But I was blinded by my pride. "I'm so crafty," I thought. To ensure my uniqueness, I Googled for it. Turns out, I'm not the only person to make the joke. In fact, it's another UW student. In fact, it's a UW CS student. In fact, it's Sahab. Shit. I feel shame. I swear I didn't know!

That bastard Sahab's website.

(See the title.)

I didn't know Google was into this blog stuff. Kinda sleazy, IMHO...
But wow...slick interface. I want, I want!