a timocracy of one

I just got Trac running on Dreamhost for InfoSauce (basically my) Open Source Projects to make it the home of the new Dynamic Scaffold Resource plugin for Rails

The Dreamhost Wiki entry on Trac made it a breeze, if only because of the link to an automated install script .

My only gripe would be that their section on Pretty URLs had a minor bug (for me).

DirectoryIndex wiki

should be

DirectoryIndex index.fcgi

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!

While setting up a new typo install on Dreamhost I hit a bug in the migrations, specifically 051_fix_canonical_server_url. Basically, if you run rake db:migrate to get the DB ready for typo, it chokes because it expects that you have already configured typo.

b.settings['canonical_server_url'].gsub(%r{/$},'')

fails because b.settings[‘canonical_server_url’] isn’t defined, but it’s easy enough to fix, just add unless b.settings[‘canonical_server_url’].nil? to the end of that line:

b.settings['canonical_server_url'].gsub(%r{/$},'') unless b.settings['canonical_server_url'].nil?

I just realized that the Markaby code I have been working with looked familiar for a reason, it very closely resembles Lisp code for generating HTML. There are some obvious syntactical differences (a few missing parens), for instance, but they are still remarkably similar.

And that got me thinking about my preference for JSON, and the fact that it isn’t too far from Lisp in concept (a data storage format that is actually valid executable code in its language) as well as syntax.

Maybe the Lisp zealots are right: the cutting edge of languages will slowly evolve into Lisp. Either that or the quip about you will have ended up writing a Lisp parser by the time you solve some of the same problems in your language of choice.

Of course, Rails is much, much easier to work with for creating web apps, so for now I’ll just be amused by the mini-Lispisms I find.

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