Sample Rails Application – A demo for the ajax based drag drop tree in rubyonrails

Posted over 7 years back at Ajax on Rails


I have provided the source code of the ajax based drag drop tree in rubyonrails in one of my previous posts.
I found some of the people are getting problems to incorporate the code into their running applications so i am providing a sample rails application in which all the code for tree is already been placed well.
However the code written seems to be lagged behind the current trends followed in rails development coz of the fire growth of rails itself, but its simply that when i wrote this tree i was very new to rails so you may find the code looks like an old wine but still tastes good to go with.

CHECK THIS OUT…

Four simple steps to make the tree working…

  1. DOWNLOAD the sample application. (let me know if you are getting any error in downloading the application.)
  2. Create a test database in mysql or modify the file /config/database.yml according to the database and user u need.
  3. Run the command
    ajaxtree> rake db:migrate

    from the application root.

  4. Run the application server by running
    ajaxtree> ruby script/server

    and watch the working tree at http://localhost:3000

Red, green, refactor. Red, green, refactor

Posted over 7 years back at The Hobo Blog

That title is pinched blatantly from the excellent Test Driven Development course by fellow Skills Matter instructor and agile programming luminary Craig Larman. Can you still say red/green when you run your tests on the command line? grinhen you run them from Emacs – a very big thanks to this chap).

Yes it’s test-driven-development week here at Hobo central (the above banner, btw, is the tranquil view from Hobo HQ).

After lots of little projects where I’ve been, shall we say, relaxed about my approach to testing, I’m getting back into the swing of a strict test-first approach. My initial reaction – boy does it slow you down! I know without a doubt though, that the perceived slow-down is a temporary thing. The double-whammy of keeping bugs at bay, and giving me the confidence to refactor properly, means the quality-bar stays way-up. Without that it wouldn’t be long before development would simply grind to halt - collapsing under the weight of it’s own unchecked complexity.

So patience is the order of the day – slow but steady wins the race :-)

All this is a rather long-winded way of saying that I haven’t yet put together a simple ajax demo to blog about. I tend to get kinda single-minded when development isn’t going as fast as I’d like it to (it never is!). Fortunately there’s a small rodent with sharp teeth reminding me that there’s more to a project than just coding :-).

Let’s see how things go today. I’m working on the standard tag-library which needs to be as generic as it possibly can be. It turns out I’m not so much building it out (adding tags) as building it “in” (getting the basic set of tags just right). If I make good progress today I’ll see if I can’t knock up that ajax demo for you.

Red, green, refactor. Red, green, refactor

Posted over 7 years back at The Hobo Blog

That title is pinched blatantly from the excellent Test Driven Development course by fellow Skills Matter instructor and agile programming luminary Craig Larman. Can you still say red/green when you run your tests on the command line? grinhen you run them from Emacs – a very big thanks to this chap).

Yes it’s test-driven-development week here at Hobo central (the above banner, btw, is the tranquil view from Hobo HQ).

After lots of little projects where I’ve been, shall we say, relaxed about my approach to testing, I’m getting back into the swing of a strict test-first approach. My initial reaction – boy does it slow you down! I know without a doubt though, that the perceived slow-down is a temporary thing. The double-whammy of keeping bugs at bay, and giving me the confidence to refactor properly, means the quality-bar stays way-up. Without that it wouldn’t be long before development would simply grind to halt - collapsing under the weight of it’s own unchecked complexity.

So patience is the order of the day – slow but steady wins the race :-)

All this is a rather long-winded way of saying that I haven’t yet put together a simple ajax demo to blog about. I tend to get kinda single-minded when development isn’t going as fast as I’d like it to (it never is!). Fortunately there’s a small rodent with sharp teeth reminding me that there’s more to a project than just coding :-).

Let’s see how things go today. I’m working on the standard tag-library which needs to be as generic as it possibly can be. It turns out I’m not so much building it out (adding tags) as building it “in” (getting the basic set of tags just right). If I make good progress today I’ll see if I can’t knock up that ajax demo for you.

Happy Thanksgiving: Rails 1.2 RC 1 Arrives!

Posted over 7 years back at zerosum dirt(nap) - Home

In case you haven’t already heard, Rails 1.2 RC 1 is out. Click here for details. Taking center stage this time seems to be the push towards creating RESTful services. Very nice. Also updates to Prototype and Script.aculo.us and, whoah, some deprecations.

So after you finish wolfing down that enormous, weight-altering dinner, sit back in your tryptophan-induced haze and take a gander over the new stuff. Me? Nah. I’m headed up to the Great White North for a couple of Internet-free days. But I know what I’ll be doing when I get back… Enjoy!

EdgeCase - Ruby on Rails Podcast

Posted over 7 years back at Ruby on Rails Podcast

A chat with the members of EdgeCase, a Ruby consulting firm in Columbus, Ohio.

Java in The Land of Make Believe

Posted over 7 years back at Ryan Tomayko's Writings

Steve Anglin, the Java Editorial Director for Apress, in Java GPL'd: Who really cares?:

Open source Java already exists in frameworks and tools like Spring, Seam, Struts, Eclipse, Tomcat, JBoss App server, and many, many more. In the most practical sense to developers, etc… open source Java has been around for a few years now in a very practical and adoptive way.

I sometimes imagine an alternative universe where Java is actually practical. I call it, The Land of Make Believe. Let’s contrast this fictitious universe with the one I currently inhabit, The Real World.

In The Land of Make Believe, here’s how you install Java™ on FreeBSD:

# portinstall java/jdk15

That’s how everything is installed on FreeBSD. There’s no manual downloads, “installers”, EULAs, or barrier to convenience and automation elsewise.

The Real World is slightly different in that you install Java™ like this:

# portinstall java/jdk15
** Port marked as IGNORE: java/jdk15:
Due to licensing restrictions, certain files must be fetched manually.

Please open http://www.sun.com/software/java2/download.html
in a web browser and follow the "Download" link for the
"JDK 5.0".  You will be required to log in and register,
but you can create an account on this page.  After registration and
accepting the Sun Community Source License, download the
SCSL Source file, jdk-1_5_0-src-scsl.zip and the
SCSL Binaries file, jdk-1_5_0-bin-scsl.zip .

In addition, please download the patchset, bsd-jdk15-patches-3.tar.bz2, from
http://www.eyesbeyond.com/freebsddom/java/jdk15.html.

Please place the downloaded file(s) in /usr/ports/distfiles 
and restart the build.
  
*** Error code 1
  
Stop in /usr/ports/java/jdk15.

What that error message basically translates to, for a huge number of developers and admins who appreciate their time and sanity, is that Java will not be installed. It just destroys the single greatest advantage provided by modern Linux and BSD: the package management.

Here’s how you install Java™ on RedHat based distros like Fedora and RHEL:

# yum install java

This will indeed install something that runs most Java programs in both The Real World and The Land of Make Believe but the similarities end there. In the The Real World, the GNU Compiler for the Java Programming Language (GCJ) and its extended runtime GNU Classpath are installed. These Java clones exist for exactly one reason: Java’s license is impractical. Those living in The Land of Make Believe will have never heard of these projects; Sun’s compiler and runtime are installed instead.

In The Real World, installing Sun’s Java on RedHat based systems works like this:

  1. Using a mildly annoyed tone, post a message to the fedora-general mailing list asking what makes Sun so special that installing their stuff should require hopping outside of established process.

  2. Enjoy the history lesson and observe that absolutely no one working at this level thinks that Java’s license is anything other than completely insane.

  3. Follow provided link to JPackage and admire the number of packages these guys have put together.

  4. Ponder how many packages may have been available had installing them been practical.

  5. Ponder how many projects decided to not use Java specifically because they would be this hard to install.

  6. Get setup for building nosrc RPMs.

  7. Learn how to rebuild packages.

  8. At last, install a JDK (this requires another 3 steps of clickity-click-click non-sense, mind).

If you want to get on the bad side of software developers and system admins, the fastest route is to waste their time.

In The Land of Make Believe, the whole idea of “installing Java” is kind of silly. It is installed “out of the box” like C/C++, Perl, Python, Ruby, and other general purpose languages. The reason is that some piece of the base system was written in it. In The Real World, Java is simply not an option for these pieces because it’s impractical.

In The Land of Make Believe, new GNOME applications are often written in Java instead of C#.

In The Land of Make Believe, projects like Jython and JRuby were considered stable and viable alternatives to their C language counterparts a long time ago because running Python or Ruby programs on top of Java would have actually been practical once the language implementation was complete. In The Real World, these projects are mildly useful if you want to add “scripting” to a Java application.

In The Land of Make Believe, the web is dominated by Java because Java is not only technically capable of running everywhere, it actually does run everywhere. In The Real World, the web is dominated by Perl and PHP.

In The Land of Make Believe, nobody really cares about GPL'd Java. In The Real World, nobody really cares about GPL'd Java either, but it has nothing to do with it going GPL.

From my perspective, the GPL puts Java back in the race for potentially useful technologies over the next decade because it makes it possible for Java to stop being such a massive pain in the ass. Whether it reaches that status is yet to be seen but I care about the fact that it is now at least possible.

Prototype vs YUI Connection Manager: Dialog Continued...

Posted over 7 years back at zerosum dirt(nap) - Home

In the last blog entry, I wrote about doing a first pass integration between Rails and the Yahoo UI Library’s Dialog widget. In the event handler for the save action, we created an Ajax.Request object using the Prototype library to make the Ajax call but I didn’t elaborate on why just calling this.submit() in the handler wouldn’t work. Well, the answer is pretty obvious: I wanted to tease out a second article :-).

YUI expects us to set up a callback handler for the success/failure of the XMLHttpRequest request that it generates when this.submit() is called. If you don’t have a callback set up, the client receives the response but just ends up throwing it away. So let’s look into how we need to change our handler to do things the “right” way (according to Yahoo, anyway). We’ll also see how this is somewhat at odds with Prototype and RJS.

YUI’s Connection Manager utility exists to simplify your interface to the XMLHttpRequest object and provides a handler pattern for callbacks. It’s used throughout their library, so let’s use it here. This updated code should obviate the need for using Prototype in the body of the save action handler:

var handleSubmit = function() {
  this.callback = {
    success: function(o) {
      var scriptObj = document.createElement("script");
      scriptObj.setAttribute("type", "text/javascript");
      scriptObj.text = o.responseText;
      document.body.appendChild(scriptObj);
    },
    failure: function(o) { 
      // do something here
      alert(o.responseText);
    }
  };
  this.submit();
}

In the code listing above, we define the callback object to handle the success / failure cases reported by XMLHttpRequest. On success, we’re going to create a new script element in the DOM and load it up with the response that our RJS template renders. Then we have to append the new element to the DOM. Remember, what we’re appending here is really just some more JavaScript that we’ll use to alter the page contents. Here’s the code in that RJS template again (add.rjs), as a reminder:

page.replace_html 'hello_msg', @thing[:name]

Alright, that’s great. But what does the JavaScript code look like that actually gets generated?

try {
  Element.update("hello_msg", "Welcome Interstate Managers");
} catch (e) { 
  alert('RJS error:\n\n' + e.toString()); alert('Element.update(\"hello_msg\", \"sdafdsfsdff\");'); throw e 
}

That Element.update instruction is Prototype’s way of saying “take the DIV identified as hello_msg and replace it’s guts with the string Welcome Interstate Managers”. Of course, that’s just the string we gave it when we serialized our form data and sent it off (see previous article for details). Simple but powerful.

OK so that rocks, but there’s a bit of redundancy here. Yahoo’s Connection Manager utility and Prototype do a lot of the same stuff. That duplication is totally against the DRY spirit we’re going for. Sigh. Now I’m not well versed enough in the finer details to advocate The One True Way here, but I should note that I’m much more experienced with Prototype than I am with the YUI connection manager. Prototype is also much more entrenched in Rails, serving as the basis for both Scriptaculous and RJS, and it looks to remain that way as Sam Stephenson (Prototype’s creator) is part of the Rails core team.

Anyway, the point I’m trying to make is that the Yahoo UI connection manager library adds further unnecessary bloat to our applications, since it’s essentially just replicating what Prototype already does. I’m sure the YUI guys have their reasons for re-implementing this stuff (Prototype isn’t universally well-loved), but it’s kind of unfortunate for Rails developers, who are pretty well married to Prototype at this point. That isn’t to say that the Yahoo stuff is better or worse.

In the meantime, if we want to use YUI’s widgets, we just have to suck it up and eat a little extra pie this holiday season. Maybe it’s worth writing an alternative connection.js to act as a Prototype wrapper. Maybe we could whip up some helper modules to get these excellent UI widgets as well integrated into the Rails framework as the Scriptaculous stuff is. I’m sure this is all very possible, but just need to spend some time digging through the stuff in more detail. In any case, it seems clear that proper RoR integration needs a bit more thought. Add it to the TODO list!

PS the folks at OpenRico have done a nice job providing a set of controls that are very RoR-friendly. Their focus is somewhat different than that of the Yahoo library, more emphasis on behaviors and cinematic effects rather than on widgets, per se. They have a great accordion widget though, and a live grid too (although it currently lacks cell editing support, which is one of the key things we’re looking for).

YUI Dialog On Rails: First Pass

Posted over 7 years back at zerosum dirt(nap) - Home

RoR seamlessly integrates with Prototype and the Scriptaculous library, buying us slick auto-complete fields, sortable lists, some nifty effects and all sorts of other web2.0-ish goodies. But when it comes to more advanced UI toolkit widgets, ones you’d find in desktop app frameworks, like draggable modal dialogs, tabbed panels, and active data grids, it seems hard to beat the library that Yahoo has put together. [That is, unless you want to start mucking with Adobe’s Flex. But that’s a topic for another conversation…]

The Yahoo UI Library has been around for a while now (since February) and I’m just now getting around to playing with it. Unfortunately, there’s no Rails helper module or anything of that sort. But that doesn’t mean we can’t build one ourselves, or at least make them play nice together…

Let’s start with something simple. Oh yeah, I should mention that Sonjaya Tandon covered this same sorta stuff and what I’m doing is based on what I found there, but I’m going to do it a little bit differently, and demonstrate how you can leverage RJS. Here we go:

First, let’s set up a Rails project and create a controller. Call it ExampleController:

class ExampleController < ApplicationController
  layout "standard", :except => :add

  def show
  end

  def add
    @thing = params[:thing]
  end
end

Pretty simple stuff. We’ll need an RHTML view template for the show action, and an RJS template for our add action. We’ll also need a layout that’ll be added to everything but our add action. Let’s take a look at that layout (standard.rhtml):

<html>
<head>
  <title>YUI Tester: <%= controller.action_name %></title>
  <%= javascript_include_tag :defaults %>
  <%= javascript_include_tag "yui/yahoo", "yui/dom", "yui/event", "yui/connection", "yui/dragdrop", "yui/container" %>
  <%= stylesheet_link_tag  'yui/container'%>
  <script language="javascript">
    YAHOO.namespace('yuitest');

    function initDialog() {
      var handleCancel = function() {
        this.cancel();
      }

      var handleSubmit = function() {
        //this.submit();
        new Ajax.Request('/example/add', {asynchronous:true, evalScripts:true, parameters:Form.serialize(myDialogForm)});
        this.hide();
      }

      YAHOO.yuitest.myDialog = new YAHOO.widget.Dialog("dlg", {
        width: "500px",
        modal: true, 
        visible: false,
        fixedcenter: true, 
        constraintoviewport: true, 
        draggable: true });

      var myButtons = [ { text: "Save", handler: handleSubmit, isDefault: true },
        { text: "Cancel", handler: handleCancel } ];    
      YAHOO.yuitest.myDialog.cfg.queueProperty("buttons", myButtons);
      YAHOO.yuitest.myDialog.render();
    }

    function addThing() {
      document.myDialogForm.thing_name.value = "";
      YAHOO.yuitest.myDialog.show();
    }

    YAHOO.util.Event.addListener(window, "load", initDialog);
  </script>
</head>
<body>
  <div id="main">
    <%= @content_for_layout %>
  </div>
</body>
</html>

So there’s a bunch of JavaScript in there. I’m going to work on cleaning all that up and building a helper module later but for now let’s just get something functional.

We’ve copied the relevant YUI library javascripts to our public/javascripts directory, and now we include them in the layout along with our defaults (prototype, etc). We’d want to trim this down to just what we need before deploying an app for real world use of course.

We’re going to create a dialog from the YUI and add two buttons on it (save, cancel) and the corresponding event handlers. We also need to add a function addthing() that will be called when the user clicks on the link in the show template. It will simply reveal our modal dialog. If you’re confused about any of the syntax here, see the YUI docs and tutorials. Lots of good stuff over there, extremely well documented.

Now here’s our show template (show.rhtml):

<div name="hello_msg" id="hello_msg">hello</div><br />
<a href="#" onclick="addThing()">Add Thing</a>
<!-- begin: dialog box -->
<div id="dlg">
  <div class="hd">this is a dialog</div>
  <div class="bd">
    <%= form_tag({:action => :add}, {:name => 'myDialogForm'}) %>
      <label for="thing_name">Thing Name:</label> <%= text_field('thing', 'name') %>
    <%= end_form_tag %>
  </div>
</div>
<!-- end: dialog box -->

Note that the form name (myDialogForm) must match up. Also note that the dlg DIV uses the same name we initialize the dialog to in the layout. This is important, it means the contents of this div are rendered within the modal dialog and are therefore hidden from the view by default. When you click on the ‘Add Something’ link, the dialog will pop up. You’ll be able to drag it around the screen and enter some text in it. Yay. Then you can click save, and it should update the hello_msg DIV. There’s an easier way to do this of course, but we’re going to use RJS because the approach is demonstrative of a lot more powerful stuff you can do, leveraging Rails model data you may have on the backend and perhaps doing some processing or database access before rendering the results. You get the idea.

So when you hit that save button, the code in the submit handler is run. Let’s look at that JavaScript again:

new Ajax.Request('/example/add', {asynchronous:true, evalScripts:true, parameters:Form.serialize(myDialogForm)});
this.hide();

We serialize the data in the form (that one text field) and submit the data asynchronously by making a direct call to Ajax.Request (thanks Prototype!). Then we hide the model dialog again, returning control to the main page. Notice that URL: /example/add. This calls the add action on our ExampleController, which does something important — in theory — and then renders out an RJS template. This RJS template, for our simple example, just replaces the hello_msg div’s inner HTML with whatever it was we typed into that text field. Here’s the RJS template, add.rjs:

page.replace_html 'hello_msg', @thing[:name]

That’s it for now! We’ll revisit this later if I have time, and try to figure out how to wrap it up in a module to make it easier to use and more general purpose.

All You Need is CRUD?

Posted over 7 years back at The Hobo Blog

DHH, as you probably heard, has learnt to stop worrying and love the CRUD. I’m very much in agreement. The idea of replacing the actions add_member and remove_member (or would that be join_group and leave_group?) with Membership#create and Membership#destroy was the final light switch that got me to a place I’d been striving for.

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!

All You Need is CRUD?

Posted over 7 years back at The Hobo Blog

DHH, as you probably heard, has learnt to stop worrying and love the CRUD. I’m very much in agreement. The idea of replacing the actions add_member and remove_member (or would that be join_group and leave_group?) with Membership#create and Membership#destroy was the final light switch that got me to a place I’d been striving for.

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!

250 RadRails Templates

Posted over 7 years back at schadenfreude

Dr. Nic has converted all of the Textmate snippets to RadRails templates. All 250 of them.

RADRails will include these templates in the new version 0.7.2 scheduled to push next week, but if you cant wait, download them now from Dr. Nics new site, www.radrailstemplates.com.

250 RadRails Templates

Posted over 7 years back at schadenfreude

Dr. Nic has converted all of the Textmate snippets to RadRails templates. All 250 of them.

RADRails will include these templates in the new version 0.7.2 scheduled to push next week, but if you cant wait, download them now from Dr. Nics new site, www.radrailstemplates.com.

250 RadRails Templates

Posted over 7 years back at schadenfreude

Dr. Nic has converted all of the Textmate snippets to RadRails templates. All 250 of them.

RADRails will include these templates in the new version 0.7.2 scheduled to push next week, but if you cant wait, download them now from Dr. Nics new site, www.radrailstemplates.com.

RJS templates without the R!

Posted over 7 years back at Luke Redpath - Home

In terms of making AJAX applications easier to develop, RJS templates are one of the most significant additions to Rails over the past year. They were far more elegant than adding AJAX callback hooks throughout your main RHTML templates (which was just plain ugly) and it let you get access to your model data in your JavaScript response easily. For many, the killer feature was being able to write your AJAX response behaviour in Ruby — one language to rule them all. The forthcoming Simply Helpful plugin takes this even further. However, not everybody is as keen on RJS templates and a new plugin by Dan Webb seeks to change the way you write your AJAX functionality in Rails.

Dan and I have had several discussions over a few beers about RJS and Dan being the JavaScript wizard that he is was of the opinion that writing JavaScript behaviour in Ruby was an abstraction too far. His reasoning was simple: JavaScript when used correctly can be a powerful language and adding a Ruby API on top was an extra layer of magic that just wasn’t necessary. Whilst he made a fair point, I still felt that RJS was infintely better than the old way of doing things and that its pros outweighed its cons…until now.

The main con with RJS is that you are depending on another layer and if that layer isn’t complete you have to revert to JavaScript anyway — you can do this in RJS by using page.call but this is ugly and really highlights its shortcomings. It would probably be fair to say that RJS as it is currently implemented, is a leaky abstraction. Not only that, but RJS is tightly coupled to the Prototype JS library and Scriptaculous – for fans of one of the many other JS core/effects libraries out there you are left with either the option of trying to port RJS to your library of choice, using page.call commands or resorting to the old callbacks method.

I was somewhat blinded by the “cool” factor of writing my JS behaviours in Ruby — after all I’m a Ruby programmer first and a JavaScript guy second. But when I really think about it, all RJS does is limit me when I want to do anything outside the simple cases that RJS caters for. But the idea of returning a behavioural response from a template is an excellent one and that has always been the overriding factor for me.

As of today, a new option has become available in the form of a new plugin courtesy of Dan – MinusR: RJS templates, without the R! Thats right, RJS templates that let you write your behaviour in JavaScript instead of Ruby. Not only that, but you can still get access to your model data (or other things such as helpers) by embedding ERb — MinusR comes with a js() helper method that encodes the output of your ERb output block in JSON. And finally, you can use whatever JS library you like.

So check it out and start embracing JavaScript. Also check out Dan’s blog post about MinusR.

The REST Dialogues

Posted over 7 years back at Ryan Tomayko's Writings

I'm not sure what it is about REST that requires use of The Dialogue but it worked for me and, judging by Sam’s Meme Map, it’s definitely working in Duncan Cragg’s The REST Dialogues and Pete Lacey’s The S stands for Simple.

If Dialogues aren’t your style, Bill Higgins has a new two part series on Ajax and REST: Part 1 and Part 2.

It’s times like these I wish I was still in heavy research, discovery, and advocacy mode with REST and Web Architecture. I've been spending the past year deep in the database, which feels like the other side of the development universe.