Model-View-Controller for the VM Module

Contents

Introduction

The Model-View-Controller method of organizing an application is very useful in facilitating updates to the three main parts of any application (model, view, and controller). These three main parts are described here.

Integration Into the Sahana VM Module

A prototype of the VM Module using the Model-View-Controller method is available here. To install this demo, do the following:

  • Download the new module: Media:new_vm_test.tar
  • Download the Smarty PHP template library and Smarty templates used: Media:new_smarty.tar
  • Unzip the vm_test.tar file and put it into the Sahana 'mod' directory
  • Unzip the smarty.tar file and put it into the Sahana 'www/tmp' directory
  • Change the file permissions for the 'www/tmp/smarty/docs/cache' and 'www/tmp/smarty/docs/templates_c' directories to be writable.

How it Works

The design for the volunteer handling of the new VM module can be represented by this UML diagram:

Image:vm_uml.png

Brief descriptions of each of the classes are as follows:

  • Smarty - the class that takes care of parsing the PHP Templates
  • DAO - an interface for accessing the database
  • Volunteer - a class to store volunteer information and handle setting and getting information about volunteers from the database
  • VolunteerView - a class to display the various pages
  • VolunteerController - a subclass of the VolunteerView, this class is what decides which pages to display and processes the forms

This Model-View-Controller system is put into Sahana using the Sahana module that was created. Sahana calls the shn_vm_test_default() function, and it is this function that decides which pages to display and what to do.

Quick Walkthrough

Once the shn_vm_test_default() function is called by Sahana, the new VM code creates a DAO object from the database object that Sahana creates and then creates a new VolunteerController object, passing it a reference to the DAO and the GET parameters.

From there, the VolunteerController decides what to do based on the GET parameters. If no additional GET parameters are specified, it simply displays a list of all volunteers. If the 'id' GET parameter is specified, it will display a single volunteer's information. If other specific VM actions are specified in the 'action' GET parameter, it acts based on those as well.

Since VolunteerController is a subclass of the VolunteerView class, it can simply display all of the view functions for each page, and based on what action needs to be taken, the VolunteerController may have to create a Volunteer object to handle database manipulation or display of a specific volunteer.