Absolute beginner with ruby and with rails. My first full blown project will interface with an existing system through a REST api.
So it doesn't employ the normal ActiveRecord model and I was hoping for some examples of projects that replace the normal use of models with API calls. The entire CRUD set will require the app to make the corresponding API calls. I'd like to do this the right way, just don't know what that looks like yet.
Thanks! :)
Helpful links for googlers:
http://yetimedia.tumblr.com/post/35233051627/activeresource-is-dead-long-live-activeresource
https://github.com/rails/activeresource
I don't know of any projects that are open source that do this, but I'd recommend looking into Active Resource. It was part of Rails through 3.2, but has been moved to a separate repo for Rails 4. The idea is that it lets you replace database persistance with RESTful APIs, which sounds like exactly what you're trying to do. There is some documentation here which should give you enough info to get off the ground. There's also a pretty old Railscast on it, but I'm sure the concepts haven't really changed that much.
Here's an example from the docs that shows how to setup your "model":
class Person < ActiveResource::Base
self.site = "http://api.people.com:3000"
end
I'd suggest leveraging ActiveModel so your models aren't 'AR' backed, i.e. no persistance via AR. You'll handle CRUD accordingly in your controllers and craft your own 'business logic' that you can tuck into your ActiveModel.
Related
I'm looking for the "rails" design pattern for code that fetches data from other websites.
I have a rails controller in my app that fetches data not from the database, but from external API's or scraped from the web.
Where's the "rails" place to put this code.
For quick implementation, I just stuck it in a model, but the model doesn't interact with the database - or support standard model functionality - so that feels wrong, but my understanding of rails and ruby isn't yet solid enough to know where it should go.
The way the code works roughly is
controller calls model.fetchData args
the model uses HTTParty or similar to make the call
processes data
passes it back to the controller
Any advice?
Broadly-speaking I think there are two possible ways to do this:
Create a plain ruby class to contain the methods for making requests to the API(s) and processing responses from it(them). You can include the HTTParty module in this class with include HTTParty. The usual place to put this code is in lib/ (make sure that wherever you put it, the path is in autoload_paths).
If you're doing anything really complex, or the API itself is complex, you might want to consider creating a separate gem to handle interaction with the API(s). The term for this type of gem is an "API wrapper" -- if you look around, you'll see there are lots of them out there for popular services (Twitter, LinkedIn, Flickr, etc.)
Notice I haven't mentioned activerecord. If you're not going to be saving anything to the DB, I don't see any need to even create any activerecord models. You can get by with just controllers and views, and then (if needed) pick and choose components from activemodel (validations, internationalization, etc.) to make your ruby API wrapper class feel more like a Rails model. For example, one thing that I've done in an app I'm working on is to apply validations to query strings before actually making requests to an external API, which is a bit like running validations on database queries before querying a DB. See this article by Yehuda Katz for more on how to make plain ruby objects feel like activerecord models.
Hope that helps. I answered another question very similar to this one just yesterday, you might want to have a look at that answer as well: Using rails to consume web services/apis
I have a set of models I need to share among several rails3/sinatra/etc applications. I haven't seen anything like this yet and I'm curious what is the most effective way to go about this in a DRY manner? Can I specify a central area for models, can I create a gem that only brings in the models I need? How have other people approached this issue. I was thinking of making a smallish gem or something I don't yet know about to handle this.
I'm using Datamapper, but this is also a more general issue of structuring multiple rails/non rails ruby apps.
You might find it's easier to have a submodule in your repository that contains your models and associated unit tests than to create a full-fledged gem. This way you can patch from one app to the other instead of having to drive everything top down.
You can create public API to models you want to use in other apps.
In rails you should already have REST controllers, so you can use ActiveResource in the other apps.
You can pack your ActiveResource classes in a gem just to simplify thing and to keep things DRY.
You can check: http://api.rubyonrails.org/classes/ActiveResource/Base.html for some examples.
And it doesn't matter if you're using ActiveRecord or DataMapper.
I just started to document a rails application. I know this is actually done by rdoc, so I followed some rdoc guides regarding syntax and so on, but I got stuck when I tried to describe attributes of models, validations and the relationship between models, mostly because these things are part of ActiveRecord. So I wonder if there is some guide or a good practice regarding how to document a rails application or if there is something I'm missing?
I know that I could put all of this in the class description, but I wonder if there is a way more closely tied to the declaration itself (has_many, validates_presence_of, etc.) and what about the attributes?
I personally prefer YARD - http://yardoc.org , as it does a better job in documenting IMHO.
I don't know if there's a specific handler for Rails available, but it's quite easy to write one - http://yardoc.org/guides/extending-yard/writing-handlers.html
A good example might be the attribute handler - part of the yard gem:
lib/yard/handlers/ruby/attribute_handler.rb
Remember your tests are part of the documentation (for developers), particularly if you are using Cucumber where scenarios are easy to read. If you keep your methods very short and there is a test method with a descriptive name e.g. "should set the users name" I find I typically don't need comments on the method.
Validations or other parts of Rails I would not document. Part of being a Rails developer is understanding how these work, I think it is a fair assumption that another maintainer of your code reading it down the road will know validations, or other things built in to Rails. By that same logic, if you can use features of the framework or happy paths (not deviate much) with [documented] third party code, a lot of the documentation will be written for you.
I've read about HMVC (Hierarchic Model View Controller) and it's flexible structure.
Have a look at this picture:
http://techportal.inviqa.com/wp-content/uploads/2010/02/MVC-HMVC.png
I wonder if the Rails 3 plugins are the answer to HMVC in Rails 3?
Based on the comments to Toby's answer it seems that you would like to be able to have MVC apps used as a component within a new app. Rails Engines (See http://rails-engines.org) provides this functionality. You simply install the engines gem and place apps in vendor/plugins and its modles/views/controller are all accessible.
This does not really conform to HMVC where the controllers in the new app delegate to other controllers. But like Toby I do not see the advantage of that.
What is nice about the Engines approach is that you can over ride any of models in the plugin by just adding a version of the model to the new apps app/model folder (same applies for views and controllers)
I have overidden app/views/layouts to give my Authentication app/plugin the same look and feel as the application it is included in.
For Rails 3 Railtie takes the place of engines and is officially supported (and actually used - Action Mailer is a Railtie plugin. I have not used it myself yet though.
Check it out at http://edgeapi.rubyonrails.org/classes/Rails/Railtie.html
A nice write up on it is also here http://www.igvita.com/2010/08/04/rails-3-internals-railtie-creating-plugins/
Rails has had plugins for a long time.
I doubt there is a technical reason why a controller couldn't dispatch to another controller, passing the request object along a chain. I just don't know what you gain by doing so - the diagram looks like spaghetti.
To me it's a misuse of MVC. I would suggest it is much simpler and more maintainable to push logic into lower-level models and classes and create a single controller that fronts the this logic, rather than creating a chain of controllers.
In the Rails 3 blog post, DHH mentioned the Cells project. I haven't used it but I am going to check it out.
The cart example shows well how that kind of functionality might clean up your application code. Code which retrieves data should be placed somewhere in controller. In every action or in a before filter. The Cell seems to be much better solution.
Please look at this rubyonrails-talk post: https://groups.google.com/forum/#!topic/rubyonrails-talk/0c4TT7UOGCw
I have been using ActiveResource in my Ruby on Rails applications for some time, and I am starting to really feel that it needs a final polish to make it go from "pretty nice" to "beautiful".
I would like to be able to use an ActiveResource as if it were an ActiveRecord. If I could use has\_many, belongs\_to and other niceties with ActiveResources, it would make my life easier.
So I looked around for a plugin to do just that, but haven't had any luck finding one. Has anyone written one? Does anyone know of an ongoing project?
Raison d'être
Let's say I have an application which manages Users, and another application which manages UserRequests. I would like to avoid any circular dependency between my applications, therefore I have decided that the Users application will be completely unaware of the notion of UserRequests. But of course, a UserRequest should belong to a User, and a User should have many UserRequests.
So, in the Users application, all I have is a User ActiveRecord, with all the necessary controller stuff to make it usable through ActiveResource.
The complicated stuff is in the UserRequests application. I have a UserRequest ActiveRecord, and a User ActiveResource. I would love to code the fact that a UserRequest belongs_to a User ActiveResource, and a User ActiveResource has_many UserRequests.
In another scenario where it could be the other way around (the ActiveRecord has_many ActiveResources, and the ActiveResource belongs_to the ActiveRecord).
Ryan Daigle proposed to do something similar with his Roxy gem. From his teaser section:
I hope to have an extension library up
soon that utilizes Roxy to provide
ActiveRecord-like association
definitions in ActiveResource.
The example he gives shows how it wouldn't be too difficult to implement with Roxy.
I just ran across the Hyperactive Resource plugin. I am looking at it right now... looks good.
The funny thing is that I had decided to write my own plugin, and I was looking for a good name for it. I wanted to find a name which would give the feeling that it was "ActiveResource++", an enhanced version of ActiveResource. I hesitated between "SexyResource" and "HyperactiveResource", and I decided that the former was not politically correct enough. So I started to write my HyperactiveResource plugin... until I wondered if someone else had already thought of that name. And it turns out someone did. And the plugin was there. Cool! But it's kind of scary how we developers think alike, isn't it? ;-)