Forum: Ruby on Rails instance variable (conroller>view) and RESTful

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
zambezi (Guest)
on 2009-05-31 03:14
(Received via mailing list)
I'm a bit flummoxed by something and hoping someone can offer an
explanation.

If I create a controller (test) with a RESTfully named method and a
view (.../test/index), the value of the instance variable passes to
the view.

class TestController < ApplicationController
    def index
        @variable = 'Pass to a view'
    end
end
-------------

If I rename the view to (.../test/foo) or some other non-RESTful name
and appropriately alter the controller method, the value of the
instance variable does not pass.

class TestController < ApplicationController
    def foo
        @variable = 'Pass to a view'
    end
end
---------------

A half dozen inprint and online books seem to dispute my personla
experience and suggest that the name of the method and view should be
irrelevant.  So does anybody have a suggestion as to what is going
on?  Is my routes.rb file where I need to be looking?

Thanks much, Bill
Colin L. (Guest)
on 2009-05-31 11:38
(Received via mailing list)
As long as the name of the view and the method match it should work.
There is nothing special about the default methods in this respect.
Post a bit more code that exhibits the problem.  Presumably the view
is called views/test/foo.html.erb.  Unless there is something special
about a controller called 'test' that is.

Colin

2009/5/31 zambezi <removed_email_address@domain.invalid>:
nodoubtarockstar (Guest)
on 2009-06-01 11:15
(Received via mailing list)
Well, as Colin says, there is nothing about the name of a method or
view that would muck with an instance variable working, but there
could also be something weird about TestController (that it *may* be
reserved, but i doubt it)...

Are you getting an error/stack trace?

Your routes could be an issue but you'd be getting an obvious error
(assuming you're in dev mode) saying something to the effect of "No
route matches "/test/foo" with {:method=>:get}"

Try posting some of your code and seeing if you get some clearer
answers. :)

Cheers!
zambezi (Guest)
on 2009-06-02 01:58
(Received via mailing list)
Hi to Colin, Jennifer and anyone else,

If nothing else, this forum serves as a sanity check.

My difficulty arose when I created an application wide template as a
container for various views and attempted to pass a title variable to
the template.  None of my fiddling raised any errors.  After reading
your replies I went back to my application and sacrificed another hour
to Ruby idiosyncracies.  Here is what I've done and the results.

#-------- within layout/application
class LinkController < ApplicationController
    def display
        @title = "title (display)"
    end
    def index
      @title = "title (index)"
    end
    def foo
      @title = "title (foo)"
    end
end
----
    <title><%= @title %></title>
---
I created a view named 'display'  with the above embedded Ruby and
opened it in the browser.  The title was BLANK.
Next I renamed the view 'index' and opened it in the browser. The
title appropriately showed "title (index)"
Then I renamed the view 'foo' and again a BLANK title.
I renamed the view back to 'index' and the title reappeared.

The above was with a template, so I decided to try the same fun
experiment with a standalone view.  And things got murkier.  Views
named 'index' and 'foo' display their titles.  Views named 'display'
are BLANK.

Just on the off chance that Ruby is weirder than I think, I checked
the list of reserved words.  No conflicts there.  I also considered
there might be something bizarre about the title tags, so just stuck a
variable in the middle of the view <body> <@= @title %></body>.  This
just reproduced the earlier results.

So there is the sad story.  Help!  I suppose I can just test all of my
view names to see if they pass muster, but I am really hoping to
eventually get to where Ruby is a time saver.

Any suggestions and/or comments on the instance variable behavior will
be welcomed.

Bill
Colin L. (Guest)
on 2009-06-02 13:25
(Received via mailing list)
2009/6/1 zambezi <removed_email_address@domain.invalid>:
> to Ruby idiosyncracies.  Here is what I've done and the results.
>      @title = "title (foo)"
> I renamed the view back to 'index' and the title reappeared.
> just reproduced the earlier results.
I presume you meant <%= rather than <@=
Did you include some fixed identifiable text in each view to check
that the correct view is being shown?
The possible name conflicts are not so much with Ruby (which would
generally give an error of some sort) but with Rails.  Have you tried
other variable names?  This is certainly not a general problem or we
would all be falling over it all the time.
Have you checked in the log file (/log/development.log) for any errors?
zambezi (Guest)
on 2009-06-02 19:29
(Received via mailing list)
Hello Colin,

I did mean <% instead of <@ and I did have some identifiable text with
each view name version.  Just cut out what I thought was extraneous to
the post.   I looked at the development.log and it is clean.  The only
differences between the view name versions were the expected time/
session/performance/etc.

The thought occurred to me that perhaps the use of duplicate view
names was the unlikely problem.  I've used 'display' as a view name
several times across different folders.  But I renamed everything and
eliminated this as an issue.

So for now I am left with a Ruby on Rails app that just has a quirky
bias against 'display' as a view name.  There are plenty of
alternative naming options and alternatives seem to work. So
ultimately not a big deal, though I'll be carrying a niggling
suspicion that something will pop up and bite me one day.

Thank you much for the replies and support.  As I indicated earlier,
this forum serves as a sanity safety net that keeps me from doing
regrettable things to my computer.  If I ever turn up an explanation
for the problem I will pass it on.

Cheers, Bill
Frederick C. (Guest)
on 2009-06-02 21:33
(Received via mailing list)
On Jun 2, 4:28 pm, zambezi <removed_email_address@domain.invalid> wrote:
> several times across different folders.  But I renamed everything and
> eliminated this as an issue.
>
> So for now I am left with a Ruby on Rails app that just has a quirky
> bias against 'display' as a view name.  There are plenty of
> alternative naming options and alternatives seem to work. So
> ultimately not a big deal, though I'll be carrying a niggling
> suspicion that something will pop up and bite me one day.
>
Have you checked whether your action ever gets called (stick a
breakpoint in there). ?

Fred
zambezi (Guest)
on 2009-06-03 07:34
(Received via mailing list)
Hi Frederick,

I can't give you a direct answer since the breakpoints in my IDE don't
work.  Actually I can set them in .rb files, but no response under any
conditions.  So at the moment I can only verify that the method is
being called.   I'm not sure if I can set a command line breakpoint.


Cheers,
Bill
Frederick C. (Guest)
on 2009-06-03 11:09
(Received via mailing list)
On Jun 3, 4:33 am, zambezi <removed_email_address@domain.invalid> wrote:
> Hi Frederick,
>
> I can't give you a direct answer since the breakpoints in my IDE don't
> work.  Actually I can set them in .rb files, but no response under any
> conditions.  So at the moment I can only verify that the method is
> being called.   I'm not sure if I can set a command line breakpoint.
>
you can always resort to slightly more primitive methods, eg stick

raise "I've been run"

in the action method.

Fred
zambezi (Guest)
on 2009-06-03 22:46
(Received via mailing list)
Hello again Frederick,

I took up your suggestion and it was revelatory, though I'm not sure
what it reveals.

With a view and action named 'display', an exception was NOT raised
from the action.  With alternative names, the exception was raised as
expected.

I created another application and got the same results.  I'm curious
as to whether this behavior is repeatable on someone else's setup.

Cheers, Bill
This topic is locked and can not be replied to.