Author Archive

Flex 3: Styling Individual Tabs in a TabBar

Monday, November 10th, 2008 by Glenn Gentzke

There are a few ways to style the tabs in a TabBar that are fairly well hidden. Here are a couple methods that hopefully save some time for those of you out there looking to apply advanced styles tabs in Flex.

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!

Using ActiveRecord’s to_xml to produce custom xml including deep level associations

Wednesday, September 10th, 2008 by Glenn Gentzke

ActiveRecord provides a powerful method to all its records called to_xml. Most web developers using RoR should be familiar with its usage and hopefully use it for their simple xml production needs. But what do you do when you need to produce xml that is selective, includes associations, or contains custom tags? There are many ways to manipulate to_xml’s output and I’ll explain a few below.
(more…)

Loosely defined link_to may cause problems when overriding url_helper

Tuesday, August 26th, 2008 by Glenn Gentzke

OR “Beware of pick pockets and loose link_to’s”

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.

Sexier Migrations in Rails 2.1

Thursday, June 5th, 2008 by Glenn Gentzke

If you thought migrations couldn’t get any sexier, then clearly you haven’t been following the mudslide of updates going on in Rails this year. As of late I’ve been updating tables in almost every way possible in several applications. From simply renaming columns to renaming entire tables and their dozens of loyal has_many’s, I’ve gotten used to the old way to change tables, but I certainly haven’t enjoyed it. Behold, migrations in 2.1 now allow you to do this:

screenshot shamelessly stolen from railscast

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.

Error in will_paginate gem running Rails 2.1.0

Tuesday, June 3rd, 2008 by Glenn Gentzke

I encountered some unexpected errors immediately after upgrading to Rails 2.1.0 from 2.0.2. To replicate the problem:

  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.