Meta Bates

I know that with every release I say something like, “This is a big release”, but the fact of the matter is this is a big release. Amongst the 49 tickets that make up release 0.7.0, there are two in particular that are at the core of Mack’s very existence, they are Distributed Objects and Distributed Views/Layouts.

Back on March 26th Mack 0.4.0 was released. This release brought the first of three large distributed features, Distributed Routes. With 0.7.0 Mack fully realizes it’s goal of making it easy to write fully distributed web applications. There is a very nice wiki page, on our new wiki, that shows in detail how to use the new distributed features. That page can found here. Also, don’t forget to watch the screencast of the new distributed features that can be found here.

Distributed Objects

Distributed objects allow you to easily distribute access to your library and model code amongst any of your other Mack applications. Allowing this access is as simple as requiring the mack-distributed gem, adding a few lines to your configuration, and starting the mack_ring_server binary. ‘Client’ applications just need to require the mack-distributed gem.

Distributed Views/Layouts

With distributed views and layouts you can now share the look and feel from one application with all of your applications. Configuration and use is just as easy using distributed objects.

Form and HTML Helpers

People have been requesting more HTML and form helper methods, and we’re more than happy to comply. There are whole bunch of these new methods now to help you more easily build your applications. The generators have been updated to use these new methods, to make your job even easier. There is also now support for doing Date/Time drop downs, similar to Rails and Merb.

‘Tell’ Messaging

Rails folks know ‘tell’ messaging as ‘flash’ messaging and Merb folks know it as ‘message’ messaging. We went with ‘tell’. Tell messages are cleared after any non-redirect request. They’re a great way to send a simple message down to the client.

New Wiki

With this release there is also a new wiki at, http://www.mackwiki.com. This new wiki, incidentally built using Mack 0.7.0, will house all the tutorials and how-to’s for Mack. There are a few entries from the old wiki that still need to brought over during the next day or two.

Changelog:

• [#114] Javascript link_helper
• [#112] Error generating mack application
• [#109] DataMapper 0.9.4
• [#103] Log colors for the console are now configurable per log level.
• [#102] New association method in data_factory
• [#101] Update to file upload testing (build_file -> file_for_upload, and multipart support in put)
• [#100] Inline routing parameters are being mutated
• [#99] Upgraded to facets 2.4.3
• [#98] Fixed mack-facets not being loaded before app_config files.
• [#97] Fixed sessions only working with ‘local_memory’ mode
• [#96] Distributed Views module now uses file cache
• [#92] Removed deprecated app_config.orm code.
• [#91] Fixed Mack blowing up if there is no config/initializers/gems.rb file.
• [#90] Added deprecation system.
• [#89] rake gems:* will now only display warning if any gem required is not installed (and not break)
• [#88] Implemented pending SQLite3 tests in mack-activerecord
• [#87] Refactored out common ORM code from mack-active_record and mack-data_mapper into mack-orm
• [#86] stylesheet link helper
• [#85] Refactored out Mack::ViewHelpers::HtmlHelpers into Mack::ViewHelpers::HtmlHelpers, Mack::ViewHelpers::FormHelpers and Mack::ViewHelpers::linkHelpers
• [#84] Added Mack::Distributed.lookup(url) to retrieve specific distributed services.
• [#83] Added mail_to HTML helper.
• [#82] Added ACL support to mack-distributed
• [#81] Fixed sessions working with redirects in testing
• [#80] Distributed objects present both the DRb::DRbObject inspect and the original object’s inspect when asked.
• [#79] Renamed app_config.mack.use_distributed_routes to app_config.mack.share_routes
• [#76] Move mack_ring_server to mack-distributed
• [#75] Left over mack-distributed rake tasks
• [#74] Added optional feature to disable initialization logging.
• [#73] Tests no longer use the functional/unit directories
• [#69] Added ViewHelperGenerator and ControllerHelperGenerator
• [#68] Transactional support in mack-AR
• [#67] Added test:setup tasks for active_record and data_mapper
• [#62] Removed const redefined warnings if mack-l10n is used along with mack-activerecord
• [#39] HAML 2.0.2 support
• [#28] Refactored out encryption into the mack-encryption gem.
• [#25] Added ControllerGenerator
• [#19] Added HTML form helpers
• [#15] File upload testing support (ability to do multipart form post in testing)
• [#11] Distributed Layout/Views
• [#10] Added distributed objects to mack-distributed.
• [#8] Move distributed code from mack-core to mack-more
• [#5] Added tell messaging
• gem: genosaurus 1.2.2
• gem: haml 2.0.2
• gem: addressable 1.0.4
• gem: facets 2.4.3
• gem: data_mapper 0.9.4

Let’s talk a bit about ‘helpers’ in Mack, shall we?

How does Rails handle helpers?

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.

How does Mack handle helpers?

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.

Mack only helper concepts

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.

Controller Helpers:

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.

Refactoring ApplicationHelper

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.

Conclusion

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.