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? ;-)
Related
I'm building a multi-tenant app in rails. I've decided not to do a separate table for each tenant like in the appartment gem.
I've decided that I can either do an around_filter in my application controller that puts a default_scope on everything, but I also thought that maybe it would be easy enough to do via permissions in the authorization gem I'm using.
The latter seems simpler, so I'm tempted to go with it. But I don't see it being recommended anywhere so I'm wondering if there's maybe a major security hole I'm not thinking of.
It seems sensible to use authorization gem. If implemented correctly, there should be no serious security hole at application level, so go for it. (If you use CanCan, there was already a question on this on StackOverflow: here)
Note that if you are concerned about security more than anything else, you should have gone for separate tables, schemas or even databases. But hopefully you have already analyzed the possible choices :) Anyway, here is an interesting article from MSDN about multi-tenant architecture with lots of useful thoughts and hints.
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.
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.
We are evaluating plugins for Authorization in Rails. The two at the top of our list are
cancan and declarative_authorization.
I would like to get some feedback from anyone currently using either of these plugins.
The problem we are going to face with any authorization plugin is that we have a
database per customer model and will need to modify the plugin to work within that
model. Because of this fact I'm interested in hearing from anyone who has had to tweak the
plugins at all as well.
I'm just starting to look around at the code. It seems like cancan might be a little easier to customize.
Any thoughts?
Cancan is a lighter weight plugin for smaller sites. You can see a video on railscasts.
http://railscasts.com/episodes/192-authorization-with-cancan
I've used declarative_authorization with authlogic/restful_auth for several projects. It has everything you would need. 1) Model security. 2) Controller security 3) methods available to the view to check auth.
The only frustrating thing I've run into with declarative_authorization is me not reading the rdocs.
http://railscasts.com/episodes/188-declarative-authorization
Authority
I'd suggest you also check out my new gem, Authority. Because you do the actual logic in plain Ruby classes and methods, you can check any data source you need to: different databases, static files, phases of the moon via a web request, you name it. :)
I ended up using declarative_authorization. Now it seems that auth_logic is where the community is headed.
declarative_auth would have been really simple if it wasn't for our apps multi-tennant db
model. I had to modify the source a bit to make it all work, but it wasn't too tough to do, and
I was pretty green when I started this project.
It seems like you really can't go wrong with any of the solutions. cancan seemed cool too
but it would have needed more mods for what I was doing so I decided against it.
Its written by Ryan Bates though which is cool. Love rails casts! :)
I know this post is old but I figured I'll update any because you never know.
I starting building my app using nifty-generators for the user authentication because I'm new to Rails and it was the easiest approach. Now, we're looking to launch the app and I want to implement the popular Restful Authentication because we need some of the features it offers.
I've never upgraded an existing model in this way, and I'm wondering what the best approach would be. Should I strip out the user model-related stuff? Or will Restful Authentication just overwrite the commonly name items? Of course, I can go into the app and make tweaks based on any changes.
Generally, how would more experienced Rails coders approach this?
Thanks!
You might want to check out Authlogic instead. There's a good railscast episode where he implements Authlogic with nifty generators.
I would add another model and relate that via an has_one-relation..
f.e. adding a Account-Model (if your user-model already exists)
class Account << AR
belongs_to :user
end
class User << AR
has_one :account
end
If you've got a fair amount of tests, there shouldn't be an issue. Your suite will let you know if you've done something wrong.
Personally I would implement Restful Auth, by hand, on another project. Play around with it until you understand how it affects your user model, then copy over the code and any migrations you need.
A nice tutorial on Restful Auth and some cool extensions is here