Tip:
Highlight text to annotate it
X
And we've done models, we've done controllers and now it is on to views.
Specifically template views and Hamel, which again if you've been reading the
book, you, you know what this is. If not read the book. Okay. So here we are. We're
down to the last component in the model-view-controller stack. Again, views
are primarily the province of the application server. Views generally don't
need to talk to the persistence database, because remember that models which are
stored there, their interaction with views is by passing information to the
controllers. So, what do we have to say about views? Not a whole lot, views are
pretty simple. You sort of already saw an example when we talked about HTML very
early on. The views that we're gonna use in the Rails version of
model-view-controller follows a pattern called template view. So again,
architecture is about alternatives. I'm gonna tell you the way that Rails does it,
and then we'll see, well, what other ways could you do it. So in a template view
pattern, it just means that the view is basically a bunch of markup like html. But
there's certain places in the markup where stuff can be inserted run time. Like the
value of some variables can be substituted into the html. Or maybe a little tiny bit
of code could run, and the result of running that tiny bit of code would be
substituted. Again, in the elder days. So you know [laugh]. Not that long ago, like
when I was a grad student or something. It used to be that this was the application,
right. Php largely evolved this way. You start by kinda writing of u. And there's
places where instead of just html. You put question mark php and then you put some
stuff. Maybe it's just the value of a variable. Maybe it's few lines of code
that goes through a loop and prints out a table of things. So what does this look
like in our, our simple diagrammatic notation? Here's this word, closure.
Everybody was awake last time when we were talking about blocks and closures, the
fact that blocks carry their environment around with them. So, how does the,
template view renderer work in rails? Well. You got a Hamel template which is
basically a, a concise version of how you specify html. And we're going to combine
that with a closure. Remember, what is a closure? It's the environment visible at
some point in the program. And in the case of rails, it's essentially the environment
visible at the moment your controller method finishes, right. So the user did
something, your controller method got called because the right route was found.
The controller method does a bunch of stuff. It sets up a bunch of variables.
That entire snapshot of state is a closure and that's what becomes made available to
the renderer. Which is really nice, by the way. What's not obvious about this picture
is that the closure doesn't have to come from the controller. It can come from
anywhere. And as we'll see this is actually a really elegant way to get reuse
because you can actually pull pieces of use in from other stuff. But what's the
output of this step? The Haml gets translated into HTML. The code and the
variables in the closure are evaluated and they're substituted into it, and what pops
out is an HTML page, ready to send back to the Happily patient user. By the way you
don't have to write it if using Hamel. One other choice, which will explore when we
do more advance topics is RJS. So you can actually have a template of stuff that
will expand into job ascript that will execute on the client once it arrives
there and the job ascript can interact with your app to do things like this cool
animation effects and new content appears and you know you hover over it and donuts
show up or. The system that actually comes with rails by default is called ERB for
embedded Ruby. Erb looks a lot more like the way PHP does things and honestly the
reason that we don't use it in this course, even though Hamel is not the
default way Ruby doesn't things, it is much more concise. And as a community,
Ruby community in particular, values conciseness because in most cases it leads
to greater clarity. So, since I always say once I show you how to do something you
should be thinking about well what else could you do if it wasn't this. Well,
another possibility is you could use what's called the Transform view, as
opposed to Template view. In the Transform view pattern, there's some kind of models
that have some data in them. There's a closure. And these go into a renderer that
outputs something else. So what's missing from the right hand side compared to the
left hand side? On the left hand side we had a hamel template with some mark up and
some things that get filled in, nothing like that over here, right? So this
basically says I'm gonna take some objects like movies, and I'm gonna generate of a
representation of them that isn't embedded in sort of an HTML template, it's just
some other representation of the object themselves. So one example might be an XML
representation of the objects, another example might be Jason which is a java
script notation that is sort of spiritually similar to XML and lets you
represent complex data structures. Why would you want to do the thing on the
right instead of the thing on the left. You know, when is template view appealing
versus when is something like, or sorry, when is the transform view more appealing
then using template view. Well obviously if you're doing a web app and human beings
are the consumers. They need to see something, right? So it makes sense to
say, okay, HTML is what browsers display. We're gonna put out some HTML with
application-specific data substituted into it. But. Suppose your exact same app is
being called as a service from somewhere else. So instead of a user clicking on
look up this movie, there's another service like the Movie Reviews or IMDB
service making a call to you and saying, look up this movie. That service probably
does not, want to receive an html page that it then has to dissect and scrape.
Like I showed in that really ugly example. That was non restful a few slides ago.
What it really wants is a nice structured representation of what they just have
asked for. Such as an html or [inaudible] format. In fact, the action view,
rendering system that comes with rails can do all of these things. And we'll see a
neat method for saying it without modifying anything else in the controller
method you could say either return an html template for human consumption or take the
exact same [inaudible] you would have given anyway and return xml or j sine for
machine consumption. So Hamill is described in the book, and in many, many
great websites. But, just to give you a very quick overview. It's, like, html on a
diet. So unlike html, instead of open and close tags, indentation is used to figure
out where tags get closed. You could have tags entirely on a single line, like this
H1. Or you could have a tag that's got stuff nested inside of it, like this table
tag. The para notation is used to specify html ids and the dot is used to specify
classes. In other words it's deliberately made to look like CSS, why because people
know CSS. You can have lines beginning with a dash, which is rubicode that get
executed, but the output is silently thrown away. Or you can have a line
beginning with equals which is rubicode that's executed and then output is
substituted into the template at this point. Right so, again if you done
something like PHP this very similar. And here is an example of rubicode that uses
those helpers that I talked about, when we did restful routes, to create a link
that's automatically gonna have the right URI for I request to create a new movie.
Can you have multiple lines of code? Like you know the line that goes you know,
beyond one's screen? Yes, that's what these red bars are for. If the red bar is
clumsy and ugly that's deliberate. Why because code shouldn't be in your views.
All the interesting stuffs should be in the model. May be some little stuff in the
controller to kind of set up some variable that are going to be substituted in the
view. But pretty much everything in the view should be straight HTML or really,
really, really simple substitutions of variables that were set up in the
controller. Hm, so. Don't put code in your views. Okay. Syntactically, nothing is
gonna stop you from doing it, but camel makes it awkward to do it because MVC
advocates having thin views in controllers. All the stuff that really
matters should be in the model. What about, you know, if you need to make an
object look nice? Instead of having the built-in format for a date, you want to
display it in some friendly format. Not a problem. Rails gives you a place to put
helper methods whose sole job is to prettify things so that they'll look nice
when the user sees them. But don't put code in your views. If you want to read
about ERB this is what comes with built-in, the built-in renderer that comes
with Rails. It actually looks a lot more like PHP, so it may seem like it's more
comfortable, but believe me, once you try Haml you won't go back. It's so much more
streamlined and once you get used to not having clutter, you come to really
appreciate it.