There are two things you want to sort out in Rails3 to get jquery humming along really nicely.
Firstly is the UJS. Rails3 has done great things in replacing all the inline JS with UJS and nice semantic XHTML - but, of course, they ship with the Prototype version of this UJS file.
You’ll want to just overwrite the public/javascripts/rails.js file in your project with the jquery version from github.
So the next step would be to add the javascript_include_tag to all your layouts, and if you’re a jquery fan then you’re probably used to something like this:
javascript_include_tag 'jquery', 'jquery-ui', 'rails', 'application'
At best, if you have only one layout, that’s ugly. When you begin to get more than one layout, you’re un-DRY, or you’re writing your own helper to wrap that up. It just gets uglier. Especially when compared to the Prototype equivalent:
javascript_include_tag :defaults
How do we get this logical grouping of JS files?
Well, I might just be the last one at the party here, but I couldn’t find anything online, or anything obvious in the help, for how to DRY this up. A quick dig in the source revealed the answer though. Somewhere in your init files (in Rails3 I have this in config/application.rb - but this will work in previous versions of Rails too) you can register what’s called an expansion, like so:
ActionView::Helpers::AssetTagHelper.register_javascript_expansion \
:jquery => %w/jquery jquery-ui rails application/
So then in your layouts you can use that expansion like so:
javascript_include_tag :jquery
Much nicer, and very simple to update in a central config location, should you wish.
As I pointed out here on the WWR Forums when you have a set of static conditions, even if you only use them once, then you should consider using a named_scope to encapsulate those conditions in your model.
So instead of having this in your controller:
app/controller/foos_controller.rb
def inactive
@foos = Foo.all(:conditions => "active is null")
end
You would shift that concept off into your model by using a named scope. So you’d have this instead:
app/models/foo.rb
named_scope :inactive, :conditions => "active is null"
app/controller/foos_controller.rb
def inactive
@foos = Foo.inactive
end
Note that what’s returned from inactive is a proper ActiveRecord collection, so you can call all your AR records on it, eg:
@foos = Foo.inactive.find_all_by_bar(params[:bar])
This is a great way to push the business logic off into your model and refer to it by name (not code) from your controller.
A/B testing, split testing, side-by-side testing, call it what you like but for those interested in improving the performance of their marketing it’s crucial to test your copy, headlines, imagery and visual arrangement.
I’ve just packaed up guerrilla_rotate, an internal tool that I’ve been using for a while, and stuck it up on my new best friend: github
It’s best to use this in combination with Rubaidh::GoogleAnalytics in which case it’ll just do what you expect for your stats. If you don’t use that, then you’re on your own with how to track the stats, manual analytics of some sort, or who knows - old school, unique image tags in each view.
Have fun.
I’ve just rewritten inline_attachment to have more features, with less code, and be more reliable (ie. not as likely to break with a Rails version bump).
The coolest new feature is full support for the ActionMailer auto-multipart feature, so mostly you won’t need to write any complex MIME part crap in your model. No code is always good :)
Quickly
app/models/notifier.rb
class Notifier < ActionMailer::Base
def signup
recipients %q{"Testing IA" <testing@handle.it>}
from %q{"Mr Tester" <tester@handle.it>}
subject "Here's a funky test"
end
end
# Oh yeah baby! Read it and weep! So how's this work? Well, you'll need
# your templates named properly - see the `Multipart email` section of the
# ActionMailer::Base docs.
signup.text.plain.erb
Your username is: <%= @username %>
signup.text.html.erb
<html>
<head>
<title>Signup Notification</title>
</head>
<body>
<%= image_tag "logo.png" %>
<p>Your username is: <%=h @username %>
</body>
</html>
Obviously you also need that logo.png in your public/images directory.
I’ve ditched this because to_param is just such a simple solution. Google it and read, it’s so simple.
When we incorporated Google Adsense into Freedraw we just couldn’t find a simple to use plugin that would insert the ads we needed into our layouts.
How the plugin works is simple, you define how the ad should look within your config/googlead_sense.yml file (a sample one is provided with the plugin). You’ll want to change at least the adclient setting otherwise I’ll get all your ad revenue.
Actually, don’t change that setting! :)
Then just add it into your views or layouts, like so:
<%= google_ad %>
This is a bit different to how the old one worked, you used to have to define all those settings in each controller that you wanted to use the helper in.
This is simpler, and you still have some control over the format in your view, like so:
<%= google_ad(:skyscraper) %>
To install the plugin:
script/plugin install git://github.com/JasonKing/google_ad_sense.git
You can see more here
IE6 is like some slightly slow friend who is very much too big for his age, and sometimes you just plain to forget to invite him to the party.
Attribute Selectors are just about the coolest things there that ever did come to CSS, especially when it comes to submit buttons. Oh, how wonderful to style your form one way, and then have a little special treatment for your submit (or reset) buttons, like this:
input, select, option, textarea {
font: 11px sans serif;
color: grey;
border: thin solid grey;
}
input[type=submit] {
background-color: gray;
color: black;
}
