Hi,
Playing with auto complete in Firefox is fun all the time , but this is not going to be same in Others Browsers(IE & Safari),
after Googling for many days i came up with a pleasant solution.
Rails2.0: auto_complete is now a plugin (it’s not in the core anymore), you will install it before using it:
script/plugin install auto_complete
Somewhere in your views you’ll want code somewhat like the following.
<%= text_field_with_auto_complete :article, :contains, { :size => 15 }, :skip_style => true %>
I specified a size for the text area with the :size => 15 values in the hash. I also included :skip_style => true which keeps the helper from automatically inlining CSS styles into the page.
and now the major issue i faced with IE and Safari browsers are :
Q. Up, Down arrow keys are not working for auto complete in non-mozilla browsers when drop down list appears
The solution is ..
This is due to a bug in Scriptaculous. At the time of writing you will need to apply the following patch that will fix it:
in controls.js around line 86 you will observe these lines
Element.hide(this.update);
Event.observe(this.element, 'blur', this.onBlur.bindAsEventListener(this));
Event.observe(this.element, 'keydown', this.onKeyPress.bindAsEventListener(this));
},
and now you modify above lines with the following code of lines :
Element.hide(this.update);
Event.observe(this.element, 'blur', this.onBlur.bindAsEventListener(this));
Event.observe(this.element, 'keypress', this.onKeyPress.bindAsEventListener(this));
// Observe keydown for non-Mozilla browsers per http://dev.rubyonrails.org/ticket/10126
if (Prototype.Browser.Gecko) {
Event.observe(this.element, 'keypress', this.onKeyPress.bindAsEventListener(this));
} else {
Event.observe(this.element, 'keydown', this.onKeyPress.bindAsEventListener(this));
}
},
and restart the server ,now the arrow keys will work in both IE and Safari browsers.
Sunday, September 28, 2008
Wednesday, September 24, 2008
improving performance with :select in rails
For newbies, rails is amazing. With its constituent modules such as active-record, action-pack, action-mailer etc.. acting behind the scenes, rails provides a lot of abstraction to the developers making things more simpler. Given this simplicity through abstraction, there follow some issues which may degrade your application performance when not taken care of properly.
Let's have a look at Active Record. It is Active Record that makes people go crazy about rails. It shoulders the responsibility of database operations for the users providing them with different flavours of methods to deal with. But there are some pitfalls to consider:
1. The default 'find' method fetches all columns from a table row:
Active Record works at the row level but not at the column level. Consider a table "employees" having emp_id, emp_name, emp_slary, emp_address and etc.. upto 50 columns. When you want to make a detailed list of all the employess, you may tend to write
@employees = Employee.find(:all).
The above statement fetches all the fifty columns of every single employee from the table and converts it as Employee objects. What if you need only a set of columns(say emp_id, emp_name, emp_slary, emp_address) but not all. Now you can achieve this using :select option in the find method
@employees = Employee.find(:all, :select => ['emp_id', 'emp_name', 'emp_slary',
'emp_address'])
What this does is select only the specified columns from the table and converts it into Employee objects. Accessing unspecified attributes from the resultant Employee objects may reult in an Error/Exception, but saves a lot of overhead in selecting all the columns and turning the rows into heavy objects.
Another case may be an articles table. Though it may seem to contain less number of columns, one tends to use a column for article body which may contain text as well as images(usually these type of columns are set to BLOB type). Here also, to make a list of all the articles, you can write
@articles = Article.find(:all, :select => ['article_id', 'article_title', 'author_name',
'published_date'])
and avoid the body column if you feel not needed.You are free to use all the other options along with :select.
2. Eagerloaded associations that contain heavy data:
class Author < ActiveRecord::Base
has_many :articles
end
class Article < ActiveRecord::Base
belongs_to :author
has_many :comments
end
class Comment < ActiveRecord::Base
belongs_to :article
end
Assuming that you know how to eagerload associated models using :include option , lets look at how we can finegrain the eagerloaded models using the :select option with :include.
@author = Author.find(:id, :include => [:articles])
This fetches an author's record and all the article records that belong to this author. But how to avoid fetching the heavy 'body' column from articles table. Can we use the :select to fetch only the desired columns from the associated model through :include ? This is not possible because eagerloading generates SELECT statement too, the use of :select together with :include is not supported . This can be achieved with a bit of extra code:
Download the patch from http://dev.rubyonrails.org/attachment/ticket/7147/init.5.rb submitted by mrj to Rails Trac.
Place this file in your lib directory and require it in environment.rb. For ex, if the file is named 'include_with_select.rb' in your lib, you can write in your environment.rb as:
require 'include_with_select'.
With this setup, you can freely select the desired columns in the :included associations as:
@author = Author.find(:id, :include => [:articles[:article_id, :article_title, :author_name, :published_date]])
If you want to eagerload a set of comment attributes for every article, you can write it as:
@author = Author.find(:id, :include => [{:articles[:article_id, :article_title, :author_name, :published_date] => :comments[:comment_text, :comment_by]}])
This way we can achieve a better performance using :select with/without :include.
Let's have a look at Active Record. It is Active Record that makes people go crazy about rails. It shoulders the responsibility of database operations for the users providing them with different flavours of methods to deal with. But there are some pitfalls to consider:
1. The default 'find' method fetches all columns from a table row:
Active Record works at the row level but not at the column level. Consider a table "employees" having emp_id, emp_name, emp_slary, emp_address and etc.. upto 50 columns. When you want to make a detailed list of all the employess, you may tend to write
@employees = Employee.find(:all).
The above statement fetches all the fifty columns of every single employee from the table and converts it as Employee objects. What if you need only a set of columns(say emp_id, emp_name, emp_slary, emp_address) but not all. Now you can achieve this using :select option in the find method
@employees = Employee.find(:all, :select => ['emp_id', 'emp_name', 'emp_slary',
'emp_address'])
What this does is select only the specified columns from the table and converts it into Employee objects. Accessing unspecified attributes from the resultant Employee objects may reult in an Error/Exception, but saves a lot of overhead in selecting all the columns and turning the rows into heavy objects.
Another case may be an articles table. Though it may seem to contain less number of columns, one tends to use a column for article body which may contain text as well as images(usually these type of columns are set to BLOB type). Here also, to make a list of all the articles, you can write
@articles = Article.find(:all, :select => ['article_id', 'article_title', 'author_name',
'published_date'])
and avoid the body column if you feel not needed.You are free to use all the other options along with :select.
2. Eagerloaded associations that contain heavy data:
class Author < ActiveRecord::Base
has_many :articles
end
class Article < ActiveRecord::Base
belongs_to :author
has_many :comments
end
class Comment < ActiveRecord::Base
belongs_to :article
end
Assuming that you know how to eagerload associated models using :include option , lets look at how we can finegrain the eagerloaded models using the :select option with :include.
@author = Author.find(:id, :include => [:articles])
This fetches an author's record and all the article records that belong to this author. But how to avoid fetching the heavy 'body' column from articles table. Can we use the :select to fetch only the desired columns from the associated model through :include ? This is not possible because eagerloading generates SELECT statement too, the use of :select together with :include is not supported . This can be achieved with a bit of extra code:
Download the patch from http://dev.rubyonrails.org/attachment/ticket/7147/init.5.rb submitted by mrj to Rails Trac.
Place this file in your lib directory and require it in environment.rb. For ex, if the file is named 'include_with_select.rb' in your lib, you can write in your environment.rb as:
require 'include_with_select'.
With this setup, you can freely select the desired columns in the :included associations as:
@author = Author.find(:id, :include => [:articles[:article_id, :article_title, :author_name, :published_date]])
If you want to eagerload a set of comment attributes for every article, you can write it as:
@author = Author.find(:id, :include => [{:articles[:article_id, :article_title, :author_name, :published_date] => :comments[:comment_text, :comment_by]}])
This way we can achieve a better performance using :select with/without :include.
Thursday, September 18, 2008
have you ever measured your rails application performance?
Well, you have been developing rails applications for over a year or couple. You did every bit of it The Rails Way keeping it DRY, writing migrations, associating your models and built-in test cases. The app seems to work great on your local machine. But are you sure it does on the production server? Have you ever used any profiling or benchmarking tools to measure the performance of the apps? If not its time to use one and make sure your apps run faster not only during development but also in the production environment.
As there are many such tools that serve the purpose, the two head-to-head competitors, RPM from new relic and Five Runs from fiveruns , which are strongly backing the Rails framework to become enterprise ready, make a good choice.
Given the task to finetune a rails app, I preferred relic over fiveruns as it is very easy to get going. RPM Lite, a standard version of RPM is free as long as you want and you can always upgrade it to enjoy more featues. For a developer use, RPM Lite is enough.
RPM Lite is available as a plugin. I got the plug-in installation link through subscription at new relic, installed it and restarted my server.
Note: The plug-in installation creates a config/newrelic.yml file. I didn't pay much attention to it. But it may contain some interesting configuration.
Now, whenever I made a request to the server, the relic plugin monitored my request and measured the time for processing my request. This is available at http://localhost:3000/newrelic.
Amazingly, relic tracked my request right from the controller to the model to the view.
1. It gave me an analysis of time spent in the controller, the model/db calls executed and to
render the results to my view to an accuracy of milli seconds.
2. It also produced a pie-chart of the processes involved.
3. It provided me with an sql view, where I could track the sql executed.
4. Number of such requests that could be server per second.
5. It also tracked AJAX requests.
From the analysis, I learnt that the app is spending most of the timein DB calls which I eventually reduced.
This way, I could make a better use of RPM and finetuned the app resulting in a notable performance boost. So, why not give it a try right now. I hope RPM will serve the purpose for you too.
As there are many such tools that serve the purpose, the two head-to-head competitors, RPM from new relic and Five Runs from fiveruns , which are strongly backing the Rails framework to become enterprise ready, make a good choice.
Given the task to finetune a rails app, I preferred relic over fiveruns as it is very easy to get going. RPM Lite, a standard version of RPM is free as long as you want and you can always upgrade it to enjoy more featues. For a developer use, RPM Lite is enough.
RPM Lite is available as a plugin. I got the plug-in installation link through subscription at new relic, installed it and restarted my server.
Note: The plug-in installation creates a config/newrelic.yml file. I didn't pay much attention to it. But it may contain some interesting configuration.
Now, whenever I made a request to the server, the relic plugin monitored my request and measured the time for processing my request. This is available at http://localhost:3000/newrelic.
Amazingly, relic tracked my request right from the controller to the model to the view.
1. It gave me an analysis of time spent in the controller, the model/db calls executed and to
render the results to my view to an accuracy of milli seconds.
2. It also produced a pie-chart of the processes involved.
3. It provided me with an sql view, where I could track the sql executed.
4. Number of such requests that could be server per second.
5. It also tracked AJAX requests.
From the analysis, I learnt that the app is spending most of the timein DB calls which I eventually reduced.
This way, I could make a better use of RPM and finetuned the app resulting in a notable performance boost. So, why not give it a try right now. I hope RPM will serve the purpose for you too.
Subscribe to:
Posts (Atom)