I'd like to write an extension for Devise that allows you to use parse_resource as the datastore (as opposed to ActiveRecord). parse_resource is a Ruby wrapper for Parse.com's REST api. It's interface is pretty much the same as ActiveRecord's and is ActiveModel complaint. Because of this, it seems possible that an extension for Devise may not require too much non-boilerplate.
However, I can't find any tutorials. All I have to rely on are the sources for other extensions. From the MongoMapper extension, I gather that there are two main parts:
The generators (not quite required)
Here you overwrite DeviseGenerator#(generate_model|inject_devise_content|replace_default_devise_orm) methods.
The "guts" (very much required)
I'm not quite as sure what's going on here. It seems that there's a lot of boilerplate, with a little bit of custom type-casting, and at the bottom there's a declaration that we'll be using this extension instead of the default ORM.
Is that all there is to it? What am I missing? Can someone explain what happens in "the guts" in a bit more detail?
Are there any simple lint tests to run to ensure full compatibility with Devise?
I think the best approach would be to write an orm_adapter adapter for parse resource. It is the real "guts" of devise's integration with various orms.
It is actually very straightforward and includes a test suite you can use. Considering parse_resource is activemodel compliant, the adapter should be as easy as cloning an existing adapter.
Next you will need to hook in the orm_adapter to devise, which is just a clone of one of these files.
For a good start you can check out the couchDB extension and the Riak extension as well. You can see that in the Hook module you override anything you want/must for making the Devise to work.
Can you see the class_eval declaration at the bottom? There you extend the class (in your case the ParseResource::Base) with the Devise::Models module, which holds all the necessary methods (including the famous devise method as you can see), and next with the Hooks module if you want to override anything (the MongoMapper extension doen't need to override anything, that's why is not using this method). Thus you must write:
module Devise
module Orm
module ParseResource
module Hooks
# here you define any overrides
end
end
end
end
ParseResource::Base.class_eval do
extend Devise::Models
extend Devise::Orm::ParseResource::Hooks
end
After that you must require 'devise/orm/parse_resource' (assuming you have named the file parse_resource.rb) in your #{Rails.root}/config/initializers/devise.rb initializer. Hope I helped a bit :)
Related
Just now I started to using Concerns in rails, but i have doubt why we go for concerns, because we can achieve same thing on module & mixing concept. So please any one tell about shat is the use of concerns instead of using module.
It's well described here: http://api.rubyonrails.org/classes/ActiveSupport/Concern.html
In short:
Concerns allow you to use #included and #class_methods instead of self.included hook with additional module ClassMethods creation;
Concerns give you a better dependency resolution for modules included in each other;
ActiveSupport::Concern adds some convenient features (i.e class_methods) to your module. You can use "pure" ruby modules without extending it. Essentially you create a module which you mix-in to a class. Doesn't matter if this module extends AS::Concern, the mechanism is the same.
when you write in concern that mean you are making one module. My opinion is concern and module be similar together. Concern can appear somewhere as model, controller and at here you can write module for yourself. And with general module is write in lib folder. Both can be used by way include or extend into a class.
When writing non-rails ruby project I often find myself in the position that I want to use certain parts of the Rails framework. This can be object extensions (like the String method camelize) or, as today, ActionDispatch::Assertions::SelectorAssertions, where I just want to add css_select to some of my tests.
I get pretty confused often over hyphenation/underscoring and often struggle to find out, what exactly I have to require. And I haven't found a system yet...
Is there a rule as to how to require a part of Rails if I know what module or class I want?
I suggest use active support library of rails. It has huge set of inbuilt methods which you can use in your ruby code. Just write in your ruby code.
require 'active_support'
http://as.rubyonrails.org/
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 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)
Let's say I have a Rails app that gets most of it's functionality from a gem (for instance, a CMS).
If I now need to add some customisation (for instance, add a property to a user) what is the best practice way of doing this? If I customise the gem, then I will have issues with updating the gem in the future.
What is the best approach to take here?
This question is quite old, but I feel it could use a bit more fleshing out. It is true that you can monkeypatch rails (and ruby) at run-time. That means it's easy to reopen a class or module and inject new code. However, this is somewhat trickier in rails due to all the dynamic class loading and unloading that goes on development mode.
I won't go into details, but you really want to put your extensions into an initializer, or a gem, since they get reloaded between requests in dev mode. If you put the code into a plugin it won't get reloaded and you'll get very mysterious errors such as "A copy of XXX has been removed from the module tree but is still active!"
The easiest thing to do is throw the code into an initializer (e.g. config/initializers/user_extensions.rb). You can just use class_eval to inject the code.
User.class_eval do
... new code ...
end
One major drawback of ruby's extensibility is tracking down where code is coming from. You might want to add some kind of log message about the extensions being loaded, so people can track it down.
Rails.logger.info "\n~~~ Loading extensions to the User model from #{ __FILE__ }\n"
User.class_eval do
... new code ...
end
Further reading:
http://airbladesoftware.com/notes/monkey-patching-a-gem-in-rails-2-3
Ruby allows you to extend classes in runtime, so you can often hack in to a library without touching the source code. Otherwise I would suggest that you download the gem, create some hooks in the library and submit that back as a patch.
Update:
Note that these customisations are application specific
Yes. What I meant was to modify the generic api in a way, such that it is possible to customise per application. For example, by allowing the user to pass a block to certain methods etc.