<br><br><div class="gmail_quote">On 4 April 2012 15:16, Simon Coffey <span dir="ltr"><<a href="mailto:simon@tribesports.com">simon@tribesports.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 2 April 2012 21:55, Andrew Premdas <<a href="mailto:apremdas@gmail.com">apremdas@gmail.com</a>> wrote:<br>
> The problem that proffer addresses isn't the important problem IMO.<br>
> The problem is that with Rails it is so easy to get powerful objects<br>
> without constraints into views where they can be abused.<br>
<br>
</div>While the problem you describe is certainly another thing that could<br>
use addressing, I'm not sure I agree that ubiquitous global view state<br>
is a minor problem. I'm just going to climb on this hobby horse for a<br>
second... :-)<br>
<br>
As a method of transferring data to the top-level template, instance<br>
variables are sort of tolerable-ish, but as soon as they start being<br>
accessed from within partials or helpers - anything that's not tied to<br>
the specific controller action in which they're set, really - you're<br>
creating a maintenance timebomb.<br></blockquote><div><br></div><div>Agreed, but does proffer stop this? If you can access the proffered variables in partials, then proffer is actually making things worse. However if proffered variables are hidden from partials then I can see it has value. Perhaps proffer could clarify this in its readme.</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
View code reuse becomes a drag, because to reuse something that<br>
accesses an ivar you've got to find its original use, and follow all<br>
the way back up to the controller action where it was set*, then<br>
replicate that ivar in the new context. Code starts getting<br>
cargo-culted between controller actions, because it's frequently<br>
easier to do that than precisely determine which set of ivars a<br>
particular render is going to need.</blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Changing things is even worse. You remove a partial or helper that<br>
depends on an ivar. Can you safely remove the ivar it depended on? It<br>
could be accessed by any number of other things in the render tree,<br>
and can't be sure without following every possible code path for a<br>
render of that action. So you delete it and hope your tests cover your<br>
shame, or you leave it there and take a performance hit fetching data<br>
that you're not even sure you need.<br>
<br>
We've been using a combination of Cells<br>
(<a href="http://github.com/apotonick/cells" target="_blank">http://github.com/apotonick/cells</a>) and decorators to clean this up,<br>
but having an explicit interface between controller and template is<br>
still a missing link, and it's nice to see this problem tackled.<br><br></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Cheers,<br>
Simon<br>
<br>
*or it might be set in a before_filter, or a before_filter higher in<br>
the controller's inheritance chain, or (heaven help you) in another<br>
helper called earlier in the render, or even (caution, rated R) in<br>
another template. Global state, eh? Fun.<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
Chat mailing list<br>
<a href="mailto:Chat@lists.lrug.org">Chat@lists.lrug.org</a><br>
<a href="http://lists.lrug.org/listinfo.cgi/chat-lrug.org" target="_blank">http://lists.lrug.org/listinfo.cgi/chat-lrug.org</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div>------------------------</div>Andrew Premdas<div><a href="http://blog.andrew.premdas.org" target="_blank">blog.andrew.premdas.org</a></div><br>