| 89 | | class names to name its associations in report tables. It now looks up |
|---|
| 90 | | the proper association name through reflection. This will break any old |
|---|
| 91 | | code that relied on the earlier convention, but eliminates ambiguity |
|---|
| 92 | | issues. |
|---|
| 93 | | </p> |
|---|
| 94 | | |
|---|
| 95 | | <p> |
|---|
| 96 | | <i>(**NOTE:** Mike, please change as needed and add an example)</i> |
|---|
| | 89 | class names to name its associations in report tables. It now uses |
|---|
| | 90 | the proper association name to qualify attribute names. This will |
|---|
| | 91 | break any old code that relied on the earlier convention, but eliminates |
|---|
| | 92 | ambiguity issues. |
|---|
| | 93 | </p> |
|---|
| | 94 | |
|---|
| | 95 | <p> |
|---|
| | 96 | For example, say you had two models, Customer and CustomerAddress |
|---|
| | 97 | defined as follows: |
|---|
| | 98 | </p> |
|---|
| | 99 | |
|---|
| | 100 | <pre> |
|---|
| | 101 | class Customer |
|---|
| | 102 | has_many :addresses, :class_name => "CustomerAddress" |
|---|
| | 103 | end |
|---|
| | 104 | |
|---|
| | 105 | class CustomerAddress |
|---|
| | 106 | belongs_to :customer |
|---|
| | 107 | end |
|---|
| | 108 | </pre> |
|---|
| | 109 | |
|---|
| | 110 | <p>If you do:</p> |
|---|
| | 111 | |
|---|
| | 112 | <pre> |
|---|
| | 113 | Customer.report_table(:all, :include => :addresses) |
|---|
| | 114 | </pre> |
|---|
| | 115 | |
|---|
| | 116 | <p> |
|---|
| | 117 | Previously, the columns from CustomerAddress would have been qualified as |
|---|
| | 118 | customer_address.attribute_name whereas now, they would be |
|---|
| | 119 | addresses.attribute_name |
|---|