The Devel!

Todo: Compiled KRJS

This template_optimizer plugin looks great. If it can compile for KRJS too, that'll remove its only drawback of slower rendering speed due to method inspection. Any one with a free hand to give it a try?

KRJS Explained

Regarding KRJS, I've been asked "Hmm.. so you moved the javascript to the controller... what's the benefit?". I'll try to briefly illustrate the benefits here with some Rails/RJS code - the codes in this example are broken, bugs or simply wrong but that's not the point - hopefully you'll get the drift.

The Problem: Given a textfield and a blank div in Rails, let's do a google suggest-ish feature
<%= text_field_tag 'query' %>
<div id="placeholder"></div>

Method #1
1. observe your textfield with javascript:
<script>
  // every 3 seconds, check changes typed into textfield
  my_observer('query', 3, 'my_call_to_server');

  // when called, sends server a request and updates HTML with
  // response data
  function my_call_to_server(query) {
    data = Ajax.get("http://host:port/my_script?query=" + query);
    getElementById('placeholder').innerHtml = data;
  }
</script>

But let's be fair, with Rails can cut it down and even get cross-browser compatibility:
<%=
observe_field('query',
  { :url => { :action => ' my_script'},
  :frequency => 3,
  :with =>'query',
  :update => ' placeholder')
%>

2. Next, handle the Ajax.get on server and spits out HTML.
def my_script
  search_results  = search_for(params['query'])
  render text: => search_results.to_html
end

Notice the bold portions, these will come back to haunt you when you have many ajax pages - because you're forced to tie up the whole logic (observe 'query' every 3 seconds, send to server 'my_script', update 'placeholder') all inside the HTML template. Dang! These will haunt you when you need to change or add logic (I'm sure you've experienced it before)

Method #2
1. Again, observe your textfield (notice the omitted :update option)
<%=
observe_field('query ',
  { :url => { :action => 'my_script '},
  :frequency => 3,
  :with =>' query')
%>

2. Handle the Ajax.get on server and use RJS to spit out JS (calling page will execute):
def my_script
  search_results  = search_for(params['query'])
  render update do |page|
    page.replace_html :placeholder, search_results.to_html

    # 2 new whiz-bang features!
    page.replace_html :title, "Suggestions for #{params['query']}"
    page.hide :advertisement_div if
      User.find(@session[:user_id]).name == 'George'
  end
end

Notice lesser amount of bold portions in the template? No more hard coding to update 'placeholder', we're saying it only at the server side. In fact, its so easy to add more / change JS events with RJS, that I had easily added 2 extra features without any the template changes! To introduce / change features in method #1, you would have to modify the html template.

Now, notice that last extra feature... It roughly means "Find current user in database, if the name is George, send an extra javascript event to hide the advertisement div ". Imagine the code you have to juggle if we're doing this on client side (method #1)!!

Method #3
NOW.. Let's have fun with KRJS
1.
2. Handle the Ajax.get on server and use RJS to spit out JS (calling page will execute):
def on_query_change_3
  # same code as method #2...
end

Hey! There's no Step 1(tm). And step 2 is identical to method #2 (all benefits of RJS) except that our function has a specific naming convention. Absolutely no need to touch your template at all! The necessary javascripts in the HTML are inserted automatically when the template is rendered.

Let's say we decide to change the JS event to onblur instead of observing every 3 seconds... come, think what has to be done if we're using method #1 or #2? Ready? Change 1 file? 2 files? remove observe_field method, and replace with onblur event?...

In KRJS, you simply rename your controller handler:
def on_query_blur
  # same code as method #2...
end

Now, its not really performant right now... the time-savings is mostly conceptual as well as on the development time. The exact implementation could be evolved, no issue:

• detect external on_xxx.rjs files instead of clogging the controller with on_xxx methods 
• different behavior when in production mode
• rake task to compile for production (faster to render)

With KRJS, I can see lots of code-cutting with the many RJS examples out there. Patches are welcome. 

KRJS: RJS without messing the Views

RJS is great and awesome. I use it quite regularly now. With RJS, I don't have to deal with which parts of the page to update in the rhtml files - I get to decide whilst in my controller using the nice and elegant render :update. Sweet.

But part of me wished I didn't have to even decide which page elements are to be ajaxified. I'd wish I could more easily enable a link, form or button to make ajax calls without going back and touching my html...

Oh well.

Introducing the KRJS plugin, with less than 60 lines of patch to Rails' ActionPack itself (which probably means bugs are aplenty, would slow production sites to a crawl, and that its fresh from the oven too)

To see KRJS in action (so what does it do?), generate a blank controller and index action:

./script/generate controller Sample index

Give it a decent layout (include javascripts) by creating the file app/views/layouts/sample.rhtml

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
     "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
   <html>
   <head>
     <%= javascript_include_tag :defaults %>
   </head>
   <body>
   <%= @content_for_layout %>
   </body>
   </html> 

Create a sample form:

<%= form_tag({:action => 'submit'}, {:id => 'form'}) %>
     <%= text_field 'account', 'login', :id => 'account-new-login' %><br />
     <%= submit_tag 'Login' %>
   <%= end_form_tag %> 

This will be the last time we're touch the Views. If you visit the page now, you should see a simple form. This is the most basic Rails app. It will be our mickey mouse app for this session:

Clicking on Login leads you to an even simpler error page:

This is because we didn't have any code to handle the form submit. Don't let that stop us web2.0-ers, let's ajaxify it anyways! First, install the KRJS plugin

./script/plugin install http://choonkeat.svnrepository.com/svn/rails-plugins/krjs/

and restart your server.

Now, try to view the page, and click on the Login button.... same error page. Good! That means KRJS didn't mess up the original app. Now let's add a new method into the controller, app/controllers/sample_controller.rb

  def on_form_submit
       render :update do |page|
         page.insert_html :after, 'form', CGI.escapeHTML(params.inspect)
       end
     end

 

Refresh the page, and click on Login

As you can see, the form has become ajaxified - to update the page instead of sending the browser to a new location - by merely adding a new corresponding method in the controller! How about adding this to the controller:

 

  def on_account_login_blur
       render :update do |page|
         page.insert_html :after, 'form', CGI.escapeHTML(params.inspect)
       end
     end

 

Refresh the page, type something into the textfield and TAB away from the field:

Yea, KRJS registers onBlur events as well. In fact, it'll register onClick, onSubmit, onWatever, onYouwant because it doesn't really care. All that matters is your HTML element's ID attribute. KRJS currently identifies xhr actions by naming conventions, hence it will probably be most convenient to be used with dashed_dom_id plugin. 

Go ahead, give it a spin. I'm going to sleep.. hope I don't wake into a world of horror...

[Updated plugin links]