Hello all, I am a rails nuby and I am evaluating using Rails for a new web application. The application will have a large number of tables (>70) that will basically mimic a large collection of paper forms that user would otherwise have to fill out. From what I have read on rails thus far it seems I would have to create a lot of models and form templates. Is this common and if so does anyone have any suggestions of efficient ways to do this? There is one catch, the forms need to be able to display their labels in more that one language. Thanks peer
on 2006-03-28 04:24
on 2006-03-28 04:58
On Tue, Mar 28, 2006 at 04:24:49AM +0200, Peer Allan wrote: } I am a rails nuby and I am evaluating using Rails for a new web } application. The application will have a large number of tables (>70) } that will basically mimic a large collection of paper forms that user } would otherwise have to fill out. From what I have read on rails thus } far it seems I would have to create a lot of models and form templates. } Is this common and if so does anyone have any suggestions of efficient } ways to do this? It sounds like each table will correspond to a single form. This is pretty much ideal for scaffolding. You should be able to generate basic models, controllers, and views for the forms with script/generate scaffold. You may want to tweak the views and validation and such, but that is to be expected. It sounds like scaffolding will be a very useful start for you, however. } There is one catch, the forms need to be able to display their labels in } more that one language. When the scaffolding is generated, assuming config/database.yml has the proper configuration and the database exists, a _form.rhtml file will be generated (for each model) which uses label tags. I recommend creating a label helper method that will give the desired label based on the appropriate language and the label identifier. Then run the following on each _form.rhtml to replace the label tags as they exist with invocations of the label helper method: sed -i 's,<label for="\([^"]*\)">[^<]*</label>,<%= label :\1 %>,g' _form.rhtml } Thanks } peer --Greg
on 2006-03-28 06:21
I'm trying to create a table AND create a row in my migration. I'm having trouble with the creating a row part (the line Planet.create below): file: db/migrate/001_first_table.rb class FirstTable < ActiveRecord::Migration def self.up create_table :planets do |t| t.column :name, :string end Planet.create(:name => "Earth") end def self.down drop_table :planets end end rake migrate => rake aborted!, uninitialized constant Planet I'm getting this error on Rails 1.0 and edge 4068
on 2006-03-28 06:25
planet = Planet.new(:name => "Earth") planet.save
on 2006-03-28 06:30
oh, I think you'll need to create a model as well.
on 2006-03-28 06:44
>oh, I think you'll need to create a model as well. Oh that helped, thanks ... can you tell I haven't done this much yet ;-) I think maybe the scaffold I used before made the model ... and checking this page: http://wiki.rubyonrails.org/rails/pages/UsingMigrations didn't remind me to make the model.
on 2006-03-28 09:03
Peer Allan wrote: > There is one catch, the forms need to be able to display their labels in > more that one language. I know others have suggested the model-per-form route, and that's probably the simplest route, but you may want to take a look at the processes that the forms fit into, to see if there are simpler domain models that you could take advantage. For instance, if forms A, B and C contain different information, but always need to be filled out sequentially (for instance, by different people) as part of the same process, then you could use a single model to represent that process. You'd still need the separate templates, of course, but you'd gain a much simpler workflow system. Just another idea for the melting pot...
on 2006-03-28 14:23
Alex Young wrote: > > Just another idea for the melting pot... Every idea is welcome! This kind of approach is one I was curious about. It seemed excessive to me that I would have to create 70+ controllers, one for each form, when most of the forms function in a similar way. I can understand having to make that many models due to validation issues. Does anyone find it hard to maintain an app with so many files? Peer
on 2006-03-28 14:40
> This kind of approach is one I was curious about. It seemed excessive > to me that I would have to create 70+ controllers, one for each form, > when most of the forms function in a similar way. I can understand > having to make that many models due to validation issues. if theyre all forms, you proabbly want to be thinking more along the lines of a FormTemplate and FormFields class, and making a GUI editor so that you can design the forms from the interface, rather than writing model code for each. you could even scratch the FormTemplate class and just have the templates be tagged instances of a normal Form..and clone their state. if you have a lot of complex interrelationships between the forms, and want to start thining about refactoring your business without having to also think about refactoring your app, i'd suggest checking out DabbleDB. theres no reason good chunks of Rails like ActiveRecord, Migrations, RJS, and addons like Markaby and the AJAX scaffold generator couldnt be plundered to create something like this, but the current assumption is that the model is static and defined at server launch time..