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

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

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

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,

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

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,

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.