Rails - Dec 2005 - Helper Classes

Hello,

Helper methods are currently implemented as modules that, I assume, are
included in the ActionView class in the context of the ActionView.

This is fine for simple views, but it seems like it may cause problems when
the views get more complicated.

Some tight coupling will start to happen If the helper grows and grows and
gets a bunch of methods. You could move some of the methods to another
helper module, but the object still has all of the methods. This would make
it more difficult to unit test the helper since there is potentially some
tight coupling going on.

Also, there is the possibility of name collision. One can start pluggin in
one of the many 3rd party helpers (
http://wiki.rubyonrails.com/rails/pages/3rd+Party+Helpers), but what if two
of the 3rd party modules have the method :render_this?

I think making the helpers into classes would solve these issues, for the
same reasons why object oriented code handles complexity better than
procedural oriented code.

Has anybody used Helper Classes? If so, what is a Rails friendly convention
of doing so? For example, would the helper classes go into the app/helpers
directory or in the same directory as the view (app/views/viewname)?

Are there any examples out there?

--
Thank you,
Brian Takita
http://freeopinion.org


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

are included in the ActionView class in the context of the ActionView.


I meant to say

are included in the ActionView object.


On 12/12/05, Brian Takita
<brian.takita-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
>
> Hello,
>
> Helper methods are currently implemented as modules that, I assume, are
> included in the ActionView class in the context of the ActionView.
>
> This is fine for simple views, but it seems like it may cause problems
> when the views get more complicated.
>
> Some tight coupling will start to happen If the helper grows and grows and
> gets a bunch of methods. You could move some of the methods to another
> helper module, but the object still has all of the methods. This would make
> it more difficult to unit test the helper since there is potentially some
> tight coupling going on.
>
> Also, there is the possibility of name collision. One can start pluggin in
> one of the many 3rd party helpers
(http://wiki.rubyonrails.com/rails/pages/3rd+Party+Helpers
> ), but what if two of the 3rd party modules have the method :render_this?
>
> I think making the helpers into classes would solve these issues, for the
> same reasons why object oriented code handles complexity better than
> procedural oriented code.
>
> Has anybody used Helper Classes? If so, what is a Rails friendly
> convention of doing so? For example, would the helper classes go into the
> app/helpers directory or in the same directory as the view
> (app/views/viewname)?
>
> Are there any examples out there?
>
> --
> Thank you,
> Brian Takita
> http://freeopinion.org



--
Brian Takita
http://freeopinion.org


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