I have a model that requires loading external data from an auxiliary source. A number of web services exist that my model can fetch the data from (swappable), but I don't want to create code that will make it difficult to change services (costs significantly differ based on variable and fixed usage and it is likely changing will be required).
I would like to create a driver to perform the interaction (and then create further custom drivers if the service requires switching). Unfortunately, due to the tight coupling of the driver and model, it does not makes sense to extract the code into a plugin or gem. I have extracted all the code into a module (see example), and currently have the code declared above my model.
module Synchronize
def refresh
self.attributes = ...
self.save
end
end
class Data < ActiveRecord::Base
include Synchronize
end
Does Rails (3.0.0) have a convention for storing modules tightly coupled with models? Should I be using a plugin to do this? Is this associated with the 'app/helpers' directory? If not, where is the most appropriate place to store the code? Thanks!
You are correct that if the module is tightly coupled to that specific model then it's not a good candidate for a gem/plugin.
app/helpers/ is for view helper methods and shouldn't contain modules that are solely for mixing into models.
One place you could put the module is within lib/. This is for code that doesn't really fit anywhere within app/ and is often the initial home of loosely coupled code before it is moved to a plugin (but that isn't a hard and fast rule). However, since your module is tightly coupled to your model, lib/ may not be the best place for it.
I know that 37signals (and others) use the concept of 'concerns' as a way of keeping related model code organised in modules. This is implemented by creating app/concerns/ and putting the modules in there. That directory is then added to the app's load path in config/application.rb (config/environment.rb for Rails 2) with:
config.load_paths += %W(#{Rails.root}/app/concerns)
The module can then be mixed into the model as normal.
Here's the original blog post about this by Jamis Buck - http://weblog.jamisbuck.org/2007/1/17/concerns-in-activerecord
Another variation of this which I personally prefer, although it doesn't involve modules, uses this plugin:
http://github.com/jakehow/concerned_with
Hope that helps.
This link has helped me out around this.
http://ander.heroku.com/2010/12/14/concerns-in-rails-3/
I have been sticking it in a model/extensions directory. The concerns directory makes sense but the word 'concerns' doesn't feel obvious to me. Maybe it will grow on me.
I also added the extensions path in the application.rb
config.autoload_paths += %W(#{config.root}/app/models/extensions)
Related
This is my first on StackOverflow and I'm a new rails developer.
I'm using RoR to create an inventory application for Magic: The Gathering cards. I've found a Json API that I'd like to use to pull data on all of the cards, sets, etc into a local database.
My initial inclination is to create a helper class to manage all of this (which can also be called in seeds.rb during db:setup), but I have no idea where I should put this class in my project's directory structure. It's not really a model/controller/view, so I feel it should be kept separate from those parts of the app.
Further more, I'm having trouble testing any class I do make. I initially created a directory app/classes and put the class there. Then in my spec directory, I created spec/classes and created the spec file. Accessing my helper class from the spec did not work in the same way that accessing my models in their spec classes did.
I'm at a loss as to how to do this and quite a bit of googling and searching on here has just left me more confused. I'd love any help that can be offered. How would you do this?
You don't mention specifically what issues you're encountering, but for starters app/classes isn't in rails's autoload path - rails' require magic doesn't know to look in there to find these classes (as an aside, 'classes' sounds like a slightly meaningless name - models & controllers are classes too).
You can add to the paths rails searches (see config.autoload_paths in config/application.rb) but I would put this in lib (and the corresponding specs in spec/lib).
It would also work just fine with these classes in app/models, whether or not it does there is down to choice. There's nothing that says that files in there have to be active record subclasses - the decision of whether or not this functionality belongs in there boils down to whether it works/feels like a model to you.
I'm wondering if there are any best practices about where to put non-standard Ruby files in Rails apps, those that don't fit in any of the default directories (controllers/models etc.).
I'm talking about classes that are used by controllers/models etc., but are not subclasses of any of the Rails base classes. Classes that include functionality extracted from models to make them less fat. Some of them kind of look like models but aren't AR models, some of them look more like "services", some are something in between or something else.
A few random examples:
"strategy" classes that handle authentication with password, via facebook etc.
"XParams" objects that encapsulate params or "XCreator" objects that handle processing of params to execute some complex action that results in creating some AR models in the end
classes that make requests to external APIs or encapsulate those requests and responses
fake models that can be substituted for a real AR model (e.g. guest user)
Resque jobs
classes that store and read information from Redis
classes that execute some specific actions like processing data, generating reports etc. and are called from Resque jobs or rake tasks
I've got quite a lot of these now, some of them are added to lib which ends up as a pile of random classes and modules, some sneak into app/models. I'd like to organize this somehow, but I don't know where to start.
Should only AR models go into app/models? Or is it ok to also put there any domain or helper models? How you decide if something is a model?
Should everything that doesn't fit into app go into lib? Or maybe I should add a few new custom subdirectories to app? What subdirectories, and how do I divide the custom classes?
How do you handle this in your projects? I know every project is a bit different, but there must be some similarities.
Good question - i don't have a concrete answer for you
but I recommend checking out this post
- http://blog.codeclimate.com/blog/2012/02/07/what-code-goes-in-the-lib-directory/
- be sure to read through all the comments
on a current project i have a ton of non-ActiveRecord objects under app/models, it works but not ideal
i put 're-useable' non application specific code under lib
other alternatives I have tried on side projects (say we have a bunch of command objects)
rails is a pain when it comes to namespaces under app, it loads everything up into the same namespace by default
app/
commands/
products/create_command.rb # Products::CreateCommand
products/update_price_command.rb # Products::UpdatePriceCommand
alternate, everything besides rails under src or an app_name directory
app/
src/
commands/
create_product.rb # Commands::CreateProduct
update_product_price.rb # Commands::UpdateProductPrice
I haven't come across a good solution for this, ideally the 2nd one is better, but would be nice to not have the additional directory under app, that way you open app and see controllers, commands, models etc...
You touch on a number of different use cases, and I think that this part is the closest to the "right" answer:
I've got quite a lot of these now, some of them are added to lib which ends up as a pile of random classes and modules, some sneak into app/models. I'd like to organize this somehow, but I don't know where to start.
That's pretty much right on in my book. The one thing you don't mention is extracting various pieces into separate gems. Classes that talk to external services are excellent candidates for extraction, as are strategy classes if they're sufficiently general. These can be private, since running your own gem server isn't hard, and you can then obviously reuse them across ROR apps.
Last and most concretely, resque jobs I stuff into lib/jobs.
My rule of thumb is if it's a model of some kind, it goes into app/models. If not, it probably belongs in lib or some appropriately named subdirectory thereof, e.g. lib/jobs, lib/extensions, lib/external, or the like.
If you're interested, I also wrote a follow-up article about this a bit later summing up what I found: http://blog.lunarlogic.io/2013/declutter-lib-directory/
I place any model classes (like STI subclasses) in apps/models. I place my other classes in lib, as it seems to be the best place to put them. It's easy for me to know where to look. It's also easier for me to group my tests since my model classes are all in one place.
Convention-wise I'm loathe to put helper classes in app/models. If they're presenter classes they belong in the app/helpers. If they're not then lib seems to be the best place for them.
Often my classes find their way into lib in subdirectories where modules with the same name as the subdirectory is responsible for including them. (Rails is very touchy about filenames and classnames when it comes to the autoloader.)
Another option is to encapsulate each module into its own gem and then refer to the gem via your Gemfile. This permits code sharing across projects.
I am new to Ruby on Rails and my questions are about the application design, based on Rails 3. There are many data on the internet on the creation of standard websites (such as blogs) on Rails, but my application requires more than just "post and read" and I am not sure how to implement that.
The idea:
The model "Route" includes a number of airlines modules: "Ryanair", "easyJet", etc.
The "Route.Update" method calls the "UpdateRoutes" on each airline module (for example, "Ryanair.UpdateRoutes", "easyJet.UpdateRoutes")
It should work the same way with more models (such as "Flight.find") and more airlines ("Delta.FindFlights")
The questions:
Where should I store all the modules? I don't see any app/modules folder in Rails.
If my modules require gems, should I include them in the modules or in the models (where they are actually used)?
I want to make my application scalable. For example, I want to add a new working airline (module) without changing any code in "Route", "Flight" or any other model. I imagine something like the method "IncludeAirlines" which would go through modules/airlines/name.rb, include every module and call the needed method of it (such as name.UpdateRoutes). Is there any better way to implement that in Ruby on Rails?
As you might know, modules are generally used either as namespaces or as mixins.
Where you place a module depends on how tightly coupled a module is with the app directory . A few patterns in storing modules :
The /lib directory, if the module does not particularly 'interact' or concern the app/ and you treat the module as an internal plug-in.
The app/models directory, would be an appropriate place if your module is central to your business logic. A popular use case here, is where you use a module as a mixin to DRY your models/controllers.
37 Signals introduced a pattern of treating them as 'concerns' and storing them in app/concerns.
If your module uses a gem, you may need to require the gem in the module (sometimes a require is not at all necessary).
Your 3rd question is not clear. Sorry about that. Not quite sure what you're trying to do.
I have a model that requires loading external data from an auxiliary source. A number of web services exist that my model can fetch the data from (swappable), but I don't want to create code that will make it difficult to change services (costs significantly differ based on variable and fixed usage and it is likely changing will be required).
I would like to create a driver to perform the interaction (and then create further custom drivers if the service requires switching). Unfortunately, due to the tight coupling of the driver and model, it does not makes sense to extract the code into a plugin or gem. I have extracted all the code into a module (see example), and currently have the code declared above my model.
module Synchronize
def refresh
self.attributes = ...
self.save
end
end
class Data < ActiveRecord::Base
include Synchronize
end
Does Rails (3.0.0) have a convention for storing modules tightly coupled with models? Should I be using a plugin to do this? Is this associated with the 'app/helpers' directory? If not, where is the most appropriate place to store the code? Thanks!
You are correct that if the module is tightly coupled to that specific model then it's not a good candidate for a gem/plugin.
app/helpers/ is for view helper methods and shouldn't contain modules that are solely for mixing into models.
One place you could put the module is within lib/. This is for code that doesn't really fit anywhere within app/ and is often the initial home of loosely coupled code before it is moved to a plugin (but that isn't a hard and fast rule). However, since your module is tightly coupled to your model, lib/ may not be the best place for it.
I know that 37signals (and others) use the concept of 'concerns' as a way of keeping related model code organised in modules. This is implemented by creating app/concerns/ and putting the modules in there. That directory is then added to the app's load path in config/application.rb (config/environment.rb for Rails 2) with:
config.load_paths += %W(#{Rails.root}/app/concerns)
The module can then be mixed into the model as normal.
Here's the original blog post about this by Jamis Buck - http://weblog.jamisbuck.org/2007/1/17/concerns-in-activerecord
Another variation of this which I personally prefer, although it doesn't involve modules, uses this plugin:
http://github.com/jakehow/concerned_with
Hope that helps.
This link has helped me out around this.
http://ander.heroku.com/2010/12/14/concerns-in-rails-3/
I have been sticking it in a model/extensions directory. The concerns directory makes sense but the word 'concerns' doesn't feel obvious to me. Maybe it will grow on me.
I also added the extensions path in the application.rb
config.autoload_paths += %W(#{config.root}/app/models/extensions)
I have several methods I call from my controllers that feel like they should be pulled out and put into a reusable class, outside of the controller. Where do people usually put this stuff? I know I can put them into my ApplicationController, but that doesn't seem to be a great solution if I think I can use these methods later in other applications.
Also, I have a bunch of utility methods in my controllers that likely won't be used in other controllers, or in the future at all, but I feel like they just bloat my controller a bit. Do people usually move these out someplace for cleanliness or just end up with a huge controller?
I'm coming from Java and Actionscript where I'd just create new util classes for this stuff.
The lib directory is a place you can put modules/classes which can be mixed in or used by controllers (and anything else, really). This can be a place to put code that doesn't fall into other areas (but be careful about making sure lib doesn't turn into a mess itself). Side comments just to keep in mind:
If you know you have a large amount of related functionality that could, or will, be used in other applications, that might be a plugin.
Its also worth keeping in mind that there's nothing wrong with creating a model that is not an Active Record object. So again, depending on what you have, this might make sense as well.
Create a module file in lib directory:
module ControllerUtil
def foo
end
def bar
end
end
Include the module in the controller:
class UsersController < ApplicationController
include ControllerUtil
end
You can create app/modules directory, and create XYZUtils module in it e.g
module XYZUtils
def abc
end
def efg
end
end
and include the module as and when required in Controllers or models etc.
include XYZUtils
You can create different modules for utility functions related to different Models or entities
I won't prefer /lib directory because that should contain the project related code, not app related, e.g tasks etc.
I would keep all the App related code in /app directory itself
Related to Sahil kalra's above answer from 2014:
Rails now has an app/controllers/concerns directory where you can put modules full of helper methods and easily include or extend them in your controllers. I just copied and pasted all of my logic-intensive methods out of my application_controller and they worked right out of the box.
(You should, of course, still make sure everything works correctly before putting anything into production.)
Controllers should be very minimal - basically ingesting arguments and making some very high level decisions. If you have some helper functions that are doing just those kinds of things but aren't going to be reused, then keeping them in the controller is the right thing to do. Just make sure to mark them as private.
For more commonly shared things, you can either back them into your ApplicationController (if they're used in all controllers) or into a class in your app/models directory. I recommend the models directory over lib because Rails in development mode is much better about spotting changes to those files and reloading them. Changes to files in /lib tend to require restarting the webserver, which slows down your development effort. This is unfortunate, because controller helpers really should not be mixed with models.
In general, though, if you have more than a handful of these helpers, you're probably doing too much in your controllers. Take a hard look at them and see if maybe some of them shouldn't be part of your models instead.