# Views¶ ↑

The view is the scene for our show. The user is sitting in his chair (the browser) and see on screen actors (the view). Enjoy the show without think that behind the scenes there is a whole team. The team behind the cameras is our controller but the user don’t care about that.

The user only see their browser and our application is just and HTML document.

## `Camping` Views¶ ↑

Inside the Nut::Views module, we will write methods. That method shall called with the render sentence. The views do not use class.

    module Nust::Views

       def post_number
          p "you asked the post number @post"
       end

    end

Well, well, that was a views, but now: How we show it to the user? We will call the view from the controller. And we pass to the view all the parameters that we want to show.

    module Nuts::Controller
       class PostN
           def get number
             @postn=number
             render :post_number
           end
        end
     end

We just declared a controller for the route /post/(number here). When the browser ask for the route /post/1 the controller will be trigged and the get method defined inside the class, will respond to the “get” request in the web server.

The first instruction in our controller, will by write the number in the @postn variable and then “render”

But what is `render`? This sentence is not from ruby, this is a camping’s sentence and mean: -show now the view named (:symbol). It take a symbol as parameter, and the symbol’s name, shall be one of these methods declared in the views. Now we have only a view named post_number.

You could “associate” it MENTALLY as a hash like this:

    def my_view => render :my_view

But that will happen in your mind. In camping these will be happening in the modules, not in a hash, therefore, their are very associated too.

Imagine your applications as a big building. The controller as the corridors and the views as the offices. Where are the offices and we do in each office?

## Views and Controllers¶ ↑

Model View and Controller, are joined but not scrambled. The views use R(ControllerName) for call the controllers and “move”. The controller will use “render” for call the view.

-And now… what do you think we have behind the curtains?

    module Why::Controllers
       class CircusCourtains
          def get
             require 'endertromb'
             @monkey=Endertromb::Animals::StartMonkey.new :frog=>true,:place=>:hand
             render :behind_curtain
          end
       end
    end

-OMG! It’s a monkey with a start in the hand!

-yes, ladies and gentleman, we have it just here for you

    module Views
       def behind_curtain
          p @monkey
       end
    end

No, we don’t have it behind the curtains, but the user believe it. There is the view, enjoy the show.

## Template engine¶ ↑

We spoke about the views, and HTML, but we are not using html’s tags for our view…

How happening this?

The rubyist have not necessary to write HTML code. Exists some options named template. That the “p” before the `@monkey` in the view. A template engine is a kind of “pseudo-language” for handle HTML code. In some template engines you will also write HTML in a more easy way. Their also handle ruby data inside HTML. Templates engine are the wheels of the views.

In camping, you will write views using a template engine named Markaby and you will write HTML pragmatically.