decent_exposure helps you program to an interface, rather than an implementation in your Rails controllers.
Sharing state via instance variables in controllers promotes close coupling with views. decent_exposure gives you a declarative manner of exposing an interface to the state that controllers contain, thereby decreasing coupling and improving your testability and overall design.
via voxdolo/decent_exposure – GitHub.
It’s almost as if the program were composed out of some kind of discrete “objects”, which only communicated with each other via well-defined “interfaces”, and “encapsulated” their implementation details. It’s like a whole new paradigm of programming!
(Just in case anyone misses the joke, this is not an indictment of decent_exposure. It’s a commentary on just how broken the Rails Controller/View interface is and has always been. I find it ironic that one of the most OO languages in modern use, the notion of a public method interface has to be hacked into Rails controllers with a special syntax.)
Thanks for the mention 🙂 I've always been irked by Rails Controller/View interaction as well… thus the creation of decent_exposure. I'm hopeful that after it gets a bit more adoption (and I finish the forthcoming rewrite) that it might get absorbed into Rails proper.
Cheers!
My pleasure!
My only concern about decent_exposure's approach is that, as a friend of mine put it, if you use it now you have two problems. I.e. you're avoiding Rails' exposure problems by layering yet another piece on top. My hope would be that eventually Rails evolves to a point where it is using Ruby's built in objects, methods, and visibility to mediate the relationship between views and controllers.
But until then decent_exposure is an interesting approach to the problem and I'm looking forward to trying it out on a project in the future.
Kind of a late response to this, but Im curious on your views of decent exposure vs say a Presenter pattern.
From what I understand the decent_exposure gem is hiding the implementation details via an interface on the controller itself and using a Presenter we are adding another layer between the view and the controller there by decoupling the view from the controller.
I’m also curious on what you mean by ‘using Ruby’s built in objects, methods, and visibility to mediate the relationship between views and controllers.’ in the above statement.
Also good work on exceptional ruby!
Rails Controllers+Views = global variables.
Pretty silly.
Indeed.