Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Where should I put functions that are accessed by models? -- Rails 3.1

I've been told that the helpers are just for functions that are needed by the views.

Where should I put in functions that are used commonly by models? What about controllers?

What's the convention to place commonly used functions that will be used in:

1) models

2) views

3) controllers

Problem: Creating a module in lib to hold the functions and including the module in a class would create a boat-load of instance methods for the class.

Problem: What about functions that are common and needed in all three?

like image 895
user1049097 Avatar asked Oct 15 '25 18:10

user1049097


2 Answers

Problem: Creating a module in lib to hold the functions and including the module in a class would create a boat-load of instance methods for the class.

First organize, then optimize

Problem: What about functions that are common and needed in all three? Do you really have methods that are needed in all the three and not exist yet ? If yes, may be you can give an exemple

I think the question should be where to put logic in general. You should first think what your method does before to think about where to put it. But whatever you create, when it's getting big and or valuable, you should really think about exporting it as a gem/plugin.

Inner navigation logic (what to display and where to go after an action) : Controllers

  • App navigation logic; application_controller
  • Sub set of app logic; create a namespace with master controller, class API_controller < application_controller

Data logic (How to manipulate, process data) : Models

  • Data; Model class method (search, sorting, counting, macro process ...)
  • Datum; Model instance method (modification, micro process ...)

Data presentation logic (How to display data) : Helper, Partial and Decorators

  • Helper are not designed for that in my opinion.
  • Partial handle layouting of specific data.
  • application decorator; handle generic data presentation help
  • scope_decoration; you can use inheritance

Layout language logic (layout language help) : Helper

  • Specific to your app; application_helper
  • Specific to a model ...; model_helper, but you should consider decorator
  • Generic; export it in a gem (super form helper, templating system ...)

Layout logic (should i display this menu ?) : ?

  • Helper/decorator/model can should answer the question : @user.can_edit?(@article)
  • Layout handle the display <%= render :partial => allowed ? "something" : "somthing else" %>

I think if you are not in this configuration you are creating kind of backend system. So it should go in lib, then in a gem later.

This organization is just an exemple. The most important thing is to organize your code and split different logic layers and don't hesitate to refactor/export code to make it generic after adding new features...

like image 54
ProxyGear Avatar answered Oct 17 '25 08:10

ProxyGear


  • for Controllers - put common methods in application_controller.rb
  • for Views - put common methods in application_helper.rb
  • for Models - monkeypatch ActiveRecord::Base to include common methods OR write a module with common model methods and include it in the models that need it OR do it in OOP way by subclassing ActiveRecord::Base with your abstract class, then inheriting all your models from this class.

To use common methods in both Model and Controller, do one of the following:

  • Write a plain ruby class, put it in /lib or elsewhere, just make sure it's loaded, then require it when you need to use its methods.
  • Extract common functionality to a gem, install it, require it when you need it. Publish it to rubygems if it's something valuable.
like image 41
buru Avatar answered Oct 17 '25 07:10

buru