When doing validation, try to use getElementById instead of using the DOM hierarchy to access form items. Firefox and IE responded well to input form items but not drop down menu’s. For example: firefox will pick up document.myForm.dropdown.selectedIndex but IE won’t. Solution? Use getElementById(“dropdown”).selectedIndex
<form name=”myForm”>
<select id=”dropdown” name=”dob” type=”list”>
<option>01</option>
<option>02</option>
</select>
</form>
So apparently, whenever you launch a rails application in production mode a copy of your app is actually used. So any changes that you make are not seen on the other side until you restart the web server. . . It was very frustrating figuring this one out.
I’ve conceided to using the in place design for storing personalized data by using property_type table and properties table. I did so manually in the property_type table and also in the property table. I added a subcategory (Basic, Personal, Work, and Education). Within Basic, I added attributes (Interest In, Relationship, Status, Looking For, Political View, Religious View). Within Personal I added attributes (Activities, Fav Music, Fav Movies, Fav Books, Fav Quotes, Fav TV Show, About Me, and Interests). Within Work I added attributes (Employer, Position, Description, Time Period). And Within Work I added attributes (School, Concentration, Start Year, End Year).
Manual personalized field mysql inserts:
insert into property_types (parent_id, title, short_name, description, is_global, order_by) values (98, “Time Period”, “emp_time”, “Work Time Period”, 1, 102);
insert into properties (user_id, property_type_id, value, created_at, updated_at) values (9, 102, “Now”, NOW(), NOW());
Now to add these property_types into all the rest of the users into the properties table. Fire up the development console (ruby script/console)
First to list all of the new property_type id’s
myPropertyTypes =[69,80,81,82,83,94,85,86,87,88,89,90,91,93,95,96,97,99,100,101,102]
Then walk through the user list and associate each property_type to each user.
User.find(:all).each { |usr|
myPropertyTypes.each { |pt|
tmp = usr.properties.create(:user_id => usr.id, :property_type_id => pt, :created_at => Time.now, :updated_at => Time.now)
tmp.save
}
}
As I walk through facebook extracting any bit of useful features for my integration of a social network into a openid server I found myself creating modular tables containing different bits of personalized data. For example, Within a person’s profile you have several different categories (basic, contact, personal, education, courses, and pictures) separated by tabs and within each tab you have several different attributes to describe that tab/category. In my mind, I created a separate table for each tab/category and table columns for each attribute within that tab/category table. In addition, instead of linking the five or six tables back to the user, I would create an associative table containing the id’s of five or six tab/category tables and tie that associative table’s column id to the user. This way, I keep the user table clean and decouple the user from its page front data. In essence, I am categorizing and organizing data through tables.
But… some of the categorized data is already being stored by the openid server. So how is it storing its data. As it turns out. Within the “My Profile” tab of the openid server by east media are different sets of property categories (personal, contact, addresses, and links). Within each category are different sub categories and or attributes that you can change. You may also dynamically create and populate categories, subcategories, and attributes. But these categories, subcategories, and attributes are stored in a flat table with a table column, parent_id, to categorize and organize data.
More specific, in the table “property”, there is a single tuple called “root” that is the parent of all categories/subcategories/and attributes. From root, there are 4 categories, (personal, address, contact, and link) that have a parent_id linking it back to root. All attributes of personal, address, etc, have parent_id’s linking them back to its corresponding category. In essence, the data is being categorized and organized by table attributes.
So what to do? Do I add more attributes to the property table and pollute the properties table even more so AND make the mapping of users to properties table ridiculously large? OR use my design and rewrite how data should have been stored in the database.
Getting back into it 