Getting started with software design using MVC, OO, and Design patterns

I am just getting started on a new project and need to use MVC, OO and design patterns.

Here's the idea: Imagine a page that displays a set of widgets. These widgets are (usually) charts that are based off of data contained in several separate tables in the database. I use a running example of page that reports on a student's performance.

**High Level Requirements**

- a page that displays a set of (**HTML only**) widgets.
- widget's data will be based off a database query.
- the page can be used to view separate datasets containing similarly laid out data. For example, a single page will display widgets that report on various aspects of a single student's performance.
- want to see another student's performance, pull up another page. Displaying different widgets for different students is not needed (though it may be nice to have later).
- There may be many students, but data contained in the database is similarly laid out for all students.
- the way a widget is displayed may be changed easily (say changing a widget from displaying as a pie chart to display as a bar chart).
- widgets should be able to be created quickly.

**Low Level Requirements**

- Currently data does not change so widgets will not need to automatically update themselves.
- Widgets may represent a ratio of two things (eg. a ratio of failed tests to successful tests as a pie chart), a series of points, or sometimes a single numeric value.
- Development of new widgets should be a breeze, existing code need not be modified.
- Framework to be used: Zend Framework, based on MVC.

There are (minimally) three things to define a widget: the dataset to report on (in the example above, the student ID), the query that describes the metric being reported, and a render mode (barchart, timeseries etc).


Here is a pass at breaking down the responsibilities of each layer of the MVC:

*View:* Zend views are HTML templates with PHP injected. They will contain one of several types of widgets. Widgets are of various forms including: static JPEG images (loaded from a remote site ie: `<img src="http://widgetssite.com?x=2&y=3"/>`, JSON based javascript widgets, or charts of various kinds (piechart, bar chart etc.)

*Controller:* Creates the widgets, assigns them to the view afterwards. The set of widgets that is to be displayed on a page needs to be maintained somewhere. Since I can't think of a good way to do this in the view, I'll add this to the controllers responsibilities for now. If there's a better place for this please shout. The controller will also have to handle any other input parameters and passing them to the widget. For example, the data_set id which may be passed at the url line as `http:/.../report/?student_id=42`

*Model*: The model, in the Zend Framework, is responsible for pulling the data and as such will most likely contain a class for each widget for accessing the database.

Some points:

1. The model here, represents the data for a particular widget. So necessarily, it will need to know what the query is going to be, in order to pull together the tables necessary to fetch that data.

2. There's an additional processing step that will most likely be necessary before the widget can present the data. This is dependant upon which renderer will be used. Sometimes it may require forming a url out of the data returned. Other times, a JSON array. Other times perhaps creating some markup. This can go either in the model or the controller or the view. Unless anyone can think of a good reason to move it to the controller or view, it is probably best to let this live in the model and keep the view and controller thin.

3. Likewise, a widget will be made up of 3 things, its parameters, its data, and its renderer.

One big part of the question is: **What's a good way to represent the widget in an Object Oriented design?** I already asked this once, couldn't get an answer. **Is there a design pattern that can be applied to the Widgets that makes the most sense for this project?**

Here's a first pass at a rather simple class for the Widget:

Code:

---

        class Widget{
          //method called by the view
          render() {//output the markup based on the widget Type and interleaved the processed data}
   
          //methods called by the controller:
          public function __construct() {//recieve arguments for widget type (query and renderer), call create()} 
          public function create() {//tell the widget to build the query, execute it, and filter the data}
          public function process_data() {//transform into JSON, an html entity etc}
   
          //methods called by the model:
          public function build_query() {...};
          public function execute_query() {...};
          public function filter_data() {...};
        }

---

Looking at it, I can already see some problems.

4. For example, it is straightforward to pass the widget that was created in the controller to the View to render.

But when it comes to implementing the model it seems not so straight forward. Table Gateway Pattern is simpler to implement than ORM. But since table gateway pattern has one class for each model/table it doesn't seem to fit the bill. I could create a model for a particular table, and then within that, instantiate any other models needed. But that doesn't seem so to fit the Table Gateway Pattern, but rather ORM pattern. **Can Table Gateway Pattern be implemented with multiple tables? What alternatives are there? Does it make sense that the controller creates the widget and the widget creates the Model?**

5. Another issue that arises is that this design does not enable ease of widget creation. ie. Say I wanted to create a PiechartWidget, how much code can be reused? Would it not make more sense to use some OO ideas such as an interface or abstract classes/methods and inheritance?

Let's say I abstract the Widget class so only the shared methods are defined concretely, and the rest are declared as abstract methods. Revising the Widget class to make it abstract (second pass):

Code:

---

        abstract class Widget{
   
          private $_type;
          private $_renderer;
     
          //methods called by the controller:
          //receive arguments for widget type (query and renderer),
          protected function __construct($type, $renderer) {
            $this->_type = $type;
            $this->_render = $renderer;
            $this->create();
          }
     
          //tell the widget to build the query, execute it, and filter the data
          private function create() {
            $this->build_query();
            $this->execute_query();
            $this->filter_data();
          }
     
          //methods called by the model:
          abstract protected function build_query();
     
          protected function execute_query() {
            //common method
          }
     
          abstract protected function filter_data();
   
          //method called by controller to tranform data for view
          //transform into JSON, an html entity etc
          abstract protected function process_data();
   
          //method called by the view
          //output the markup based on the widget Type and interleave the processed data
          abstract protected function render();
        }

---

**Is this a good design? How could it be improved?**

6. I assume writing a new widget will require at least some new code to build the query, and maybe filter the data, but it should be able to use preexisting code for almost all of the rest of its functionality, including the renderers that already exist.

I am hoping anyone could provide at least some feedback on this design. Validate it?
Tear it apart. Call me an idiot. That's fine too. I could use any forward traction.

A few specific questions:

Q1. What's the best way to implement the renderers, as part of the Widget class or as a separate class? 1a. If separate, how would it interact with the widget class(es)?

Q2. How could I improve this design to simplify creation of new kinds of widgets?

Q3. And lastly, I feel like I am missing something here with regards to data encapsulation. How does data encapsulation relate to the requirements and play out in this scenario?

Q4. How best could it be harnessed this project?

Thanks in advance.