[LRUG] Proffer and introducing constraints to Rails

[mudge]

I think you've both hit on something here more accurately than I could
previously express.

My issue with rendering views is that their mechanism is obscured (are
they a method call? an instantiated object?) and, through that
obscurity, it's easy to make mistakes of the sort Simon mentioned.

To make this clearer, consider this somewhat fatuous code:

  def view(*)
    "Hello, #{@name}, good to see you again!"
  end

  @name = "Bob"
  view

It's unlikely you'd ever consider writing code in this way and yet I
feel like this is what we are currently doing. It's not clear from the
method's signature that a specific variable must be passed in and if
you fail to set @name before it is called then there is no error: only
an incorrect result.

Proffer effectively changes it to be more like this:

  def view(variables={})
    "Hello, #{variables.fetch(:name)}, good to see you again!"
  end

  view(:name => "Bob")

Which is marginally better but pushes the error into the template
itself if name is undefined. In reality, the code you'd want to write
is this:

  def view(name)
    "Hello, #{name}, good to see you again!"
  end

If we could somehow express views as just methods with all the
standard functionality available to us by doing that then maybe
unpicking some of these issues would be easier. Of course, this means
that it would have to apply everywhere a template is employed
including partials, etc.

Perhaps all this really comes down to is the fact that Rails' "render"
is insanely powerful and rather opaque for it. Perhaps if we could
simplify the view part to simply be:

1. Take some state;
2. Return a string.

Then views and helpers would be practically the same thing and we
could tackle some of these problems more easily.

On Wed, Apr 4, 2012 at 7:59 PM, Viktor Tron <viktor.tron at gmail.com> wrote:
> On Wed, 04 Apr 2012 19:47:02 +0100, Daniel Barlow <dan at telent.net> wrote:
>
>   On Mon, Apr 2, 2012 at 4:17 PM, Tom Stuart <tom at therye.org> wrote:
>>
>> Also, I can't think of many situations in which one sets an instance
>> variable in a Rails controller (with the exception of setting up an object
>> in a before_filter for use in an action - see conversations passim) for any
>> reason other than exposing it to the view. I'm not convinced that changing
>> "@post = foo" to some explicit means of passing the data to the view is a
>> huge inconvenience.
>
>
> I agree that from the controller's point of view it's just syntax and
> "@foo=1" is just as good syntax as "proffer :foo".    But now pretend you're
> the *view*: there's no way on that side of the interface to for it to
> specify the data it needs. I think it'd catch a non-zero quantity of bugs[*]
> if  views could explicitly declare the parameters they depend on and bail
> out (instead of assuming nil) unless all are supplied.  I've used Erector a
> fair bit and it does have the right idea here, imo
>
>
> I elaborated on this idea in my earlier response. Would love to hear more
> reactions to it.
>
>
> And though I agree that the complexity of this interface rarely reaches
> levels where it actually *matters* that much, perhaps that in itself is an
> artefact of the less-than-optimal convention we have here: the subconscious
> cognitive burden of having to remember which variable names are important is
> preventing us from designing cleaner, more expressive, more general
> programs.  (Or on the other hand, perhaps the same cognitive burden is
> preventing up from ballsing it up completely - who knows?).  There's an
> analogy to be made here with lexical vs dynamic scope, and history came down
> squarely on the lexical side of that debate the first time around.
>
> Except for emacs lisp programmers, obviously.  But they're a special case
>
>
> -dan
>
> [*] my bugs, at least.  Your buggage may vary.
>
> --
> dan at telent.net
> http://ww.telent.net
>
>
>
>
>
> _______________________________________________
> Chat mailing list
> Chat at lists.lrug.org
> http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>