Open Green

Fundementals of Ravana Usage

Back to the manual

Being based on Ruby On Rails, a similar MVC application framework written in Ruby, you could always get a "second-opinion" of how Ravana work by reading Ruby On Rails related documentation.

Model-View-Controller: The Famous Application Design Pattern

What is it?

Model-View-Controller was (and is) a application design pattern originally a framework developed by Trygve Reenskaug for the Smalltalk platform in the late 1970s. It has become the most intriguing and usefull UI design pattern.

So, what is an application design pattern, anyway? Well, it is the general way of building your website/web application. Not the coding, or where the files are put, but how the puzzle pieces (Database, template, code) will interlock. You can think of it like this, in terms of architecture: the application design pattern is the steel girders and walls, and your application fits in as the carpet, the paint, and how many panes the window is constructed of.

MVC is a "flexible" acronym. Since the actual order can be changed or interperated different ways, it also can be said as:

  • VMC
  • VCM
  • MCV
  • CVM
  • CMV

For some reason, though, MVC is the most commonly used acronym to describe this single idea.

The Three Components

The point of Model-View-Controller is to split the three predomanaint UI/IO components into three parts:

  • Model: your database tables; data presistance
  • View: your templates; the output
  • Controller: your code; the input

1. Models

"An object that wraps a row in a database table or view, encapsulates the database access, and adds domain logic on that data."
Written in Patterns of Enterprise Application Architecture, written by Martin Fowler

Models are objects encapsulating both behavior and data from the database. In other words, Models are your Read and Write access to the database. Model names are the singular form of the table they are affecting inside the database.

2. Views (and layouts)

Views are the presentational logic, or display logic of your application. They are basically templates, but are named and placed specifically so that each controller has a layout (Ravana's idea of a head/footer) and each action has a view.

3. Controllers

Controllers are classes which contain actions. Actions are the functions/methods of the controller class, and contain the bulk of your code, most importantly your aggressive database actions.

Aggressive database actions are the ones that change things in the database, and include Create Update and Delete. Passive database actions are the opposite, and include Retreive, Count, etc.

The previous description of Model-View-Controller was cut down from a long description. If you want more info on Model-View-Controller, see MVC: The Most Vexing Conundrum.

Routes: Dynamic Redirection in Ravana

Routes are "dynamic redirects" of a sort, but instead of redirecting to a file, they redirect to a controller/action pair. The default route is:

					/$controller/$action/*
				

An action is a function/method inside the controller (controllers are classes).

As an example, lets assume this controller:

					class blogController extends applicationController
					{
					function addEntry($title, $category) {echo "Title:'$title'
Category:'$category'"}
}

So, if we request:

					/blog/add_entry/AnotherSiteUpdate/WorldWideWeb
				

Since the request matches that default Route, it runs through that Route, going to the blog controller. It would call the equivalent of the following line of PHP:

					blogController::addEntry('AnotherSiteUpdate', 'WorldWideWeb');
				

The "*" in a route stands for a argument list seperated by foward slashes ("/").

We should get the output:

					Title:'AnotherSiteUpdate'
					Category:'WorldWideWeb'
				

The Dispatcher

The base .htaccess redirects everything (and I mean everything) to dispatcher.php, or the Dispatcher. The Dispatcher first checks to see if a real file in the public directory that matches the requested URI exists: if it does, then the dispatcher includes that files and ends parsing. Otherwise, it checks to see if a Route matching the requested URI

Back to the manual