require 'lib/some_rake_file' # or require 'lib/some_rake_file.rake'

=> rake aborted!
no such file to load — /home/your_project/lib/some_rake_file

Rake assumes the ‘require’d files end in .rb, so it won’t find your .rake files. You need to import rake files:

import 'lib/some_rake_file'

This is fine for individual files, but I wanted to include all files that end in .rake in my tasks dir:

Dir.glob('tasks/*.rake').each { |r| import r }

…and there you go. While dead simple, this exemplifies an important distinction between require and import that I found to be poorly documented. Keep your rake tasks organized and remember that Rake isn’t just for rails apps!

If you need to style the tabs uniformly, then you’ve got little work to do. Just set the StyleName attribute on the TabBar itself and just define it in your stylesheet.

<mx:TabBar id="tabBar" styleName="myTabBarStyle"  />

.myTabBarStyle {
	tabHeight: 28;
	cornerRadius: 0;
	horizontalGap: 0;
	horizontalAlign: right;
	backgroundAlpha: 1;
	backgroundColor: #357cc6;
	borderStyle: none;
	borderThickness: 0;
	dropShadowEnabled: false;
}

Now that’s all good and well when all your tabs look the same. What if you want to apply styles to tabs individually? Well, if you’ve got 3 tabs or less you can use some css selectors to reference the book ends specifically, and let the general style apply to the middle tab.

.myTabBarStyle{
    ...
  tabStyleName: "greenTab";
  firstTabStyleName: "blueTab";
  lastTabStyleName: "yellowTab";
}
.greenTab {
  fillColors: #a5d414, #87c408;
  backgroundColor: #87c408;
   borderColor: #87c408;
  themeColor: #a5d414;
}
.blueTab {
  fillColors: #5a9cd6, #357cc6;
  backgroundColor: #357cc6;
  borderColor: #357cc6;
  color: #ffffff;
  textRollOverColor: #ffffff;
  themeColor: #5a9cd6;
}
.yellowTab {
  fillColors: #333333, #333333;
  backgroundColor: #333333;
  borderColor: #646464;
  color: #F8ED6D;
  textRollOverColor: #F8ED6D;
  themeColor: #646464;
}

When you have 4 or more tags, you need to set their styles by getting a reference to the tab itself and call the setStyle() method. Straight forward? Yes. Easy to find information about? No… in fact I ran into trouble because there wasn’t any documentation available for an individual tab’s class and FlexBuilder 3 has no source code for the mx.controls.tabBarClasses package.

Import the Tab code, get a reference to the tab you wish to style, and call setStyle() for each attribute you want to change. Let’s say you have 4 tabs and each has a different style. You can combine all 3 methods of styling by using the css code above to set the tab style for all tabs in the tabBar, override styles for the first and last tabs, then specifically grab the 3rd tab and override its style in the component:

  <mx:Script>
    <![CDATA[
	import mx.controls.tabBarClasses.Tab
 
       private function tabBarCreationComplete():void{
	  var tab:Tab = tabBar.getChildAt(2) as Tab;			  
	  tab.setStyle("fillColors", ["#edb000", "#e69500"]);
          tab.setStyle("backgroundColor", "#e69500");
          tab.setStyle("borderColor", "#e69500");
          tab.setStyle("themeColor", "#edb000");
       }
    ]]>
  </mx:Script>

And update the TabBar control:

  <mx:TabBar id="tabBar" 
                     styleName="myTabBarStyle"
                     creationComplete="tabBarCreationComplete();"  />

You can iterate through each tab in the TabBar and set each tab individually if desired. I hope this helps some Flex developers out there who are confused by styling many tabs individually!

The Options Hash

The most obvious way to change the output is to use the options hash outlined in the docs. A short list of options you might want to explore is:

• except => [:attr1, :attr2] — excludes attributes in array from output
• only => [:attr1, :attr2] — output contains only the specified attributes
• include => [:assoc1, :assoc2] — calls to_xml on the given first level association and nests it in the output
• methods => [:meth1, :meth2] — adds a tag to output in the format <method-name>[method output]</method-name>

Usage is incredibly simple:

  # grab xml for a record and its child
  my_record.to_xml(:include => :child)
 
  # same, but only output the ids and names (assuming both have these attributes)
  my_record.to_xml(:only => [:id, :name], :include => :child)

Behold, the Builder

A fantastic feature of to_xml that Ryan blogged about last year is that it yields the builder, thus allowing you to add arbitrary tags into the output. What’s more is you can pass the builder into another object’s to_xml method inside the outer block and produced nested xml.

For example:

  # Arbitrarily insert a tag
  my_record.to_xml do |xml|
    xml.some_tag some_value   #=> <some_tag>some_value</some_tag>
  end
 
  # I want to get xml for my record and all its children
  my_record.to_xml do |xml|
    my_record.children.each{|child| child.to_xml(:builder => xml, :skip_instruct => true)}
  end

You can nest as deep as you want without overriding a model’s own to_xml method:

  output = my_record.to_xml do |xml|
    my_record.children.each do |child|
      child.to_xml(:builder => xml, :skip_instruct => true) do |fxml|
        child.grandchild.to_xml(:builder => fxml, :skip_instruct => true)
      end
    end
  end

deep_xml: Model methods that utilize (but do not overwrite) to_xml

I chose to write methods in the models that handled including the children’s xml such that a single call to my_record.full_xml would produce nested xml automatically. Notice how the builder is being passed to the children, it’s important!

  class ParentClass < ActiveRecord::Base
    has_many :children
 
    def deep_xml(builder=nil)
      to_xml(:builder => builder) do |xml|
        children.each{|child| child.deep_xml(xml)}
      end
    end
  end
 
  class Child < ActiveRecord::Base
    belongs_to :parent
    has_one :grandchild
 
    def deep_xml(builder=nil)
      to_xml(:builder => builder, :skip_instruct => true) do |xml|
        grandchild.to_xml(:builder => xml, :skip_instruct => true)
      end
    end
  end
 
  class Grandchild < ActiveRecord::Base
    belongs_to :child
  end
 
# Now the call is simple:
Parent.firstdeep_xml #=> custom xml for a parent that includes its 
                        #   children and their grandchildren (1 each in this case)

There’s not much to it, but I found this solution to be nice shorthand that cleaned up ugly nested to_xml blocks I was writing over and over. I call my_record.deep_xml from any layer of the family tree and return a nice drill down of data to the leaf children. It’s great if you’re working with a complicated database and need to be able to present your data in xml.

If you are so inclined…

If you really need to, you can just overwrite the to_xml method in the model. While fine to do if you know you’ll always want that one specific template, I avoid it as much as possible and won’t cover it since examples are all over the blogosphere. Why not just make a separate function to avoid producing unexpected results for someone else who joins your project later on?

I hope most rails dev’s out there take advantage of RESTful routes and the url-generating helpers so readily available these days and actually enjoy them. But for some of you who are lucky enough to inherit a legacy app (you know, 1 year olds) or for whatever reason encounter loosely defined link_to’s [exemplified below], you can easily update the code to avoid some gotchas.

This is what I consider a loosely defined link_to:

link_to 'Destroy', some_record, :confirm => 'Are you sure?', :method => :delete

It lacks parentheses, option grouping, and most importantly, expects the helpers to generate a specific kind of link (in this case a destroy action) from just the record itself. Now, rails is pretty smart these days and will probably generate the correct link without a hiccup if your app isn’t employing a custom RAILS_RELATIVE_URL_ROOT, or setting skip_relative_url_root => false.

Well, my latest app is. And this is how that loosely defined link_to renders:

ArgumentError in Controller#action
wrong number of arguments (0 for 1)

The stack trace will provide evidence that some thing’s a mess in url_for related to the default_url_options, defined in application.rb (or elsewhere). Rails’ helpers cannot correctly produce a url due to lazy linking.

So, make your code more readable and keep the helpers happy and define your link_to’s like this:

link_to ( 'Destroy', record_path(some_record), :confirm => 'Are you sure?', :method => :delete )

Refresh that error page and voila! Happy links again! Stricter coders may even group the options with curlies, and that doesn’t hurt either.

I am definitely excited about that change and look forward to updating tables with the utmost ease. Along with this great update, migrations are now automatically generated with a timestamp as their version number instead of simply an integer. What this means to the solo developer is more information given at a glance than just the migration order (not too useful). What it means as a team developer is little to no worries of colliding migration versions with others on your team. Additionally, a schema_migrations table is created in your database which tells you what migrations have been run so far, which is more useful than the schema_info table which is just the latest migration version. Those of you who hate reconciling migrations with other developers rejoice.

For more on these updates, click on over to Railscasts, since I shamelessly stole an image of their screencast anyway.

What might go wrong when you update your own app, you might wonder?

In most cases there are no complications, unless you already have a migration up to version 20080605122345 [YMMV on the timestamp]. This is NOT ok if you’re setting the time and date of “right now” in the application. For example, the date of present time is set to midnight, May 15th, 2007 in an app I’m currently working on for development and testing purposes. This means my new migrations (ALL of them) are given the same version of 20070515000000_…. and this is bad news. I am hunting around for a way to tell the generator to use simple version numbers instead and I will report back when said way is found.

1. Choose a model that has_many :things, :through => :something_else, and also uses the will_paginate gem somewhere
2. open up your console
3. Model.find(:first).things #=> all your things
4. Model.find(:first).things.collect(&:id)

#=> SystemStackError: stack level too deep
from /usr/lib/ruby/gems/1.8/gems/will_paginate-2.1.0/lib/will_paginate/finder.rb:139:in `method_missing_without_paginate’
from /usr/lib/ruby/gems/1.8/gems/will_paginate-2.1.0/lib/will_paginate/finder.rb:139:in `method_missing’
from (irb):3

This problem was referenced in this post and the solution is contained therein.

I uninstalled the will_paginate gem and installed the “mislav-will_paginate” gem from http://gems.github.com.
To install it yourself just use:

sudo gem uninstall will_paginate
sudo gem install mislav-will_paginate
--source=http://gems.github.com


Go back into your console and try it out, then make sure you restart your server for the changes to make it to your app.

Hopefully this helps some of you who are jumping on the latest rails releases, especially after RailsConf just got everyone excited.