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

[AppleII717]

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

[radhames brito]

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

[Marnen Laibow-Koser]

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
mar...@marnen.org
--
Posted via http://www.ruby-forum.com/.

[radhames brito]

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

[Marnen Laibow-Koser]

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

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.

[radhames brito]

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.

--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To post to this group, send email to rubyonra...@googlegroups.com.
To unsubscribe from this group, send email to rubyonrails-ta...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.