The generic controller. A standard implementation of the CRUD actions that can be used out-of-the-box in a large majority of cases.

The idea is that the concrete controllers that make up an application will need no custom code at all — just a few declarations: I need an auto-completer for this attribute, an ajax-setter for that one… I don’t see why this can’t be done.

Of course if an application needs to do something unusual, then sure you might want a custom action or two. But a huge number of apps are really nothing more than a web-interface to a database, and nearly all apps have at least some parts that fit this description.

There are a couple of challenges though. Firstly, what should these standard actions render? It’s all very well to have a single URL that you hit to, say, create a new event in your calendar, but depending on where in your app you’re coming from, you’re likely to want a different page (or ajax update) to follow.

Simple answer – parameterise it. Have the browser request “create me a new event, then refresh parts a, b, and c of my page”. That functionality is now part of Hobo and seems to work great. As well as getting us closer to a fully generic controller, this idea has also yielded a very simple approach to ajax.

Another problem I’ve hit is that sometimes an application feature requires a whole graph of related models be created in one go. The solution to that one has been to extend the way ActiveRecord handles the hash you pass to MyModel.new. With Hobo’s ActiveRecord extensions, that single call to new can set up arbitrary relationships with other models, either existing or new.

This post is light on technical details (all will be revealed), but it sets the stage for what I want to waffle about next — Hobo’s support for ajax. I think Hobo’s approach will make ajax programming easier than with anything else out there.

Just had a good week delivering a Rails training course for Skills Matter in London, but of course that meant little progress with Hobo. Next week it’s full steam ahead!

Why? Rails already has a bunch of mechanisms for re-use within views. Namely: layouts, partials and helpers. Each serves a different purpose, and yet, IMHO, there’s still a gap. I find that small fragments of mark-up tend to crop up over and over in my views. Yes I could extract them into paritals or helpers, but I find myself disinclined to do so.

Helpers are good for small bits of dynamic content, but not so convenient for re-use of HTML fragments – I don’t really want to embed loads of HTML in strings in Ruby source. Nor do I want to make excessive use of the tag helper. I want to put mark-up in mark-up files.

So partials would be appropriate. But each partial needs it’s own file, which again discourages me from making heavy use of them.

Finally, and prefixed with a big ol’ IMHO — dang are those ERB scriptlets ever ugly! If you ever needed to call a helper passing in HTML mark-up in the parameters, that’s HTML within Ruby within HTML — not pretty. Hey, it works right? This is not a criticism of ERB. The syntax used (<%= ... %>) is like that for a reason. ERB doesn’t need fixing. DRYML supports ERB scriptlets, but allows you to hide them away behind nice clean custom tags, leaving you with beautiful clean templates [swoon] where you can see what’s going on at a glance.

Defining a tag essentially just creates a new helper method for you, and a use of that tag is nothing more than a call to that helper. This is just syntax. Witness:

hello_world.dryml

<def tag="hello">Hello World!</def>

<p>Here it is: <hello/></p>

<p>And here it is again: <%= hello %></p>

Groovy baby :-)

(check out the Hello World post to see how to get set up so you can try this)

And just as you can call a tag from Ruby instead of mark-up, you can define them in Ruby if you wish. You can do so in your helpers. Try this

app/helpers/application_helper.rb

module ApplicationHelper

  include Hobo::DefineTags

  def_tag :from_ruby do
    "As easy as that eh?"
  end

end

That will give you a <from_ruby/> tag in all of your DRYML templates. If your tag contains more code than mark-up, it’s cleaner to define it in a module like this.

You could even define the tag in a helper module and call it from an ERB scriptlet, but that would be kinda strange… Hey — knock yourself out, it’s all good :-)

I’m trying not to get ahead of myself because there’s a Quick Guide to DRYML coming right up. I just want to show you that this is just a thin layer on top of your regular Rails template. They’re just purdier is all.

Actually there’s a lot more under the hood in DRYML — it’s not just syntax. We’ll get there.

Bud Fox: How much is enough?

Gordon Gekko: It’s not a question of enough, pal. It’s a zero sum game, somebody wins, somebody loses. Money itself isn’t lost or made, it’s simply transferred from one perception to another.

I’m a bit of a Gordon Gekko myself when it comes to programming. Greed is good. Remember? Greed works. I’m greedy for speed. Seems to me pretty reasonable that I should be able to build a nice looking, usable, fully-ajaxified database app in what? A couple of hours? That would be fast enough. Then I’d be satisfied [grin].

To be clear, I’m only talking about a basic front end to a database here. You know the drill: create, update, delete, link things together. A blog, a simple content management system, a shop, an events diary, an issue tracker… The list goes on and on. All these kinds of sites are overwhelmingly similar. If I’m having to sweat a lot of code to get a site like this working, surely I must be repeating myself from the last site I built? Real programmers don’t repeat themselves. (Got that? I said: real programmers don’t repeat themselves)

Of course, any interesting web app is going to need a bunch of code to make it tick. Your job aint going anywhere just yet Mr. Programmer (except to Bangalore of course). I just don’t want to waste my life hacking on uninteresting sites. Or to be more accurate, on the uninteresting parts (there are a lot!) of my otherwise brain-meltingly exciting sites.

In fact there’s a bunch of stuff out there that will build a database front-end for you, in an instant. The Python world has Django, and the same for Rails is not far off. The Streamlined guys seem to be doing a great job. With one caveat: it’s called an Admin Interface. Not for public consumption.

So if an admin interface can be derived automatically from the data model, surely a genuine end-user interface can’t take that long? They are mere mortals, I believe, these administrators.

This is exactly what Hobo is trying to achieve – to take the automation of the out-of-the-box admin interface along with the flexibility of hand-coded views, and mix ‘em up in a big ‘ol pot to see what comes out.

Like the Scriptaculous guys have it – it’s about the user interface, baby!

This pretty much reflects my experience with hacking on Rails apps. The data-layer has been reduced to blissful simplicity. The move to CRUD as a design strategy makes the idea of a one-size-fits-all controller look pretty doable. But the views… I seem to spend 80% of my time hacking view code.

Not for much longer! :-)

Soon I’ll be able to say:

<page title="search">
  <hey_cut_the_drama_and_give_me_a_search_page_already/>
</page>

<page tile="Search">
  <hey_cut_the_drama_and_give_me_a_search_page_already/>
</page>

Of course, it’s all open-source so if it works, please help yourselves :-)

Feeling greedy?

(p.s. What a load of old waffle eh?! I’ll make sure the next post has some actual content. Y’know, like, er, code and stuff)