I would like to start by addressing my experiences with CoffeeScript. My opinion of it is of ambivalence. I’ve used it on a project, I’ve played with and in the end I’ve come out with the opinion of “it’s ok”. It didn’t blow me away, but at the same time I can see why so many people like. It offers some really cool features that I really wish JavaScript had and you can cut down on the amount of code you have to write. On the other hand the apps I tend to write don’t tend to be that JavaScript heavy that I really needed to reach out for something like CoffeeScript.

So, how do I feel about CoffeeScript being included with Rails? Well, I’ll get to that. Let’s go over some of the most common arguments I’ve heard from people this week about why they’re anti-CoffeeScript in Rails.

“It’s an abstraction layer of JavaScript! JavaScript isn’t that bad, why can’t you just write JavaScript?”

“It’s going to be a hinderance to newbies. It’ll be too much of a learning curve!”

Let’s start with that second point first, shall we? I agree, it does represent a new element that needs to be learned when coming to Rails. But here’s the pretty nifty thing about how it’s all implemented in Rails. In order to actually use CoffeeScript in Rails you have to create your files named foo.js.coffee if, however, you just name your file foo.js then, guess what? You will have to write plain old JavaScript! Seems like newbies, and those who don’t like CoffeeScript, can just keep writing plain old JavaScript without anything stopping them at all.

Now, let’s talk about the abstraction layer argument. Yes, CoffeeScript is an abstraction on top of JavaScript, but let’s take a look at a few other parts of the Rails stack and see how they hold up against this argument.

Here’s a fairly common Rails stack:

• ActiveRecord
• Haml
• jQuery
• RSpec

What do all those things have in common? Well, they’re all abstraction layers that sit on top of something else, don’t they? Let’s look at that list again?

• ActiveRecord – SQL (Structured Query Language)
• Haml – HTML
• jQuery – JavaScript, you could just as easily hand roll those AJAX calls in pure JavaScript.
• RSpec – Test/Unit

What I’ve found funny about the particular argument is that I’ve heard it MOST from those who use things like HAML, which is a DEFINITELY an abstraction layer that sits on top of HTML. See where I’m going with this one? Good, I don’t want to belabor the point.

So, finally, where do I stand on this whole thing? Well, I view like it Test/Unit and Prototype. Those are both the current standard (although jQuery will replace Prototype in 3.1) and I don’t like or use either of them. Instead I configure Rails to use jQuery and RSpec. I don’t like Haml, but those that do simply replace ERB with Haml and they move on with their day. So my take is this, it’s there, it’s included. Use it if you like, or don’t. Is it really that big a deal? No, it really isn’t. If Rails dropped ERB and went with Haml as the default, would I bitch and moan, probably a bit, but then I’d just install the Rails-ERB gem and move on with my day, just like I do with jQuery and RSpec today.

So sit back, relax, use the libraries that you want to use, Rails let’s you do that. Oh, while you’re relaxing why not try out CoffeeScript, who knows, you might just enjoy it. Or not.

Incompatibility

• Gone is <%= @content_for_layout %> in layouts. In is <%= yield_to :view %>.
• Gone is render(options_hash) in controllers/views. In is render(type, value, options_hash)
  Examples:
  render(:action => :new) is now render(:action, :new)
  render(:url => “http://www.mackframework.com”, :parameters => {:message => “hi”}) is now render(:url, “http://www.mackframework.com”, :parameters => {:message => “hi”})
• Gone is *.xml.erb. In is *.xml.builder

Render Me Softly

In the new rendering engine there are two parts to the system, Mack::Rendering::Type::* objects and Mack::Rendering::Engine::* objects. Let me explain the difference.

Mack::Rendering::Type::*

A type is something like :action, :text, :inline, :url, etc… That is the type of thing you want to do. I want to render an action. I want to render a url, etc… There are classes for each of these types, and you can easily add your own. These types do all sorts of work before they pass it off to an engine, if need be. For example, in the case of Mack::Rendering::Type::Partial the render method does the work of inserting an ‘_’ in the appropriate place, so the file can found.

<%= render(:partial, "users/form") %> # => "users/_form"

Once that happens it tries to find an engine to process the partial.

Mack::Rendering::Engine::*

An engine does the actual work of rendering the io, with the binding of the Mack::Rendering::ViewTemplate object, it’s been given by the results of the render method in the Mack::Rendering::Type::* object. Engine examples would be, Erubis (ERB), Markaby, Haml, and Builder::XmlMarkup, all of which are included with Mack in this release. New engines can easily be plugged in and registered with the system.

Coming soon a tutorial on adding PDF::Writer support using the new system.

The biggest thing, however, is what’s been causing a stir online now for the past few days, I’ve split out the ORM support into separate gems. I’m not going to go over it again, you can find all the details here: http://www.mackframework.com/2008/05/04/orms-and-mack/

Needless to say this is a good release to get, if not for the bug fixes alone, but for the great db:create rake tasks that are now in there. Thanks, again, to Darsono Sutedja for his great contributions.

Changelog

• Added rake db:create and db:create:all rake tasks.
• Refactored out constants, such as MACK_ROOT and MACK_ENV and made them into Mack::Configuration.env, Mack::Configuration.root, etc…
• Added test:stats and test:coverage Rake tasks.
• Removed support for ActiveRecord and DataMapper and moved them into their own gems.
• Fixed a bug where yields in ERB weren’t giving the desired results.
• DataMapper database.yml file can now be nested, and is generated as such.
• Cleaned up some tests, and refactored the HTML generation stuff.
• Fixed a bug with the scaffold generating ‘bad’ methods instead of ‘post’
• Made error_messages_for more compatible with DataMapper.
• Fixed a bug loading url.rb and uploaded_file.rb found by Phil Darnowsky
• [dsutedja] Render method (in controller_base) now accepts response status code.
• gem: mack_ruby_core_extensions 0.1.23
• gem: genosaurus 1.1.4
• gem: datamapper 0.3.2
• gem: rcov 0.8.1.2.0
• gem: mack-data_mapper 0.5.0
• gem: erubis 2.6.0

There’s been a general overhaul of the generators included with Mack. Mostly, cleaning them up. With that said things like the scaffold, model, and migration generators have been updated to do what a lot of people have been asking for, that is take a ‘cols’ parameter and build out the generated code corrrectly. This really makes life, very, very simple.

There will be a re-written ‘blog’ tutorial coming out soon to make use of this, as well as migration support that’s now part of Mack.

Very exciting stuff! Enjoy!

Changelog:

• Mack now uses Erubis, http://www.kuwata-lab.com/erubis/, for it’s rendering engine instead of ERB. This makes Mack even faster now! Yippie!
• Added rake generate:model name=<model_name> (optional: cols=<col_1>:<col_1_type>,<col_2>:<col_2_type>) This will also create a migration for you.
• Updated rake generate:migration name=<model_name> (optional: cols=<col_1>:<col_1_type>,<col_2>:<col_2_type>) This will create the proper table migration for you.
• Updated rake generate:scaffold to use the ModelGenerator now.
• ScaffoldGenerator now create input fields based on the type of columns, if any, passed in.
• Overall general refactoring of the generator classes.
• Fixed a bug with request logging not, well, logging.
• gem: erubis 2.5.0
• gem: thin 0.8.0

Instead of focusing on what didn’t make it in, let’s talk about what did make it in! There’s some cool stuff in this release.

Format Driven Content

Mack now allows you to drive different content based on the format requested. For example:

/posts – will render app/views/posts/index.html.erb
/posts.html – will also render app/views/posts/index.html.erb
/posts.xml – will render app/views/posts/index.xml.erb – A special note *.xml.erb files, despite their name, do NOT get run through ERB, instead they use the XML Builder library
/posts.js – will render app/views/posts/index.js.erb
etc…

Alternatively, in your action you can now define ‘want’ blocks, to run specific code based on the format. Example:

class PostsController
  def index
    # find all the posts in the system
     @posts = Post.find(:all)
    wants(:html) do
      # this will only be run if html is requested.
      # we need a username for a 'welcome message in the view'
      @username = @user.username
    end
    wants(:xml) do
      # this will only be run if html is requested.
      # find the last published date
      @last_pub_date = Rss.find_last_by_date_by_object(:posts)
    end
  end
end

XML Builder Support

I’m not going to go into this, there is another nice post coming shortly that will explain how to use this library to add RSS to our blog demo. Here’s the post.

Built-in Encryption

In every app I’ve ever built I found the need to use encryption. Whether it’s for encrypting something into a cookie, a password in the database, or a file on disk, we all need encryption, so I’ve baked the crypt gem into Mack.

At the very simple level you can easily do this in your code:

@my_encrypted_value = _encrypt("hello world")

and you’ll be returned a nice pieced of garbled data using the Crypt/Rijndael library. Decrypting is just as easy:

_decrypt(@my_encrypted_value) # => "hello world"

See, I told you it couldn’t be easier. It gets even better you can even define your own ‘worker’ to implement other encryption schemes. It’s as simple as this:

class Mack::Utils::Crypt::HorribleWorker
  def encrypt(value)
    value.reverse
  end
  def decrypt(value)
    value.reverse
  end
end

_encrypt("hello", :horrible) # => "olleh"
_decrypt("decrypt", :horrible) # => "hello"

See how easy that was? You can also do:

@my_encrypted_value = "Hello".encrypt
@my_encrypted_value.decrypt #=> "Hello"

Either way it’s now easy to handle encryption in your funky cool Mack app.

Changelog:

• Ticket: #8 Xml Builder Support
• Ticket: #7 Ability to drive certain content based on ‘format’
• Ticket: #9 Added a global encryption system to make encrypting/decrypting of strings easy to use
• gem: builder 2.1.2
• gem: crypt 1.1.4