Yehuda Katz is a member of the Ruby on Rails core team, and lead developer of the Merb project. He is a member of the jQuery Core Team, and a core contributor to DataMapper. He contributes to many open source projects, like Rubinius and Johnson, and works on some he created himself, like Thor.
@kmilden it actually wasn't all that expensive. I already had 4GB and the additional 8GB was just $200
Rails Refactor Update (and Merb 1.0.7.1)
December 31st, 2008
Over the past few days, I’ve been working on refactoring ActionController and ActionView to clean up the interactions between them. You can follow along on my github fork. Some principles I’m following:
- ActionController and ActionView should work well standalone
- All request-related information should be calculated in ActionController and passed through into ActionView
- ActionView should be responsible for figuring out what path to render; ActionController should pass enough information for ActionView to figure it out.
- Based on the previous, the information passed from ActionController to ActionView will likely be: template_name, list of acceptable extensions (i.e. [:html,
ml]), prefix (usually the controller name), and partial (a boolean indicating whether the template is a partial). This is not nailed down yet, but it has so far served well. - So far, I have unified render(:template), render(:file), and render(:action) to use this new conduit, and will be working on partials tomorrow. Partials are quite complicated so my current plan may have to change slightly when I tackle them.
- Interesting info: ActionPack has a lot of methods that call each other (somewhat circularly), so it wasn’t really possible to just replace the existing conduit in a straight-forward manner. Instead, I created the new method (currently called find_by_parts, which finds a template based on the components I discussed above) and slowly (very slowly) moved existing callers of find_by_path over to use find_by_parts. Thankfully, the Rails test suite caught the initial errors I made, a huge saving grace of the entire effort.
- A nice side-effect of moving to a single, clean API between AC and AV is that the final code should be easier to understand. Once I’m further along, I’ll post some details of how exactly the interaction works.
We also released Merb 1.0.7.1 today to fix a few issues that were outstanding as well as a 1.0.7 development mode regression. (In general, we will be using the x.x.x.x moniker for midweek releases and x.x.x for weekly releases). The issues that were fixed:
- Templates should reload again in development mode
- An issue in the bundler where gems in your local repository were getting greedily installed is fixed
- An issue that was preventing bin/thor merb:gem:install use is fixed
- The error message when gems could not be found was slightly improved
To upgrade:
- gem install merb (make sure merb-gen 1.0.7.1 is installed)
- in your app, rm -rf tasks/merb.thor
- in your app, run merb-gen thor
- you should receive a prompt asking you to override bin/common.rb. Accept the prompt.
- you’re done
Happy holidays folks!
Tags: AcG
solnic, Posted December 31, 2008, 9:01 am
Thanks for the update and BTW – are you going to go with Merb naming convention for controllers or leave Rails-style (with “Controller” suffix)?
teamon, Posted December 31, 2008, 9:52 am
I think it will be xxController cause of compatibility
(and yes, I dont like it)
rick, Posted December 31, 2008, 12:14 pm
We just discussed this, and will likely support the merb style convention, but go with the rails convention by default. The rails convention is to separate the domain from the infrastructure. Models = domain, Controllers/Helpers = the infrastructure. This shouldn’t affect your existing apps, and should be easy to change in new Rails 3 apps if you desire.
Dado, Posted December 31, 2008, 1:55 pm
I too prefer the Merb convention. Both the “old-Rails” convention (for backward compatibility) as well as the new “Merb” convention should be supported. I don’t know how controllers are looked up in Rails 1 and 2, but if instead of naming conventions one looks for classes that inherits from ActionController::Base that should be enough to support whatever naming conventions one might like.