Here’s one that took way too long to figure out (mostly because I couldn’t think of a good Google search for what I was looking for). Hope this entry has enough keyword stickiness to help someone else out.

To override ActiveRecord’s default naming schemes (pluralized table names, "id" as the name of the primary key), you can use the following ActiveRecord methods:

  set_table_name "MY_TABLE_NAME"
  set_primary_key "MY_KEY_NAME"

Those methods should override Ruby on Rails’s default behaviors and let you use your own names for ID/primary key fields and table names.

technorati tags:ruby, on, rails, activerecord, database

As reported by Kyri and Larry, two of my coworkers here at TheLadders:

Dojo has problems on IE when it’s running over SSL. When Dojo creates background IFRAMEs for things like animation and transport, it initializes those IFRAMEs without a src attribute. The fix? Add a URL (any URL will do) to the src attribute of any occurences of IFRAMEs in Dojo functions that you’re using.

technorati tags:dojo, iframe, ssl

I’m working with another powerful widget from Dojo: the Dojo tree widget. I’ll continue to post some "hands-on documentation" like that I did with Dojo’s FisheyeList Widget. Here’s a quick tip off that bat that’s not readily apparent.

If you want your tree to be expanded when it loads (instead of showing the top level container only), you’ll need to make use of the expandLevel property. Here’s how it looks in code:

By specificing an expandLevel of 2, we tell the widget we want the top level container expanded to expose its children on load, the behavior you’d get if you clicked the expansion icon for the top level container. 1 is the default expandLevel; it shows the parent and nothing beneath it. These levels increase (expandLevel="3", expandLevel="4") to accomodate initially expanding your Tree to whatever depth you’d like.

technorati tags:dojo, dhtml, javascript, tree, widget

Douglas Crockford, JavaScript genius, presents an article on the use of "new" when creating objects in JavaScript. Excellent read that will make your code better. I know I’ll use his <select> code somewhere.

technorati tags:javascript, functions

This IE6 browser bug shows up if you’re trying to get PNG transparency to show up in Internet Explorer 6 and below using Microsoft’s alpha image filter. What’s the deal? Well, if you’re using that filter on a background-image, then you won’t be able to click on anything appearing above that background-image. Have a form as a child whose parent is using the filter for its background? You won’t be able to click on any of the form elements. At all. The solution? Don’t use a PNG and that filter. It’s not particularly desirable – in fact, it can really mess with your design – but it’s better to leave the filter right out, unless there’s no need to click, highlight, or otherwise interact with an element on the screen.

technorati tags:browser, bug, ie6, microsoft, image, alpha, filter

Need to save the content_type of a file upload in Ruby on Rails? Here’s a simple one-liner for your model that does it:

self.content_type = incoming_file.content_type.to_s.strip!

where incoming_file is a reference to the file that’s been uploaded. Why the strip! call? Because Rails (at least on Windows) stores an extra character (newline / carriage return) at the end of the content_type field. strip! (the bang method) drops that last character in place, letting you do everything in that single line.

technorati tags:rubyonrails, file, upload, ror

Been looking for an IE7 CSS hack? Been looking for an Opera hack? Odds are, you can find something around here. This is one of the most comprehensive CSS hack sites I’ve seen. By far, the best part is how granular this site gets: just about every browser you’re going to find is covered.

My thoughts on cascading style sheets hacks? Well, since you’ll be using them to correct Internet Explorer’s bad behavior, you should use what Internet Explorer gives you: conditional comments. Use conditional comments to keep IE fixes in a separate CSS file. That’s what I like to do when I have the time: it keeps the "good" code separate from the "bad." Plus, if Microsoft releases any fixes, you need only to adjust the conditional comment; since Microsoft’s conditional comments allow tests against browser version, you’ll be a lot safer with conditional comments. Plus, it keeps your regular stylesheets clean.

If conditional comments aren’t your thing (perhaps because they’re not traditional markup, although they do validate), you can try minimized attribute selectors. Why? Because minimized attribute selectors let you separate IE and Firefox/Opera/Safari CSS selectors into separate blocks. Create an IE block, then "fix" that code in a minimized attribute selector on the line below. This clearly separates IE corrections from compliant code. Unfortunately, these types of selectors aren’t XHTML compliant and are basically out if you’re writing XHTML.

This leads to my final choice, the one I’d probably recommend if conditional comments are out of the picture: exploiting IE’s failure to support media selectors on @import rules. This works almost the same way as conditional comments do, but instead of placing IE code in a separate file, you place compliant code in a separate file, which you then import to correct your IE CSS. Instead of keeping "good" code in your main stylesheet, you use the hack to correct the bad code.

I strongly recommend conditional comments: they’re the cleanest way to render CSS across browsers, and they are flexible enough to allow you to avoid using hacks in your code. If browser compatibility changes, just update the condition. Plus, there’s no nasty hacks that may be corrected in future browser releases hanging around in your stylesheets. But, if the best option isn’t your option, it’s nice to know there are other ways to make your pages render correctly cross-browser.

technorati tags:css, ie7, browser, hack, stylesheets, cascading, conditional, comments, css, hacks

IE7 is slowly spreading. The morning, I booted up my computer only to see the little MS auto update shield. No big security fixes this time: Microsoft was giving me IE7. If you’re a web engineer like me, I hope you’ve had time to run regression testing on your site. If you’re scrambling, here are a few links to know:

• Been procrastinating on your IE7 roll-out plan? Here’s what I recommend: just keep checking your logs, looking for the point at which the update causes IE6 and IE7 stats to "flip" Since it’s an automatic update, everyone will convert at once: the stats for user agents visiting your page should flip flop, with IE7 picking up IE6’s numbers. At that point, make the switch yourself and begin developing exclusively in 7.
• Still need a copy of IE6 for testing purposes? Evolt has you covered with a downloadable copy of every browser in the history of mankind. Grab a copy of IE6 to keep for testing purposes, because your current copy won’t be around much longer.
• If you haven’t checked the excellent Microsoft IE developer blog yet, you may wish to do so. They’ve been keeping running updates of what IE7 will and won’t do, and what will change (and break) between IE6 and 7.
• Finally, Microsoft has an Internet Explorer developer center with more (albeit cursory) information on the browser, and a few readiness toolkits that will walk you through changes.

I’ll post any quirks or hacks I can find. In the meantime, good luck!

technorati tags:ie7, cross-browser, development

Here’s a quick little tip to keep in mind when working with JavaScript: you can quickly convert a number (int, decimal, etc.) to a string by doing this

var i = 1;
var newString = i + "";

Edit on 11/21/06, 12:21PM Eastern. As pointed out in the comments below, my "excellent" example is totally bogus and leads to invalid (X)HTML. (It does, however, work in browsers, while it shouldn’t.) If you need a numeric ID, do what I do in the real world, not in my examples: preface it with a unique identifier. (Talking about baseball cards? How about using "bbc_NUMBER"?). In my own defense, this was the only thing I could think of to illustrate my point at the time. Bad example follows. ARGH!.

Now, you’re thinking: wow, why would you explain something so stupidly simple? Because even though it’s simple, it’s a useful and powerful technique. How? What if you’re working with numeric IDs on the backend that are printed dynamically into your code on the front end? Eventually, you’ll wind up with something like <element id="1" />. You’ll have a string ID and need to send an int back. Or, you’ll be iterating through a for loop, and you’ll need to do something with that iterator (access an element in the DOM, say).

Let’s say you have a function that looks like this bound to element’s onclick:

function myFunction(anID){
  // hide clicked-on element
  document.getElementById(?????).style.display = "none";

  for(var i = 0; i<4; i++){
  document.getElementById(?????).style.color = "red";
  }
  // send an AJAX request back with this ID
  sendAjax(anID);

  //Yellow fade to show done
  yellowFade();
}

Is anID an int? Convert it to a string in your document.getElementById() call like so:

document.getElementById(anId+”").style.display = "none".

What about that for block? Fill that in like so:

document.getElementById(i+”").style.color = “red”;

>Your ints are now strings.

technorati tags:javacript, dom, dhtml

How do you make product specifications comprehensive enough for AJAX, Web 2.0 apps? Simple boxes and arrows aren’t going to cut it: your spec must talk about complex interactions and behaviors, timings (of updates or polling), and application states. In short, you’re not just writing a document that talks about how code should work; you’re writing a document that talks about how people should work with your code.

Adaptive Path took a stab at the Web 2.0 spec and what’s beyond wireframes and came up with a three-pronged approach to documenting Web Twenty apps. Their approach is as comprehensive as any I’ve seen. However, cranking out specs like this seems like a product of having a lot of time (read: billing clients for hours worked) and may only play out will on large, highly interactive projects. (On short projects, these specs might take longer to build than the actual end product).

Specs really do help development, and Adaptive Path’s spec helps capture all of the important pieces of end-user interaction that make or break an app. Ultimately, these things are only as good as your product team: the people responsible for building the spec must have comprehensive knowledge of what can happen in an application for them to document that behavior or they must be willing to work with, and adapt their ideas to, the knowledge of practicing developers or designers whose knowledge of possibilities is greater. In all, writing specifications should be an iterative process with input coming from across all disciplines, a change advanced web applications are forcing to happen.

technorati tags:specs, product, design