I’m curious to get some feedback from the smart people around here.
I’ve got a method called “to_permalink” that creates a URL friendly
permalink from the name, or title attribute of about 4 AR models.
For those same models I want to override the “to_param” method so it’s
formatted like
“#{id}-#{permalink}”
It’s obviously not too DRY to define to_permalink and redefine to_param
in each model and the two obvious solutions would be:
1.) Create a new class that these 4 AR models would inherit from.
2.) Add a module to lib and include that in these 4 models.
Either way works, but I’m wondering is there a convention for this type
of thing? Any caveats to using one vs. the other? If it’s the same
either way, then what is the most readable in your guys’ opinions?
Let me know what you guys think, or if I’ve missed something altogether.
Thanks,
– Josh
http://iammrjoshua.com
Write an ActiveRecord plugin, like the “permalink_fu” →
A good guide to Rails plugins is →
http://peepcode.com/products/rails-2-plugin-patterns
Maurício Linhares
http://alinhavado.wordpress.com/ (pt-br) | http://blog.codevader.com/
(en)
On Wed, Jan 14, 2009 at 6:04 PM, Joshua A.
Another thing I might point out is that I’m just interested in sharing
methods between these 4 models. If I were to go the new class that the
models inherit from route, that new class would never be instantiated.
With that in mind, it seems to be more sensible to go the module route
to me.
– Josh
http://iammrjoshua.com
Joshua A. wrote:
I’m curious to get some feedback from the smart people around here.
I’ve got a method called “to_permalink” that creates a URL friendly
permalink from the name, or title attribute of about 4 AR models.
For those same models I want to override the “to_param” method so it’s
formatted like
“#{id}-#{permalink}”
It’s obviously not too DRY to define to_permalink and redefine to_param
in each model and the two obvious solutions would be:
1.) Create a new class that these 4 AR models would inherit from.
2.) Add a module to lib and include that in these 4 models.
Either way works, but I’m wondering is there a convention for this type
of thing? Any caveats to using one vs. the other? If it’s the same
either way, then what is the most readable in your guys’ opinions?
Let me know what you guys think, or if I’ve missed something altogether.
Thanks,
– Josh
http://iammrjoshua.com
On Wed, Jan 14, 2009 at 4:04 PM, Joshua A.
[email protected] wrote:
1.) Create a new class that these 4 AR models would inherit from.
This won’t actually work. Rails would try to use the same table to
store all of the models if you inherit from one. See the “Single
Table Inheritance” section from
2.) Add a module to lib and include that in these 4 models.
If you don’t go the plugin route (which I would probably recommend),
this would be the way to go.
–
Training by Collective Idea: Ruby on Rails training in a vacation
setting
http://training.collectiveidea.com – San Antonio, TX – Jan 20-23
Brandon,
I’m familiar with how STI works in Rails, and while you do make a good
point, that could be handled by calling “set_table_name” in each of the
4 AR models that are inheriting from the parent class. However, I’m
trying to cut down on the code I write, and that wouldn’t be cutting
down at all. Another reason I think a module is the way to do this.
A plugin would work also, of course, but IMO a plugin is best suited for
something that would be used and reused, where this is just a one off
situation with literally no more than 4 models. It wouldn’t take long to
put a plugin together that does this, but I would probably never use it
again… who knows though? I might.
Thanks for the pieces of advice everyone!
– Josh
http://iammrjoshua.com
Brandon K. wrote:
On Wed, Jan 14, 2009 at 4:04 PM, Joshua A.
[email protected] wrote:
1.) Create a new class that these 4 AR models would inherit from.
This won’t actually work. Rails would try to use the same table to
store all of the models if you inherit from one. See the “Single
Table Inheritance” section from
ActiveRecord::Base
2.) Add a module to lib and include that in these 4 models.
If you don’t go the plugin route (which I would probably recommend),
this would be the way to go.
–
Training by Collective Idea: Ruby on Rails training in a vacation
setting
http://training.collectiveidea.com � San Antonio, TX � Jan 20-23