More on RestController and some updates 2

Posted by Tim Connor Fri, 20 Apr 2007 18:58:00 GMT

I’ve fleshed out RestController, through some more usage. Combined with moving associated object creation into the model, it now really DRYs out my code, by being a little more flexible.

On any overridden action you can call super, passing in an option options hash. The current options are :template, which works for the editing template for errors on update and create and :find_options, for sorting the index view, for instance. As well, the instance variables (@page_title and @your_model_name) are set with ||=, so you can do custom init and then call super.

Well a picture is worth a thousand words, so, here are the public methods, using all of these techniques, from my most complicated controller on a project using it:


def index(options = {})
super ({:find_options => {:order => ‘date DESC’}}.merge(options))
end

def public_index @page_title = ‘Sun Valley Fishing Report’ @body_class = ‘archive’ index :template => ‘public_index’ end def current @report = Report.current @page_title = ‘Latest Sun Valley Fishing Report’ public_show end def public_show @report ||= Report.find_by_date(params[:date]) @page_title ||= ‘Sun Valley Fishing Report’ render :text => ‘No report found’, :layout => ‘public’ and return unless @report show :template => ‘public_show’ end def new @report = Report.new() Location.find(:all).each { |location| @report.conditions.build(:location => location) } super end def edit @report = Report.find(params[:id]) Location.find(:all).each { |location| @report.conditions.build(:location => location) unless @report.locations.include?(location) } super end

Most of the other controllers ones are a couple of lines, maybe over-riding one action. For instance, here is my UserController, and even this might be simplified when I add in an error condition on edit and show (and/or an passed in error handling block):


class UsersController < REST::RestController
def edit
user = User.find_by_id(params[:id]) unless @user flash[:notice] = @messages[:editing_invalid_id]
redirect_to users_path and return
end
super
end
end

UPDATE: Same day – I updated again, and now I can empty out that user controller, because the edit and show actions have basic checks for not found.

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]

My SOAP hatred vindicated

Posted by Tim Connor Wed, 22 Nov 2006 16:00:00 GMT

For a decent while now there has been an anti-SOAP movement among Rails peeps, REST advocates, and the like. Most recently see: The S Stands for Simple. I’ve been on that bandwagon for a while now, but sort of felt like (due to my own experiences) the enterprisey folks could blow it off as kvetching among the unwashed masses. Well, now, I am at least partially vindicated.

The aforementioned post caused a huge response, all in agreement basically. And among those are people with the enterprise cred and experience with SOAP to make it stick. For example, how about Google’s search and Adwords API? It doesn’t get much more enterprise than that does it?

As someone who bears some past responsibility for well used SOAP services (Google’s APIs for search and AdWords) let me say now I’d never choose to use SOAP and WSDL again. I was wrong.

It’s almost enough to make me want to email old clients.

Of course, the worst SOAP experiences I’ve had is not entirely the fault of SOAP, but a vendor tacking on a SOAP API, when all their docs and code actually directly calls either the Java API or the .NET API. But, that has more than a little to do with the fact that SOAP is a pain in the ass, and the point of the REST approach: Keep It Simple Stupid. Make your API almost exactly the same as your browser based interface, for free.

Oh, and have some more gloating

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.

User-friendly RESTful permalink

Posted by Tim Connor Wed, 18 Oct 2006 16:23:00 GMT

So I’ve taken to changing my permalinks ala: http://www.notsostupid.com/blog/2006/07/07/urls-on-rails/. Of course, Typo already has user-friendly slugs, but I am now prefacing the article id to the title, for the permalink. My thinking being it would take a minor patch to Typo to allow for this sort of routing, and suddenly I have the freedom to rename my article and permalink at will, without making old links obselete. I mean who hasn’t realized a glaring typo AFTER an article is published. Well, if one ever has readers (not me, of course ;)) then you can’t just go and correct it, without making potential links out there incorrect.

Yes, I realize this scheme isn’t actually RESTful, it just came up in looking into REST stuff, and has some potential advantages.

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?

Tim

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

Markaby and Rails named routes and form_for 2

Posted by Tim Connor Thu, 12 Oct 2006 05:57:00 GMT

I’ve been getting back into programming full-time, instead of managing developers and fitting my own coding around that time as I could (read 18+ hour work days), by building a family project in Ruby on Rails. I’ve managed, maintained, and debugged a number of RoR projects, but this will be my first from the ground up full build. Now, of course, this is a perfect opportunity to go all out, use the bleeding Edge, and try and do everything right, which suits my perfectionist side just fine.

Part way through the first phases of the project, I come across Markaby and decide to switch away from ERb to that. It’s a way of doing your templating for Rails in pure ruby, which is nice for me, as my ruby needs more practice than my HTML, and it saves me from the verbosity of HTML.

Of course, a little later I come across another way to get a litle further out of the safe mainstream. While working on my functional tests (yes, not only am I learning Rails, I am learning TDD at the same time) of the verify :method => (to prevent GET requests from accessing destructive methods), I take the next step into territory that Rails Edge has been moving in and push further into RESTful stuff a little further. At the most basic this means using HTTP DELETE to destroy an object, instead of a form post. Of course, since browser don’t support DELETE, Rails has a reasonably sightly hack to let you have your back-end code be clean and handle a true DELETE and a slightly hacked form delete in the same way.

Well then I start going further and trying to make the next model I am working on fully REST accessible. This leads me to some of the newer stuff in Rails for that, the merging of simply resful plugin functionality into Rails. Well that and the kick-ass v2 Agile Development with Rails book lead me into using named routes in my form_for of my templates.


form_for :modelname, url => modelname_path…


Well this is where things get a little jinky. Markaby does all sorts of magic and assumes that most helpers called should be directly output to the HTML stream. This is great most of the time, but sometimes you don’t want this, like when said “helper” is a named route and outputting directly into the HTML at that point will not work with your form. Of course, they address this issue , in general. Well it doesn’t quite solve the problem of this specific usage. A commentor on the blog even asks a question about named routes. Unfortunately commenting is closed to move things to the new Markaby Trac, before there is 100% resolution.


So, at the risk of bugging the maintainers, I reopened an old ticket on the issue, and asked about it there. There is some mention of being able to use .to_s and that does work for me, but I hadn’t really seen it documented, and wanted to know if that was the official word on handling named routes. I’ll update here with the response, but for now this does work in Markaby:



form_for :modelname, url => modelname_path(@instance).to_s