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

Rails
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 A.

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,

Marnen Laibow-Koser
http://www.marnen.org
[email protected]

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

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.

On Mon, Sep 27, 2010 at 3:29 PM, Marnen Laibow-Koser

6

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,

Marnen Laibow-Koser
http://www.marnen.org
[email protected]