Topic: Dynamic Controls on a Page

Moderator: I'm not sure if this is the right forum... moving is fine w/me...
.Net'er stepping into RoR using Eclipse Indigo IDE, (Worked a bit'o Android)

In my .Net days (day before yesterday) I would often load a page and display by default certain controls depending on an enum value passed into a function Display_Control(byval e as myAppenum).

Each time an action occurs, Display_Control controls which pannels (div)'s and other html controls render/are visable.

So say when a user enters a new record, certain contact data fields are shown, an ajax lookup is performed once the basic contact info is entered to not enter a dup, then when the user chooses the type of contact certain controls are rendered, for example: type of insurance, sale or rental, B2B or customer.

Then at post/submit, I use the .Net findcontrol to loop through to get the current controlname values NV collection, skipping invalid default values based on the ennum, then w/the enum and the NV collection I get my form ID which passes that to an API which will loop & map my NV values to an insert that includes the database & table names; the form ID ensures that only valid fields & values are inserted, any invalid NV's from the page are ignored, can be logged or messaged back to the user if need be. In other words the page/form displays dynamic fields yet the final data insert is fool proof.

Making new forms/pages is easy add any controls to the new page, load the page ID, NV list & database & table names into a table called control.  For enterprise I break the API to a webservice to be consumed by multiple web applications.

table: control
fields: recid, formID, HTMLFieldName, dbFieldName, dbFieldType, createdate, createby, active

Gosh, that was long, sorry folks, my big Q's are...
Assuming that only certain controls conditionally render, how would Ruby find the rendered html controls?
Followup - And do an insert into certain tables & fields found at run time?

Re: Dynamic Controls on a Page

Welcome to a whole new world

First,  get your database setup by editing config/database.yml.  Tell Rails how to access your database,  tell it which database system you are using,  the login and password, and the database to use.  Once you have told the rails app how to get to the database, Rails conventions take over.

When Rails knows about your database,  Rails will interrogate the database when it boots.  For example,  say you've manually configured the database via SQL command line,  and you've created a table called 'things'.  Now you want to make your Rails app aware of this table.  You'd do that by declaring a model Thing.  That is the first convention you've come across,  a table with the name things has a model called Thing.  So if you create this file:


class Thing < ActiveRecord::Base

Rails conventions takes over.  Rails will assume there is a table in the database called 'things'.  So now, after making this model declaration,  the table and ALL it's columns (attributes) are available to you.  You can now to something like this in a controller:

@thing = Thing.find(:id=>1)
name =

If your table has an column called 'name',  the above code will just work,  because Rails will discover the fact that your table things has a column field 'name'.

There is a second convention shown above,  models are identified by a column called id.  If you use Rails Migrations to create your tables,  migrations will take care to set up the id column,  if you set up the tables yourself,  you have to know the convention that id is a column of type integer that is a unique identifier for the table and is an auto increment.

Now say you add a column to the table things.  However you do it, if you reboot the Rails app,  the new field will be known to the Rails app without any further intervention by you.  If you add an address field to the table 'things',  and reboot the rails app,  the following code just works

@thing = Thing.find(:id=>1)
name =
address = @thing.address

So now you understand the 'auto discover' aspect of Rails, you can leverage that feature with scaffolds.  Scaffolding is a way of generating a bunch of code based on the table.

Let me know if your are following this,  and I'll respond further.

Joe got a job, on the day shift, at the Utility Muffin Research Kitchen, arrogantly twisting the sterile canvas snout of a fully charged icing anointment utensil.

Re: Dynamic Controls on a Page

I'm following you, and working w/the gettingstarted tutorial I kinda figured that out looking at the logs & seeing the sql queries, and I do get the model thing, sort'a like a token for the table things as the table.

It is weird, in that I'm relinquishing control & obligation to manage that control for query'ing the db; part of my issue w/the New World is that often my apps are reused for client(s) different purposes, so a data entry app at one client works at another; I just update the entries in the database for the control labels for html_field01, mapto fName formid = 12, label First Name, html_field02, mapto lName, formid = 12, label Last Name. When the form renders I see the new lables, when it posts I build a list of htmlfield names of mapto name & values by my formid = 12, then the insert does a lookup on the target table schema only, and finds matches extras are ignored and an insert statement is dynamically built, it's quite a bit of code, but it's write once & re-use.

I've got a bug in GettingStarted blog... I'm not sure how to debug, but I'm looking at the logs... wish me luck, I'm off to post in GettingStarted (I think there's a forum for that(?))...

Re: Dynamic Controls on a Page

You never really relinquish control.  Rails typically just relieves you of the tedium,  but if what Rails does isn't right,  you still have control to make it do exactly what you want.  What Rails is so good at is getting stuff up and running in a generic way with VERY minimal effort.  But you're NEVER restricted to accepting the Rails default behavior.

All Rails database introspection does is eliminate the need to define database attributes to your app.  Designing forms for editing those attributes can be automated,  but typically,  you always refine/replace the boilerplate stuff with the more specific stuff you really want.

Joe got a job, on the day shift, at the Utility Muffin Research Kitchen, arrogantly twisting the sterile canvas snout of a fully charged icing anointment utensil.