Rails - Jul 2005 - Subclassing ActionView::Helpers::DateHelper

Hi,

I would like to create a custom date_select helper that provides a text
input for the year instead of a select, because the date range is far
too large for a select to be feasible.

Clearly, the simplest thing to do would be to subclass
ActionView::Helpers::DateHelper and add my helper to it. 

Where would I put my new class, and how do I ensure that the application
uses it, and the original?

Thanks!
Tom Weissmann


	
	
		
___________________________________________________________ 
Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail
http://uk.messenger.yahoo.com

Tom Schutzer-Weissmann wrote:
> I would like to create a custom date_select helper that provides a text
> input for the year instead of a select, because the date range is far
> too large for a select to be feasible.
> 
> Clearly, the simplest thing to do would be to subclass
> ActionView::Helpers::DateHelper and add my helper to it. 
> 
> Where would I put my new class, and how do I ensure that the application
> uses it, and the original?
I don''t think it''s a matter of subclassing, but instead, just
overriding
the method you need customized. You could do that on the 
application_helper.rb file. So, for instance, you could write there:

#save the standard implementation by renaming the old method
alias_method :old_date_select, :date_select

#override with your new method implementation
def date_select(object, method, options = {})
   unless options[:dropdown_for_year] #your custom option
     ... do your custom code here ...
   else
     old_date_select(object, method, options) # call the default
   end
end

This way, all calls to date_select helper would yield your custom code, 
except if called with the :dropdown_for_year option.

Hope that helps,
Dema
-- 
http://dema.ruby.com.br - Rails from a .NET perspective

On Wed, 2005-07-06 at 15:10 -0300, Demetrius Nunes
wrote:
> I don''t think it''s a matter of subclassing, but instead,
just overriding
> the method you need customized. You could do that on the 
> application_helper.rb file. So, for instance, you could write there:
Or in that case, could I just add an entirely new method,
custom_date_select, and use that?

This leaves me very confused about scope. What ensures these methods are
available in the first place?

Tom


	
	
		
___________________________________________________________ 
Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail
http://uk.messenger.yahoo.com

Tom Schutzer-Weissmann wrote:
> On Wed, 2005-07-06 at 15:10 -0300, Demetrius Nunes wrote:
> 
>>I don''t think it''s a matter of subclassing, but
instead, just overriding
>>the method you need customized. You could do that on the 
>>application_helper.rb file. So, for instance, you could write there:
> 
> 
> Or in that case, could I just add an entirely new method,
> custom_date_select, and use that?
> 
> This leaves me very confused about scope. What ensures these methods are
> available in the first place?
Yes, you could simply add a new method and always use it. The big 
difference is that by overriding the standard method like I showed you 
makes your new method the default behavior, so all helper calls already 
written would change their behavior instantly. But sometimes, that''s
not
what you want, so...

Helpers coded in the application_helper.rb are available to all views in 
your application. Helpers coded in their specific [controller]_helper.rb 
are available only to the views related to the specific controller. The 
scope is guaranteed by ActionPack.

rgds
Dema
-- 
http://dema.ruby.com.br - Rails from a .NET perspective