<div>Hello all,</div><div><br></div><div>Over the weekend, Paul Mucur (@mudge) and I knocked up a gem called Proffer:</div><div><a href="https://github.com/hudge/proffer" style="color:rgb(17,85,204)" target="_blank">https://github.com/hudge/proffer</a>.</div>


<div><br></div><div>There is more information on GitHub but the summary is that it stops Action</div><div>Controller from exposing all defined instance variables to your views by default</div><div>
and instead provides a way to explicitly declare your dependencies instead.</div><div><br></div><div>For example:</div><div><br></div><div>  class PostsController < ApplicationController</div><div>
    include Proffer</div><div><br></div><div>    def new</div><div>      proffer :post => Post.new</div><div>    end</div><div>  end</div><div><br></div><div>Our main rationale was to remove some of the global state that seems to pervade</div>


<div>Rails views. We want to see if forcing you to declare what information you pass</div><div>to a view would make you more mindful of the collaboration between your objects.</div><div>Would we end up with a better design if you couldn't just rely on some instance</div>


<div>variable being declared further up the chain? In particular, partials that</div><div>modify or make decisions based on data set in the controller can be especially</div><div>fiddly to maintain or reuse.</div>
<div><br></div><div><div>A lot of the talk at last month's TDD fishbowl [1] was about how to make testing</div><div>easier for beginners by improving conventions and we're using the same principle</div>
<div>here. We're attempting to guide people towards not using global state while</div><div>still not imposing a radical change in style. Avdi Grimm's recent "Objects on</div><div>Rails" takes a similar tack with his FigLeaf module [2] which makes it possible</div>


<div>to mark inherited methods as private as a way of forcing you to consider your</div><div>coupling to APIs that you may be trying to keep isolated.</div><div><br></div><div>While there are more drastic attempts at rethinking views such as Erector [3],</div>


<div>it seems like there might be opportunity for more incremental improvements to the</div><div>standard Rails approach to views.</div><div><br></div><div>As a question for the list (besides feedback on the gem which we would greatly</div>


<div>appreciate), are there any other conventions or constraints we could apply</div><div>through software to further explore Rails best practices?</div><div><br></div><div>  [1]: <a href="http://skillsmatter.com/podcast/agile-testing/lrug-tdd-fishbowl" style="color:rgb(17,85,204)" target="_blank">http://skillsmatter.com/podcast/agile-testing/lrug-tdd-fishbowl</a></div>


<div>  [2]: <a href="http://objectsonrails.com/#ID-5e701b05-6b1a-4cdf-9e4b-254b8f6c110d" style="color:rgb(17,85,204)" target="_blank">http://objectsonrails.com/#ID-5e701b05-6b1a-4cdf-9e4b-254b8f6c110d</a></div><div>  [3]: <a href="http://erector.rubyforge.org/" style="color:rgb(17,85,204)" target="_blank">http://erector.rubyforge.org/</a></div>


<div><br></div><div>PS: Remind us to write up how this simple gem led us to contribute to RubySpec</div><div>and stay up until 3 am chasing a bug in RSpec-Rails...</div></div>