After the design goals for the PHOOP framework, now its time to come face-to-face with the framework itself (you will find the framework files attached with this blog post).
Following are the details about the framework, you need to know for developing on it. All features discussed below would be demonstrated in a simple application built on the framework in the next blog post.
- Each page is supposed to be composed of 2 files with the naming convention being Page.php, and Page.inc.
Page.php should contain the mark-up for the page together with any javascript and styles you want for the page. Any data/information required for the page should be made available in Page.inc through a public function. You can think of Page.php file as a template file, and Page.inc file that does the processing and provides data to be used in the template.e.g. the following code shows specifying the items for a Html <select> fetched from the database by Page.inc and formatted and displayed by Page.php:
{syntaxhighlighter brush: as3;fontsize: 100; first-line: 1; }<?php
$provinces = echo PageBase::$pageObject->getProvinces();
foreach ($provinces as $province) {
echo sprintf(‘<option value=”%s”>%s</option>’, $province[‘id’], $province[‘name’]);
}
?>{/syntaxhighlighter}This code is placed in Page.php whereas the getProvinces() is a public method in Page.inc. - There’s a PageBase class available which acts as a sort of master file for all pages. Each Page.inc file is expected to define a class named “Page” (i.e. the class should be named after the file itself), which inherits from PageBase directly or indirectly.
PageBase class provides abstraction from common page related operations (which can be overridden in derived classes). Further it establishes the different elements of a page with header, footer and main content files. header and footer are template files (that can be replaced by any page), and the Page.php is the main content file.
The concept gains power with the fact that you can create sub-classes of PageBase, e.g. ForumPageBase, ProductPageBase and provide appropriate UI elements for different types of pages for your application, and then inherit different types of pages from the appropriate PageBase class.
- The main entry point to the application is index.php in the root of the application. This file performs the normal bootstrap and loads the appropriate Page.php and Page.inc files based on the urls.
The urls for the application are of the form:http://localhost:8080/phoop/
http://localhost:8080/phoop/?path=Report
http://localhost:8080/phoop/?path=Admin/UploadDataThat is navigation between pages is achieved by specifying the path in the query string. You can specify the default Page file in case the path parameter is absent.
There are utility classes with static methods available in the framework, that would generate the application url by passing in your relative class path to the methods.
- The namespaces are based on folders. So, a page with the file name Report (the second example url above) residing in the root of the application needs to provide a class named “Report” in Report.inc and Report.php that contains the page’s html.
However, if the file is placed in a folder let’s say called Admin (the third example url above), then there should be 2 files Admin\UploadData.php and Admin\UploadData.inc, and the class name in UploadData.inc needs to be Admin_UploadData (i.e. folder_filename).
- The framework provides out-of-the-box support for handling Ajax calls to Pages. For Ajax calls, the normal Page bootstrap is by-passed and pages supporting Ajax calls are supposed to provide a public handleAjaxRequest method, and return any desired data to client.
Further, if the data being returned is JSON, you can instead handle getAjaxJsonResponse method and return the desired data. The framework would automatically encode the data as JSON and send it to the client.
- The framework itself uses Camel casing as the naming convention.
- A static global public variable PageBase::$pageObject provides the reference to the current page object that is handling and processing the request. This object is available in all template files, whether it be your header, footer or page template file.
You can access public methods for the current page through this object. - There are default header and footer template files available. You can easily override them on a per-page basis, or better still based on the type of the page by creating a derived class of PageBase and overriding the template to be used by specifying renderHeader and renderFooter methods.
- There’s an important file called Config.inc inside the Includes folder. You should open that file and specify the database information, along-with the application path in that file. The comments in that file would enable you to understand easily what each option is meant for.
- There are some utility classes available in the Includes folder for common Html and Http tasks. Further, there’s a Database.inc file available that provides ADO.NET style data access through its 3 public methods executeReader, executeScalar and executeNonQuery. You can easily add more methods as desired to these classes, or add more utility classes you need.
I think that is sufficient information one needs to know to start developing with PHOOP. All of the above functionality is contained in a handful of files (just 4-5) hardly some kilobytes in size (I mentioned Simple as the first design goal).
All the above points would make much more sense if you have a look at a sample application developed in the PHOOP framework. The same is available in the next blog post here.
The core PHOOP files are attached below. However, you might find it easy starting your development off the sample application, by modifying it.
Recent Comments