STI, xml/xslt, or ? for many custom forms/templates

rubyonrails-talk
1

I'm considering porting an application to RoR. The application is basically a "Order Entry" type system for the Interior Designer vertical market. The existing application has a table with over 400 column! (not my design!). The majority of these columns are measurements and descriptions for a certain types of product categories (e.g., "Draperies","Sheer Draperies", "Upholstery","Pillows","Lampshades", etc)

Each one of these categories (25+) has a custom form that display the measurement attributes for that category. To make things worse, there's a lot of javascript that enables/disables/shows/hides areas/ fields. There is some sharing of attributes (width, height, length, size, for example). I can cut down the javascript by creating more categories - for instance there are 3 types of "Sheer Draperies".

I alway though that these "Category Details" didn't need to be stored individually in a record, but serialized in a "Details" fields. Now the basic question is what would be the best approach?

I've never done xml/xslt type forms and don't know how difficult that would be.

I've experimented with what could be considered "Tableless STI" and it works, but with a few gotcha's. For instance:

class Detail < ActiveRecord::Base   def self.columns     @columns ||= ;   end ... rest of tableless stuff   #common attributes   column :type, :string   column :category, :string   column :workroom_material_reference, :text   column :description, :string   .... end

class Carpet < Detail   column :style, :string   column :quanity, :integer   column :yards, :float end

The tableless approach would not allow me to create a new Carpet without first doing Detail.new. There were other problems that I hacked around, like defining def self.new_category(category) that creates new ActiveRecord objects for both the basic attributes and the category attributes. Maybe if I used a real table, some of those problems would go away.

That approach is livable, but was wondering if I am totally missing a better approach?

Anyway, I know I am still going to have a couple hundred date elements to deal with and a bunch of partials.

Anyone want to point me in a different direction?

Steve Alex

2

if i were you i would back up my db and create migration to move everything to different tables. In fact you could do a rake task for that.

desc “Fixing that crapping design” task :fix_the_fail => :environment do crappy_table = “crappy_table_name” new_tables = [“table1”,“table2”,“table3”…etc] category_a = [“Draperies_name”,“date”,“workroom_material_reference”…etc] category_b = [“Upholstery_name”,“date”,“workroom_material_reference”…etc] category_c = [“Lampshades_name”,“date”,“workroom_material_reference”…etc] category_d = [“name”,“date”,“workroom_material_reference”…etc] categories = [ category_a,category_b,category_c,category_d] ActiveRecord::Base.establish_connection i=0 ActiveRecord::Base.connection.tables.each do |table_name|
if new_table.include? table_name
data = ActiveRecord::Base.connection.insert(insert into table_name categories[0] values (select categories[0] % crappy_table) i++ end end end end

something like that and just forget about everything before that

3

radhames brito wrote:

if i were you i would back up my db and create migration to move everything to different tables. In fact you could do a rake task for that.

But you shouldn't. No schema change should ever be done without a migration.

Best,

4

he would first create the appropriate tables with a migrations, if you look at the rake that i gave is does not create any tables, i suggest he adds them first then move everything with a migration or a task

5

PLEASE QUOTE WHEN REPLYING! How many times must I say this?

radhames brito wrote:

he would first create the appropriate tables with a migrations, if you look at the rake that i gave is does not create any tables, i suggest he adds them first then move everything with a migration or a task

Unnecessary. The migration should contain everything that is necessary to both create the schema and fit the data into the new schema. The whole point of migrations is that each migration contains everything that is necessary to bring the database from one consistent state to another.

Best,

6

well ok , he can use a migration then is not like the logic is very different , he just has to move the connection related code.