self.class in view rhtml

Hi all, very much new to Ruby and RoR - a very steep learning curve
but exciting stuff!

I'm just playing around with some things - I have a LoginController
which has an index.rhtml view file. If I insert <%= self.inspect %>
into this I get LOADS of not-very-readable stuff, so I tried <%=
self.class %> but this just gives me something like "#<Class:
0x4864ecc>" - why doesn't this class have a name?

Am I right in thinking that 'self' in a view is the calling

Thanks for any help!

<%= self.class.superclass %> gives ActionView::Base.

self in a view is not calling the controller.


Thanks Jatinder,

That makes more sense for it to be a view object.
Do you know why the actual class seems to have no name?


No clue about the thought behind the actual class having no name.

Following is a snippet from actionpack-1.13.3\lib\action_controller/base.rb

view_class(extending ActionView:Base) gets associated with a controller.


Great thanks for that; I wasn’t aware you could create anonymous classes in Ruby.

Try <%= controller.inspect %>

self.inspect is probably inspecting things like the request, response,
and controller objects. There may be some duplication, because
controller.inspect probably shows the request and response objects

The view classes are created dynamically with the necessary helpers mixed in.

Hi --

Thanks Jatinder,

That makes more sense for it to be a view object.

Of course, that raises the question: how can this view object share
instance variables with the controller object, since instance
variables by definition are always the property of self, and there are
two different selfs here?

I know you didn't ask, but the answer is kind of interesting :slight_smile:

The controller's instance variables have to be explicitly transferred
to the view:

   def assign_variables_from_controller
     @assigns.each { |key, value| instance_variable_set("@#{key}", value) }

where @assigns is the controller's instance variables.

So the whole thing where, say, @user is "shared" between the
controller and the view is based on this sleight of hand. It's almost
the opposite of what instance variables, as such, are actually for,
but it provides a very nice sense of continuity and connection between
the controller code and the view.