Rails - Nov 2005 - RE: Why class InstanceTag is defined at 4 different places inRails

In Ruby you can add and modify existing classes at will simply by
reopening it. The 4 files you mention add functionalities to the
InstanceTag class. This is not a redefinition. The best part is that you
can do the same ! An easy way to overwrite an existing method or to add
new ones is to create a file under you rails application lib directory
and put in it the replacement you want to make:

module ActionView
  module Helpers
    class InstanceTag
      def to_date_select_tag(options={})
          # => your code here
      end
    end
  end
end
 
Then, require it at the end of environment.rb.
 
I believe the new plugin system (I am still at v0.13.1) will formalize
this to avoid modifying the environment file.

________________________________

	From: rails-bounces-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
[mailto:rails-bounces-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org] On
Behalf Of Neeraj Kumar
	Sent: Friday, November 04, 2005 4:31 PM
	To: rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
	Subject: [Rails] Why class InstanceTag is defined at 4 different
places inRails
	
	
	In Rails, the class InstanceTag is defined at 4 places:
	
	active_record_helper.rb
	date_helper.rb
	form_helper.rb
	form_options_helper.rb
	
	
	I have a need to overrite the 
	def to_date_select_tag(options = {}) 
	method of class InstanceTag defined in date_helper.rb . With
little background in Ruby I am finding it difficult to achieve
overwriting a method in an elegant way.
	
	Is it a good design practice to have such big classes inside a
module? Or this constraint has been put by the language or framework?
I''m trying to understand the design rationale.
	
	Thanks.
	-=- Neeraj
	



_______________________________________________
Rails mailing list
Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
http://lists.rubyonrails.org/mailman/listinfo/rails