Beans, Pages, Page Frames in PHP
by Robert Szlizs, FixPoint

Web Page Anatomy

All over the web we see so many differently looking pages. We always try to find something new that distincts one from the other. And yes, visually they look so different: one is a static and simple HTML, the other contains JavaScript-generated effects, another is a partial or full Flash page, another is something server extension generated dynamically... But since we are programmers we may have some ability to take some abstract view to them and if we can do so everything looks like in the good old times: so similar.

Many clever articles teach us to use the Model-View-Controller design pattern that means to write our programs a way the model representing some data functionality will be separated from the view how data appears in the browser. And the controller is something that controls (decides) what part of the system is just on order, what part of the program has to run when some process-sequence is initiated. Let us forget about the controller for a moment. Then it is natural to interpret that model is something that organizes the data into a group, manipulates them defined by the business logics, then moves it to that part of the program that will create the view. And here on the border between the model and the view the situation is often foggy.

Many times we see, the programmer solves the problem and only after that they really "defines" what is the model what is the view. Another programmer solves it another way, defines the border between the model and the view another way and he is right too. When there are attempts to "remove the fog" programmers design and build an independent presentation layer (see Struts, Spring, JSF in Java, Smarty or other template-like solutions in PHP). From the work managers point of view the problems seems to be gone. The problem is the system is not simpler, just contrary, it is more complex. Really, the task is to separate programmers' work the way that for everything we need specialists? Maybe not. Maybe some other kind of object creation, some other look at the objects will give us still powerful, usable tools that are simply enough to understand them and complex enough to make the job. In this article we will present just such a framework. This is really not a framework, it is only some collection of objects that allows us to build the complex page from simple blocks. (From my topology studies I remember the concept of simplicial complexes, so just like that.)

Nothing new under the Sun. Java Enterprise is doing that for long time. It creates a level that is full of entity beans (or already simpler data objects in the newest frameworks) that model data coming from the database. Then it creates other objects that manipulates the beans and creates other data groups from them... then finally some view takes the final data group and displays it.

Why not to do this in PHP? OK, OK, you say, but JEE runs from inside the application server with more complicated serving containers then a simple webserver. OK, OK, I say, but even if our PHP can not do this all so optimally, still why not to try it. Let us begin to build our framework: a set of some conveniently usable objects that will allow us to build our serverside in PHP in a manner similar like JEE does it.

Let us repeat the question: How to see a web page?

The page layout: Everything that is in white will be implemented by the PageFrame object. The Page object will contain the real one-theme-oriented content.

Yes, every site has some nice opening page with full of differently composed data blocks. But, when we are paging we see some frames always coming back, and really we are always interested in some central part of the page, where some main, one-theme-oriented content is presented. Everything else is some eycatching only and - what is important - a set of links that open the doors out to move away. If we take a look at the code of the generated formally it is nothing else then a linear sequence of code lines where the "main content" is well placed inside. "Well placed" means the main content separates the code to three parts: lets name the top part header, the bottom part footer. So we may see the page as combination of some frame object (we will call it PageFrame) that consists of that mentioned header and footer, and the main content part (we will call it Page) laying between the header and footer. The only question remains in the simplest case: What will the Page consists of? Let the answer be: It consists of views that some data modelling and handling objects (we will call them Beans) produce.

To achieve the goal, to create a page that's main content is in the Page aea created by a set of Bean objects' views framed by PageFrame, we have to do the following steps:

Create the PageFrame object that will make the page framing abstract and easy to use.

Create a sample database table that will produce some data.

Create a general Bean object and then it's descendant that models the data from the database table.

Create the general Page object and then it's descendant that builds the page embeddindg the Bean object in different views. In the simplest case this Page area is a simple empty string or an empty <p></p> paragraph.

Extend the PageFrame object to be more flexible.

Where to locate the files?

Before we begin with coding let's agree where we will locate our source files. Under your web root directory create your project directory (we name it myweb) and create your directory structure something similar as it is on the next graphics.

myweb
     chapter_1
          doc
          inc
          pic
     chapter_2
          doc
          inc
          pic
     ...
     common
          css
          doc
          inc
          pic
          scripts
               js
               ajax
               classes
               db_classes

Directory structure

Don't worry, we don't need it all now, but it may help later if we discuss it now. Let your chapters represent some main horizontal menu structure of your web project. So any of them will contain some index.php (or index.html) page at least. There can be placed also other php files that will control the process flow (controller) and realise the final page rendering (view). The underlying doc, inc, pic directories may contain corresponding documentation, include and flat data files, and pictures.

The common directory is special and keep it's structure fixed as it is on the drawing above. Everything that is related to the whole web project is placed here. The directory names are self-describing but we mention that classes and db_classes will contain all the PHP classes that implement the presentation layer (view) and the database representation layer (model) respectively.

In that section we will start coding the PageFrame object. We will create a PHP object that can set his characteristic member variables, create and display the page's header and footer, that allows us to compose our pages comfortably.

Read the next section: The Page Frame