Dynamic-Scaffold-Resource is dead, long live RestController 4

Posted by Tim Connor Tue, 03 Apr 2007 18:39:00 GMT

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 moved to Google Code

Posted by Tim Connor Fri, 27 Oct 2006 04:21:33 GMT

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:


Dynamic Scaffold Resource test helper now sucks less

Posted by Tim Connor Thu, 26 Oct 2006 07:00:00 GMT

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.

Dynamic Scaffold Resource Rails plugin at final prerelease 2

Posted by Tim Connor Wed, 25 Oct 2006 23:48:00 GMT

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.

DynamicScaffoldResource is Beta

Posted by Tim Connor Fri, 20 Oct 2006 06:14:00 GMT

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.

Mocked out ActiveRecord for testing plugin

Posted by Tim Connor Fri, 20 Oct 2006 06:06:00 GMT

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

Manually setting id in Rails 2

Posted by Tim Connor Fri, 20 Oct 2006 00:12:00 GMT

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)
  def self.find(param)
    return param == :all ? [Resource.new(:id => 1, :name => 'bob')] : Resource.new(:id: => 1, :name => 'bob')

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

  validates_presence_of :name

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’ }

Dynamic Scaffold Resource Rails plugin is officially Alpha

Posted by Tim Connor Tue, 17 Oct 2006 23:44:00 GMT

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.

My first contribution : a couple of patches toward dynamic scaffold_resource

Posted by Tim Connor Mon, 16 Oct 2006 16:17:00 GMT

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:

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

[PATCH] 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?


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