Reported by jcoglan, 06/04/07 11:07:42:

Element.getStyle() for width and height is inconsistent between Mozilla and IE and Opera. Mozilla returns the width according to the box model, whereas IE (6 and 7) and Opera include padding and borders in the result. We have getWidth() and getHeight() for the latter, so I think getStyle() should return the box model value in all browsers.

I'm including a patch that achieves this, as long as the padding/borders are in px or ems and the font size is set in px. It adds a computeAutoSize() method to Element.Methods that the modified copies of getStyle() for IE and Opera can use.

Is there an element property in IE that returns what I'm after? If not, this patch will need a little hacking to accommodate more sizing scenarios.

Reported by jcoglan, 06/14/07 09:18:08:

Not sure if this is deliberate... I've written some code that wraps the tag method and including it in ActionView::Helpers::TagHelper works fine. Including it in ActionView::Helpers::InstanceTag breaks because it has a different number of arguments (it's missing the third argument, open). Should the methods be consistent?

Reported by jcoglan, 07/11/07 09:57:29:

Calling find on a HABTM-scoped collection returns incorrect results under some circumstances if there are duplicate links in the database. I've set :uniq => true on the relationship between Post and Category and written some test cases to demonstrate. In the patch, the second and fifth tests are the ones that fail, i.e.

# Returns duplicate results
category.posts.find(:all)

# Returns too few results as uniqueness is imposed in Ruby after the results
# come back from the DB, rather than being enforced by the DB query
category.posts.find(:all, :limit => 2, :include => :author_with_posts)

I've been trying to work around this in my project and I'm going round in circles trying to get both eager loading and result set size to work correctly. I'm not sure that the first example is really a bug, as the find is pretty much redundant and could be useful if you actually want to pull out duplicates from the DB. The second example is infuriating though.

Reported by jcoglan, 08/01/07 15:37:01:

ActiveRecord::Associations::ClassMethods#construct_finder_sql_with_included_associations does not pass the options hash to column_aliases, which has no idea which columns you wanted if you were using the :select option. This patch fixes the issue and is compatible with all current tests. It works as follows:

• Allows column_aliases to accept an options hash.
• Parses the :select option into an array of column names (select_columns) and table names (select_tables)
• In the loop of column_alias, check each column. Only add it to the SQL if select_columns contains the column name, or if it contains something like table_name.* for the column's table, or if select_tables does NOT contain the column's table - so anything required by a :joins or :include directive will be loaded, unless :select places retrictions on the tables involved.

I'm not sure how to add tests for this - where in the test suite is SQL explicitly checked? All I know is it doesn't break anything and it works in the app I'm building.

Reported by jcoglan, 08/30/07 12:40:39:

Let's say you want to find the sum of the prices of a bunch of products in your database, and the criteria used for selecting products involve using :include to bring in associated tables. Those LEFT OUTER JOIN statements may result in the base record (Product) being duplicated for every association found. e.g. if product number 1 has three comments associated with it, then Product.sum(:price, :include => :comments, :conditions => ...) will include product number 1 in three rows of the SQL result set. I only want its price added to the sum once, but I can't use the :distinct option because the prices I'm adding up aren't necessarily unique.

This patch adds a :distinct_records option to ActiveRecord::Calculations::ClassMethods#calculate, which replaces the table name in the SQL query with another SQL SELECT query to find a distinct set of records to be summed. I've included a couple tests to illustrate the effect, and I've run this under MySQL. I'm not sure whether all other DBs support this syntax so the patch may need work.

Reported by jcoglan, 09/06/07 00:54:45:

In some cases, you need to grab several COUNTs, SUMs etc from the database, and it speeds things along if you can get them all in one query. This patch provides a simple way to achieve this through ActiveRecord::Base.calculate. For example:

Person.calculate(:how_many => [:count, '*'], :total_age => [:sum, :age])
#=> {:how_many => 12, :total_age => 387}

Person.calculate({:how_many => [:count, '*'], :total_age => [:sum, :age]},
    :conditions => ['age < ?', 30])
#=> {:how_many => 7, :total_age => 94}

The results are fetched using one query only, rather than a separate query for each quantity. I've found this tremendously useful for generating reports from large data sets.

I've included documentation and a few tests, which run fine under MySQL. Testing with other DBs would be appreciated.

Reported by jcoglan, 09/20/07 17:38:00:

For the sake of cleaning up my code, I'd really like to see the Enumerable#pluck idea extended to many other methods a-la Symbol#to_proc in Ruby. That way I can write things like...

var checked = someRadioBottons.findAll('checked');
var minimum = myInputs.min('value');
var groups = objects.partition('validated');

This patch allows you to do that, and it even works with methods, so you can do:

var elements = $$('div').findAll('visible');

It works by adding a String#toFunction method, and adding a check for that method to many functions in Enumerable. I know this would clean up some of my code considerably. Not sure if I've missed any methods where it might be useful, but I've included tests for all the methods I've patched.

Reported by jcoglan, 09/25/07 16:24:19:

This patch adds a nested_set_list helper method to acts_as_nested_set, which produces a nested HTML list when given a collection of records from a nested set model. See the docs in the patch for a full example.