[LRUG] Proffer and introducing constraints to Rails

[Andrew Premdas]

On 2 April 2012 19:55, Andrew Stewart <boss at airbladesoftware.com> wrote:

>
> On 2 Apr 2012, at 17:05, James Hunt wrote:
> > How much more convenient is it though? How much time do you really save
> by having instance variables by default?
>
> Compared to the Java way, which is where I came from when I switched to
> Rails, using `@post` in a view is far more convenient than `((Post)
> request.getParameter("post"))` (if I recall my Java from 7 years ago
> correctly).
>
> Compared to Proffer, I think this:
>
>    class PostsController < ApplicationController
>      def new
>        @post = Post.new
>      end
>    end
>
>    <%= form_for(@post) do |f| %>
>      ...
>    <% end %>
>
> -- is more convenient than this:
>
>    class PostsController < ApplicationController
>      include Proffer
>      def new
>        proffer :post => Post.new
>      end
>    end
>
>     <%= form_for(post) do |f| %>
>      ...
>    <% end %>
>
> The problem that proffer addresses isn't the important problem IMO. The
problem is that with Rails it is so easy to get powerful objects without
constraints into views where they can be abused. In the above code the
Post.new is (probably) such an object. First of all it will be an
ActiveRecord object, and more importantly it has no place in the object
hierarchy. Avdi Grimm identifies such objects as Lone Wolf's in his Object
With Rails book; and I think this lone wolf anti-pattern is quite a
profound insight. The thing to do is not get such objects into controllers
in the first place. If you are disciplined with your controllers then  the
standard mechanism used to get things views isn't really a problem. If you
write poor controller code, you can still expose with proffer objects that
really have no place in a view. The discipline that proffer adds doesn't
really address the discipline that controller code needs.

All best

Andrew



I think it consistently saves a little bit of time.
>
> > It's interesting to think about this the other way: if Rails had never
> exposed instance variables by default, would you even miss it? Would you
> have written a gem to add the functionality? How would you justify it?
>
> I didn't have it before so I wouldn't have been able to miss it.  However
> if it vanished now I would write a gem to replace it...unless it seemed I
> was in a tiny minority; with Rails it's usually better to go with the flow
> unless there's a good reason otherwise.
>
> > In the scheme of all the things you have to do to get a Rails app
> working, not having instance variables in views seems like a really small
> thing.
>
> True, but a lot of Rails' productivity boost comes from the aggregation of
> many little time-savers.
>
> > And if you were reaaaaallly desperate, you could do:
> >
> > <% @post = post %>
> >
> > at the top of your view and you're back in business! The only difference
> here is that before you do something like the above, you have to actually
> think about what you're doing and why before you do it. It's a convention:
> break it if you want, but know why you're doing it and what it may cost you
> later on.
>
> For me, using an instance variable instead of a plain local variable is a
> fine convention.  If I want to share state with a view, I use an instance
> variable; if I don't want to share state, I use a local variable.
>
> Cheers,
> Andy
>
> _______________________________________________
> Chat mailing list
> Chat at lists.lrug.org
> http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>



-- 
------------------------
Andrew Premdas
blog.andrew.premdas.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20120402/6fc7ee33/attachment-0003.html>