Well, it’s finally here, Mack 0.6.0! This release has taken a long time, but I feel that it’s definitely worth it. This has to be the best release of Mack to date. During this release the Mack dev team grew by 100%, Darsono Sutedja, previously a contributor to Mack, is now a full time Mack core team developer! Darsono has done an absolutely great job on this release, thanks Darsono. With that out of the way, let’s jump straight to the good stuff, shall we?

DataMapper 0.9.2 Support

At long last Mack supports DataMapper 0.9.2. Because previous versions of Mack used DataMapper 0.3.2, there is some upgrade work that you’ll need to do, but trust me, it’s worth it. DataMapper 0.9.2 is a gigantic leap forward from 0.3.2. If you have problems installing the data_mapper gem, make sure that you don’t have gems.datamapper.org in your source path for rubygems. You can remove it with the following command:

gem source -r http://gems.datamapper.org 

RSpec Testing Support

RSpec is now the default testing framework for new Mack applications. This innovative testing framework makes it fun, and simple, to do behavior driven development. If you haven’t yet played with RSpec, I would highly recommend it. I wasn’t a big fan of ’spec’ testing prior to meeting Adam French, of DataMapper fame, and he turned me on to the joys of rspec. I think you’ll like it too, if you give it a chance.

mack-more

There is now a mack-more package. This will house all the optional gems available to the Mack framework. This include things like HAML and Markaby support, localization, etc… Use what you want, ignore the rest. This will help keep the core code clean, light, and of course, fast.

Localization/l10n Support

Darsono did a great job with the mack-localization gem. There is now optional support for internationalization in Mack applications. Check out the gem, it’s definitely worth it if you need to support multiple languages for your web application.

Much, much more!

Of course, there’s a lot more Mack than the stuff I just mentioned, there’s tons of bug fixes, some code clean up, some API changes, transactional testing support, the ability to catch specific errors in routes and have them diverted to a controller/action for handling.

There is a great wiki entry on upgrading your existing Mack project to 0.6.0 here. I highly recommend reading it whether or not you have an existing Mack application.

With this release the Mack team is also fully embracing Lighthouse. If you find bugs, or have suggestions please visit http://lighthouse.mackframework.com and log them there. You’ll also find the list of features that will eventually be added to Mack.

Changelog:

• INCOMPATIBILITY NOTICE: Moved Mack::Configuration.root to Mack.root
• INCOMPATIBILITY NOTICE: Moved Mack::Configuration.env to Mack.env
• INCOMPATIBILITY NOTICE: Mack::Configuration.* path methods no longer exist. Use mack-paths instead.
• INCOMPATIBILITY NOTICE: Dropped mack_ruby_core_extensions in favor or mack-facets
• INCOMPATIBILITY NOTICE: Mack::Controller::Base is now Mack::Controller (and it’s now a module)
• INCOMPATIBILITY NOTICE: Haml renderer is now part of mack-more.
• INCOMPATIBILITY NOTICE: Markaby renderer is now part of mack-more.
• INCOMPATIBILITY NOTICE: Changed request param’s accessor routine, from params(key) to params[key]
• INCOMPATIBILITY NOTICE: Test::Unit::TestCase is no longer the default testing framework, RSpec is. If you wish to use Test::Unit::TestCase add the following config parameter to your config/app_config/default.yml file:
    mack::testing_framework: test_case
• INCOMPATIBILITY NOTICE: ENV["_mack_env"] and ENV["_mack_root"] are no longer supported, please use ENV["MACK_ENV"] and ENV["MACK_ROOT"], or just Mack.env and Mack.root
• INCOMPATIBILITY NOTICE: MACK_DEFAULT_LOGGER constant is no longer available. Please use Mack.logger instead.
• INCOMPATIBILITY NOTICE: The ApplicationHelper module is now deprecated. Please move view level helpers into Mack::ViewHelpers::* and controller helpers into Mack::ControllerHelpers::<controller_name>
• thin.ru and thin.yml are no longer needed, you may delete them.
• RSpec assertions are now automatically added.
• Added a Mack::Testing::Response class to make testing of responses easier.
• moved test_extensions to testing and added the module Testing to the files in it.
• Added a dependency on mack-more
• Added a set of Rake tasks to update existing Mack applications.
• [#30] Added Mack::Logging::Filter to filter out unwanted parameters from the logs.
• In routing you can now define a route that will catch an Exception from another controller.
• ORM will not be initialized if the app never specify which ORM to use.
• All Mack unit tests are now written using rspec-1.1.4.
• mack command now takes an optional -t flag to determine which testing framework to use–value could be test_case or rspec [default]
• new setting added to app_config: testing_framework
• gem: cachetastic 1.7.2
• gem: application_configuration 1.5.0
• gem: erubis 2.6.2
• gem: genosaurus 1.2.1
• gem: thin 0.8.2
• gem: rspec 1.1.4

So a lot has been made in the last few days about my decision to drop ActiveRecord’s native support in Mack. People have asked why can’t I keep what I already have in regards to support for ActiveRecord, and why can’t I support Sequel. So, I’ve decided to compromise.

In the next version of Mack, which should be out in the next day or two, I’ve broken out support for ActiveRecord and DataMapper into their own gems, http://github.com/markbates/mack-orm/tree/master. That means you’ll be able to still use ActiveRecord, if you want. The default ORM, however, will be DataMapper. That’s what you’ll get out of the box with Mack.

Now, keeping with my original post, I’ll be actively maintaining the mack-data_mapper gem, and when I can I’ll make similar changes to the mack-active_record, but I’m not promising anything. Now the good thing here is that since the repos for these gems are on GitHub, anyone can contribute changes/additions to them. I’ve even put a stub in there for Sequel support, that’s definitely something someone else will have to support.

This also has a nice advantage in keeping the Mack core clean and simple. Hopefully this will all lead to faster development time turn around for Mack.

It’s also worth noting that when I talk about ‘native’ support, all I mean is some Rake tasks and some generators. There’s nothing stopping anyone from using ANY ORM with Mack. You could even create your own, if you really wanted to.

Here’s to hoping this makes everyone happy!

So after my post about dropping ActiveRecord for DataMapper, I’ve received some very interesting feedback, mostly good, which is great. The best comment I received was from Sam Smoot, lead developer of DataMapper. Sam offered to give me commit access to the DataMapper repos on GitHub.

I took Sam up on his offer and I’ve already made several contributions. This is GREAT news for the Mack Framework. When the best technologies start working in concert, only good things can happen.

I’m really excited about what’s happening with DataMapper 0.9.0, and I know it’s only going to make Mack a better framework. I’ve already started working on upgrading Mack to use, the yet unreleased, DataMapper 0.9.0 code base.

I’ll keep you all posted.

I’ve been wrestling with this for a while now, and I’ve finally made my peace with it. I’ve decided to remove native support for ActiveRecord from Mack. From now on it’ll be DataMapper by default, out of the box. This was not an easy decision to make. Essentially it boils down to one of the key tenants of Mack, use the best of breed technologies to build a best of breed framework. I truly feel that DataMapper, especially when it hits the 0.9.0 release, is the best ORM, and persistence, system out there. I also feel that it is a natural fit for the Mack framework.

The other reason why I made the decision was time. It’s very time consuming to constantly maintain two different, and with 0.9.0 extremely different, ORMs. There are plenty of features that I could’ve done faster, had I only been supporting the one ORM.

Now I know I might come under fire from some people for this, but it’s a decision that I think is best for the framework. If some enterprising developer out there wants to build a plugin, or a gem, that adds ActiveRecord support, then I’m all for it! Please do!

The question you’re probably asking yourself now, is when will this be happening. It’ll be happening in the next release of Mack, probably the end of this week or the beginning of next week.

Again, I’m sorry for those of you were hoping to use ActiveRecord with Mack. Check out DataMapper, I’m sure you’ll be happy with it.

Comments?

This post has moved to the wiki @ http://wiki.mackframework.com/index.php/Blog%20Tutorial