The Mack source tree is now hosted on GitHub.com
http://github.com/markbates/mack
If you would like to pull it down you can clone it with:
git://github.com/markbates/mack.git
For those of you interested in contributing you can create an account with GitHub, fork the Mack project, go nuts with your changes, and then send me a pull request. It’s all very well explained on the GitHub site.
Enjoy!
I’ve been holding back this release so I could get distributed routing into it, but it appears that there’s still a little more work that needs to be done before it’s ready to go. I’m hoping to get it out by the beginning of next week, but don’t quote me on that.
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.
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
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.
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:
Ok, as you remember a while back we created a simple blog using mack, http://www.mackframework.com/2008/03/04/the-obligatory-blog-demo/. Well now it’s time to add the all important RSS/xml feed to it.
Mack 0.3.0 introduces xml rendering support natively, so this shouldn’t be so hard. First things first, let’s fire up the app, shall we:
$ rake server
Now let’s head over to http://localhost:3000/posts. We should see our beautiful posts index page. Now let’s try to go to http://localhost:3000/posts.xml you should see something that looks like this:
Clearly, that’s not what we want, is it? I didn’t think so. The error is telling us that it’s looking for a file called index.xml.erb in the app/views/posts directory of our blog project. Obviously that file doesn’t exist.
Let’s take a second and talk about why Mack was looking for index.xml.erb. We haven’t changed anything in our controller. Our index method still looks something like this:
def index @posts = Post.find(:all) end
No where in there does it mention xml. The only place xml is mentioned is on the the url itself, remember? We looked for /posts.xml. By adding .xml you’re telling Mack that you want to render, well… xml. So it goes looking for that. That’s also new in 0.3.0. The default is html, but if you append a format (.js, .xml, etc…), it will go looking for app/views/<controller_name>/<action_name>.<format>.erb and render it.
Ok, now that we understand why we’re looking for an xml file, let’s fire up our trusty text editor and create a new file called: app/views/posts/index.xml.erb. Let’s edit the file to look like this:
xml.instruct!ml, :version=>"1.0" xml.rss(:version => "2.0") do xml.channel do xml.title("My Mack Blog") xml.link(posts_index_full_url) xml.description("Find out about all the cool stuff happening on my blog!") xml.language("en-us") xml.copyright("Copyright Me") xml.pubDate(CGI.rfc1123_date(Time.now)) xml.lastBuildDate(CGI.rfc1123_date(Time.now)) @posts.each do |post| xml.entry do xml.title(post.title) xml.link(posts_show_full_url(:id => post.id)) xml.description(post.body) xml.pubDate(post.created_at.strftime("%a, %d %b %Y %H:%M:%S")) end end end end
Mack uses the standard builder gem library. I’m not going to go into explaining how that works, there are plenty of other tutorials and documentation that will show you that. I’m also not going to explain all the necessary pieces of an RSS feed. Instead I’ll point out in that code you’ll see we’re using the @posts instance variable that we set in the index action of our PostsController. Just like regular *.html.erb files we have access to all the instance variables from the controller, as well, helpers, etc…
So now if we go to http://localhost:3000/posts.xml we should see our RSS feed. If we did a view source we should see something that looks like this:
<?xml version="1.0" encoding="UTF-8"?> <rss version="2.0"> <channel> <title>My Mack Blog</title> <link>http://localhost:3000/posts</link> <description>Find out about all the cool stuff happening on my blog!</description> <language>en-us</language> <copyright>Copyright Me</copyright>
<pubDate>Tue, 18 Mar 2008 17:18:05 GMT</pubDate> <lastBuildDate>Tue, 18 Mar 2008 17:18:05 GMT</lastBuildDate> <entry> <title>My New Post</title> <link>http://localhost:3000/posts/1</link> <description>This is my first post in my cool Mack blog!</description>
<pubDate>Tue, 18 Mar 2008 11:58:30</pubDate> </entry> </channel> </rss>
Awesome! All that’s really left is create one of those fancy RSS tags in the location field of our browsers that people can click and go straight to the RSS feed. Let’s do that now.
At the top of your app/views/posts/index.html.erb file add the following:
<%= rss_tag(posts_index_url(:format =>
Now, refresh the page in your browser, and there you go, you should now see the little RSS button in the location bar of your browser. If you click that you should be taken to your feed.
That’s all there is to adding not only xml, but an RSS feed to your new blog.
The code for this demo can be found here.
Let’s talk a bit about ‘helpers’ in Mack, shall we?
Those of you familiar with Rails are already familiar with this concepts. In Rails helpers are modules of code that get included into views for certain controllers, or all controllers in the case of ApplicationHelper. These helpers are meant to clean up the views and encapsulate commonly used Ruby code and keep it out of the views. In Rails 2.0 it’s easier now to include some of these helper methods into the controller, but by default, they’re not readily available.
Mack deals with helpers a little differently. Let’s start with ApplicationHelper. In Rails, ApplicationHelper gets included into all the views for every controller. This is extremely useful, and from my experience it’s the most used helper in Rails. The same is true of Mack. Regardless of which controller/view you’re in, ApplicationHelper is there to assist. This brings us to our first difference between Rails and Mack:
* ApplicationHelper is included into both the views AND the controllers.
That’s right, you no longer have to do special voodoo magic to get the contents of ApplicationHelper included into your controller, it’s right there by default, ready to go. Now, I know at this stage you’re saying, if ApplicationHelper is included into all controllers, as well as views, then aren’t the methods in there publicly accessible as actions? The answer is no. Which brings us to our next point on helpers:
* All helper public helper methods are converted to protected methods prior to be included into controllers/views.
By converting all public methods in helpers to protected methods we get around the security concerns regarding the methods becoming publicly available actions in the controllers.
Now, in Rails when you create a controller it creates a new helper module file for that controller. The idea being that you can put helpers into this module that are only available to that controller’s views.
* Mack helpers are NOT controller specific.
Mack, doesn’t do what Rails does in this respect. It’s been my personal experience that these files end up empty and just take up space on my disk. So screw em! We don’t need em.
Ok, so we’ve covered the basics of helpers, let’s talk about a couple of concepts that are available only in the Mack world.
What are controller helpers? In my experience working with Rails I found that I would have ‘helper’ methods, protected or private of course, in my controllers that were meant to assist the actual actions in that controller. Two things eventually dawned on me. The first was that I’m cluttering up my controllers with all these helper methods. The second was that there should be a way to share these amongst other controllers that could probably use them as well. (Example, methods dealing with authentication)
In the Rails world I wrote a gem, controller_helpers, that helps to facilitate this. Well, being as this is the Mack world, this facility is built right in.
If you go and create a module in the app/helpers folder that’s follows the naming convention <controller_name>Helper then it will automatically be included into the appropriate controller. Two things to note here, the security model is still applied, public methods become protected methods. The second is these methods are available in that controller ONLY. They are not available in other controllers or any views within that controller.
class BlogController < Mack::Controller::Base before_filter :authenticate end
module BlogControllerHelper
def authenticate
# do work to authenticate user here...
end
end
As we see the controller name in the previous example was BlogController and it’s helper name was BlogControllerHelper. Now in the example we had an authenticate method in BlogControllerHelper, we realize that we also want to use that in our CommentsController as well. So we can refactor that example to look like this:
class BlogController < Mack::Controller::Base before_filter :authenticate end class CommentsController < Mack::Controller::Base before_filter :authenticate end
module AuthenticationControllerHelper
def authenticate
# do work to authenticate user here...
end
include_safely_into(BlogController, CommentsController)
end
Here you can see in our new AuthenticationControllerHelper module we use the include_safely_into method. This method is documented in the RDoc for Mack, but basically what it does is includes that module into the list of Classes defined, and changes it’s public methods to protected.
Now we have included controller helpers into several different controllers. This helps to keep our controllers limited to just actions, and helps us to reuse code in other places. All very good things.
So, if you’re like me, your Rails ApplicationHelper module is absolutely overflowing with all sorts of bits of code. In one project I have it’s 682 lines of code! Some code does authentication like stuff, is_logged_in?, is_logged_out?, etc… some does formatting, some does other stuff. It’s a big steaming pile of unrelated code.
In Mack you can solve this problem by breaking your code out into Mack::ViewHelpers::<module_name> modules. If you do this then that module is automatically included into all views. Modules in the Mack::ViewHelpers namespace do NOT get included into the controllers. If you want to include them into controllers you can use the include_safely_into method to achieve that goal.
Well, I hope you enjoyed, and are still awake, this brief overview of the way helpers work in Mack. They are different from Rails. I feel these differences are what make Mack helpers really really useful. Mack helpers do more then Rails, and these features can be not only be really powerful, but can really help to keep your code nice and DRY.
Enjoy.
As previously mentioned there was an issue in a Mack dependency, cachetastic. Mack 0.2.0 used cachetastic-1.3.1 which had a require for the memcache-client gem.
If you didn’t have the gem installed you would get some not very nice messages. This require was fixed in cachetastic-1.4.1. Mack 0.2.0.1 uses the new version of cachetastic. There is no new functionality in 0.2.0.1, it’s simply the require fix.
Some really cool functionality is in the works for 0.3.0 of Mack, including everyone’s favorite, distributed routes. This, unfortunately, probably won’t be out till the end of next week.
$ sudo gem install mack
Like always, please allow time for the gem to propagate throughout the RubyForge mirrors.
