Release 0.8.3
Thanks to the cold and snowy New England winter this year, I’ve been able to devote quite a bit of time to getting Mack to run on Ruby 1.9, so with that said, here’s the 0.8.3 release of Mack, featuring… TADA… Ruby 1.9!! Of course there are a few other features and improvements in this release. Here’s a quick run down:
Ruby 1.9
The big one. Mack runs very well on Ruby 1.9, unfortunately I can’t say the same thing about some other frameworks. I’ve had some run ins with DataMapper on 1.9, but I’m sure those will be ironed out shortly.
A few weeks ago I announced I was working on getting Ruby 1.9 support for all my gems and libraries. I started out with Configatron, then upgraded Cachetastic and Genosaurus. Now Mack is 1.9 compatible. When I made the announcement the guys at RailsEnvy picked up on it and said that I made a call to arms to the community to pick up 1.9 support. Now granted, I didn’t actually say those words, but I think the intent was there, so I’m going to now officially say those words. This is a ‘call to arms’ to the Ruby community to upgrade their gems, plugins, libraries, frameworks, etc… to work on Ruby 1.9. I’ve done it, and I can tell you, it’s not that tough. Just use multiruby, and you’re off and running.
ActiveSupport In, Facets Out
What with the world getting smaller these days, well, at least the world of Ruby web frameworks. A lot of great work is going into refactoring ActiveSupport and making it faster, better, and smaller. Because of that and the fact that every time a new release of Facets comes out it breaks a whole lot of stuff, I’ve decided to use ActiveSupport as the basis of the mack-facets gem. So basically mack-facets is just ActiveSupport with a few more enhancements.
JavaScript Effects
Thanks to the tireless efforts of Gerardo Pis-Lopez, mack-javascript, has been upgraded to add helpers methods for effects for both Prototype/Scriptaculous and jQuery. Thank you to Gerardo for the much needed upgraded to mack-javascript.
Upgrades
Mack has been upgraded to use Rack 0.9.1, DataMapper 0.9.9, and a few other smaller gems.
Changelog:
- [#243] Upgraded to Rack 0.9.1
- [#242] Upgraded to DataMapper 0.9.9
- [#241] Removed dependency on Facets
- [#239] Add do_sqlite3 to gems.rb
- [#166] Effects for mack-javascript
- [#133] Added Form Builders
- [#22] Ruby 1.9 Support
- gem: rack 0.9.1
- gem: rspec 1.1.12
- gem: configatron 2.2.2
- gem: cachetastic 2.1.2
- gem: data_mapper 0.9.9
- gem: addressable 2.0.1
- gem: extlib 0.9.9
Tags: data_mapper, gerado pis-lopez, jquery, mack, prototype, rack, release, ruby 1.9

January 18th, 2009 at 3:17 pm
So, what is Mack anyway?
January 20th, 2009 at 4:55 am
I just wanted to drop a note to let everyone using the Mack Framework that DataMapper 0.9.10 was released today and now provides Ruby 1.9 support.
January 21st, 2009 at 1:59 pm
@Geezzzer:
http://www.mackery.com/
January 27th, 2009 at 6:16 pm
I have been trying to look for more documentation than currently exists in the user manual, but I am finding it very hard to track any down.
What I am looking for is things like, if I want to use haml instead of erb, what do I need to do? Do I have to require a gem in some file? or set it in a config file somewhere.
I would love to jump in and build an app with this, but the lack of documentation and resources to find out the things that I want is very frustrating.
Any help would be welcome.
Thanks
January 27th, 2009 at 10:56 pm
Hi Philip, yeah, the documentation definitely needs work. To quote the Beatles, it’s getting better all the time. I’ve gone and added a section on mack-haml, just for you.
http://www.mackery.com/mack_more/haml/index
That should help you, it’s pretty darn easy. Let me know if you have any questions.
January 28th, 2009 at 12:08 am
Thanks for that.
One thing that I have noticed of all frameworks, not just this one, is that when there is a default there is nowhere that shows it is a default in the running app.
I just think that for the sake of clarity, that if something is a default it is a default because there is a line in a config file, in the running app that says something similar to what you have for the haml example you put up
require_gems do |gem|
gem.add “mack-haml”, :libs => “mack-haml”
end
But this should be for every default action in the running app. And if it isn’t there then the individual things that make up app wont work.
I see this as having 2 advantages
1. Anyone creating an app, especially for the first time like I did can see exactly what is being loaded by just looking at one file
2. People can rip out and put in whatever gems they want, and it can be more customised stack of applications.
But only really looking at this app really for a day, I don’t know if the above makes sense to do. I just think that if this was how frameworks laid out themselves it would make a lot more sense to me, and less like a black box that magic things happen in.
Just my cents.
But again thanks for the piece of documentation you provided
January 28th, 2009 at 12:28 am
By the way, what is the difference between the first parameter, and the one that is passed in that is called :libs, are they not just one and the same?
January 28th, 2009 at 1:52 am
Okay, just used the haml thing and it seemed to work, all except the layout. When I use a layout with an erb extension it works fine, but when I use one with a haml extension it gives me the following
/progs/web/test_app/app/views/layouts/application.html.*
Maybe a small bug where views only expect erb layouts?