a timocracy of one

I got tired of the complexities of my plug-in solution to DRYing up the shared code in all my Restful controllers, and scaffolding gets no love from core. But after a little while I got almost as tired of having the same 7 methods repeated throughout my code base. Thus a new simpler project is born: RestContoller.

Instead of scaffolding your views (which the core team is right about – those should diverge widely to fit the UI needs) or adding tests for you, it just gives you a main rest controller to inherit from that has the 7 basic actions (index, show, new, edit, create, update, and destroy). I was also able to simply further and drop the giant block eval, by looking over Jake Howerto’s CRUDController and borrowing a technique or two (such as the use of instance_variable_set). This should make the code easier to follow, customize, and also more performant.

You can just do a vanilla checkout from Google Code, and then inherit from that.

svn checkout http://restcontroller.googlecode.com/svn/trunk/ app/controllers/rest
class YourModelController < REST::RestController

but with this new approach it’s much more natural to customize per project. You can just go ahead and grab the file, save a local copy, check it into your own source control, and do with it as you will. For instance, if all of your resources have a public facing front, but the rest should be restricted, just add something like this (as well as the appropriate function in your application.rb)

before_filter :require_login, :except =>[:show, :index]

Dynamic Scaffold Resource is now moved to Google Code. That has been the plan for a little while, but I had to get the repository reset, so I could svnsync the old repo up and keep the history.

Since this is a move to a project specific svn repository that has obviously been moved all around. And since the repository UIDs are different, you basically just need to do a clean checkout of trunk anyways:

http://dynamic-scaffold-resource.googlecode.com/svn/trunk/

I added a couple instance variables that can optionally be set so that the test helper can actually be used in something beyond the skeleton of the plugin’s own test environment. You can use it in an authenticated environment now, because you can set @scaffold_session_params and you can use it on resources that have validation in their models, because it will use @scaffold_dummy_object for the create and edit test, if you set it.

Didn’t change the core of the plugin itself, but the testing piece really was useless, so I had to add this just to use it on the project I made the plugin for in the first place.

I got everything I wanted done: testing, easy install, and documentation, so as of now Dynamic Scaffold Resource is ready to go. I’m holding off on making it officially 1.0 to see if there is any feedback from the people who expressed interest on the Rails core list.

While I know it could be fleshed out a lot more, my goal was to try as closely as possible meld the generated scaffold_resource and the dynamic scaffolding call, so as to make included it in Rails a better possibility. As such any feedback is still most, most welcome, but any new functionality would probably go in a post 1.0 branch. And there are a number of more fully featured scaffoldingesque plugins out there already, anyways.

As of 30 minutes ago, DynamicScaffoldResource hit 0.2 (tests implemented). All that leaves is documenting, trying to find an eaiser way to include the required Rails patch, and any bugs people find or fixes they suggest. It’s fully functional, though – I’m currently using it on a resource in a project under development.

Of course, having seen the code, I don’t know that I would exactly suggest this (or any of the Rails dynamic scaffolding) as a production solution or anything. Which is a shame, because with how much code is in common in newly RESTed controllers, it’d be nice to DRY them out.

I mentioned this in my previous post, but to make my plugin easier to test I tried to make it not need to touch the DB, which was interesting to do, given that scaffold_resource is very much tied to a model. This was a big inspiration and this the final (as of now) result:

class Resource < ActiveRecord::Base
  @@count = 1
  def self.count() @@count end
  def self.columns() @columns ||= []; end
  def self.column(name, sql_type = nil, default = nil, null = true)
    columns << ActiveRecord::ConnectionAdapters::Column.new(name.to_s, default, sql_type.to_s, null)
  end
  def self.find(param)
    return param == :all ? [Resource.new{ |m| m.id = 1; m.name = 'bob' }] : Resource.new{ |m| m.id = 1; m.name = 'bob' }
  end
  def save() @@count += 1 and return true if valid? end
  def destroy() @@count -= 1 end
  column :name,          :string
end

In testing DynamicScaffoldResource, I have been working on sort of mocking/overloading ActiveRecord so that it doesn’t touch the DB, so I can minimize how much it depends on the root Rails environment to test, since it’s a plug-in.

class Resource < ActiveRecord::Base
  def self.columns() @columns ||= []; end
  def self.column(name, sql_type = nil, default = nil, null = true)
    columns << ActiveRecord::ConnectionAdapters::Column.new(name.to_s, default, sql_type.to_s, null)
  end
  def self.find(param)
    return param == :all ? [Resource.new(:id => 1, :name => 'bob')] : Resource.new(:id: => 1, :name => 'bob')
  end

  column :id,            :integer
  column :name,          :string

  validates_presence_of :name
end

Well Rails treats the id as a special field, since it is. I tried letting it implicitely add it, and explicitely as above, but there was no way I seemed to be able to set it manually and access it (maybe the problem is prior to a save?), so my edit named route in the view wouldn’t choke (the show path had no problem with the nil, which I might not have caught for a while). While there is probably some way to open up access to the id column, this mailing list post opened up an alternative that works, just use:

Resource.new{ |m| m.id = 1; m.name = 'bob' }

My first Rails plugin, DynamicScaffoldResource has hit 0.1 – it now should handle all the basic REST actions almost identically to the generated scaffold_resource. The main difference is it uses the ActiveRecordHelper form() call to dynamically generate the forms, and auto-iterates over the columns on index and show, just like the offcial scaffolding. This is more fitting for the dynamic scaffolding than the blank form approach of the generator, which makes sense for that, since you will be filling that in manually.

If anyone is interested the subversion repository is up at http://svn.infosauce.org and trac is at http://trac.infosauce.org

It is still completely undocumented and untested, but those are the plans for the next release. Knowing what else needs to be fixed it probably won’t be before 0.4 or 0.5 before I’d say it’s public ready. For instance, it still requires you to have these patches applied.

I just submitted my first two patches to Ruby on Rails. I was thinking that I wanted something a certain way, and the best way to get that is contribute. I submitted these two “tiny” patches:

add options[:url] to form() in active_record_helper.rb – partially allows for RESTful call

add options[:method] to form() in active_record_helper.rb – partially allows for RESTful call

as they truly are tiny and might get applied. And of course, I submitted the tests, so my patches didn’t get tossed out immeditately.

I have to say trying to get Rails to pass its tests is a pain, and from the look of their ticket system, some of those might not be meant to pass yet (TDD). Anyways, I gave up on some of the minor tests that might not work on my system (Win32), and just made sure I did not break anything else, in making my changes. One I did that, it was actually pretty easy.

Then since the end goal I am aiming at is significantly larger, I submitted the following email to the core mailing list, instead of just jumping in and stepping on toes.

So I’ve RESTified a couple controllers, now, using the latest stuff in Edge and they don’t feel very-DRY. I realize that after they get more complicated they will need to be able to be stand-alone, but they are currently pretty wet. I considered working on an abstract REST controller, but then realized that dynamic scaffolding was almost all I needed. I just want to be able to not have to repeat myself until the controller diverges from the norm.

Now perhaps an abstract controller might be able to be figured out in such a way to allow for better TDD, but I think basically a copy of the current generated tests for scaffold_resource could just be dropped in test for those who want to do TDD, and the scaffolding could use updating if everything is supposed to move towards REST/CRUD.

I submitted a couple tiny patches to active_record_helper.rb form() to add options[:url] and options[:method] so that the ARH form could at least be called in the current REST style (since the scaffolding uses that form(), which was hard-coded to an old-style url :action =>), but wanted to ask here before proceeding further.

Am I completely off base here? If I want a dynamic scaffold_resource :model should I proceed and submit the patch? Should I just update the current scaffolding to use the new REST style, or make it scaffold_resource? What are the odds of this sort of thing getting applied? More likely given the push to REST, and since this would add another minor nudge? Should I make any other tiny patches needed to core, and then just make the rest a plug-in?

Tim

So nothing has been accepted yet, but my first patches are submitted at least. Yay!