Developing web applications presents a variety of challenges. Listed below are a number of classic web development architectural problems, and how PHOCOA provides solutions.
Separation of Data, Presentation, and Glue layers of the code.
Presentation templates should be clearly separated from other code, allowing designers to easily edit the look and feel without breaking the appilcation or dealing with business logic.
Data model code should represent only the pure data model of your system, and have no code related to UI.
Glue code links the model layer to the view layer. Glue code is typically the code for each "web page". It loads up the right data and view pieces for that page, and links the two together.
This problem is typically solved with a MVC design.
PHOCOA uses a MVC architecture as part of its framework.
PHOCOA has some flexibility in the model layer, but we recommend Propel for model objects that are stored in an RDBMS. Of course, not all of your model objects will be persisted, and you can write your own classes as well. You can use other persistence solutions as well, but this may break some of the functionality of the framework.
For the presentation layer, PHOCOA uses a template system to separate the presentation layer from the Model and Controller layers. PHOCOA uses the Smarty template engine, but it is possible that the system could be extended to use other template engines.
PHOCOA's controller layer is one of the most powerful parts of the framework. The PHOCOA controller layer provides automatic state-maintenance of form data, a formalized data validation mechanism, and a bindings layer. All of these items will be discussed in more detail below, but have the net effect of drastically reducing the amount of code you have to write.
Persistence / Retrieval of Model objects to a database.
Model objects should be accessible through a single interface and easily retrieved and persisted. Typically this means saving complex relational model data in a RDBMS, as well as querying the DB and restoring model state.
This problem is typically solved by Object-Relational mapping tools.
PHOCOA currently uses a modified version of Propel to provide object persistence. The modification that is made is simply to make the Propel BaseObject subclass the PHOCOA framework's base object, WFObject. This allows Propel objects to provide the requisite interfaces for integrating with PHOCOA.
"Skinning" - having an overall look and feel for a site that is easily switched out. Also, having different look & feel for different parts of a site. Also, getting data into the HEAD section of the page.
All web sites have graphics that are used for every page. We call this a "skin". Some sites allow different themes of a single skin, and others use different skins for different parts of the site.
This problem is typically solved with include files and logic to switch between files.
PHOCOA has a complete infrastructure for skinning built into the framework. A web application can have an unlimited number of skin setups for different parts of the site. Additionally, each of these skin setups can have an unlimited number of skins with an unlimited number of sub-themes. Skins in PHOCOA are completely arbitrary and impose absolutely no design restrictions.
The undlerlying skin mechanism also allows you to easily customize HEAD information such as title and meta tags.
PHOCOA also includes a menu system infrastructure for managing hierachical menu systems.
Maintaining State of a Form Between Requests.
A nice web application will keep track of all of the data the user has entered into the form. In the case that the form's action cannot be completed due to validation or other error, the form will need to be re-displayed, and it sure is nice if it looks the same as when the user pressed "Submit".
This problem is typically solved by a lot of glue code, or with tools like HTML_QuickForm or patForms.
PHOCOA provides a complete UI state-maintainance mechanism. A full set of widgets are provided that represent all HTML input types. Each widget automatically maintains its own state. It is also possible to create custom widgets to promote re-use of complex widgets such as color pickers, date pickers, etc.
Centralized Dispatch Architecture
Web applications typically have many "actions" that can be performed by the user. Developers need a way to easily determine which action was requested, and a way to dispatch this action to the correct handler.
This problem is typically solved with a Front Controller pattern.
PHOCOA implements a Front Controller that locates "modules" in unlimited folder structure. PHOCOA also allows your modules to access PATH INFO data to promote friendly-URL use.
PHOCOA is an event-driven architecture as well, automatically dispatching control to your action handlers in response to FORM submissions.
Request Variable Normalization
Web applications should take care to prevent XSS (cross-site scripting) attacks caused by user manipulation of the request data.
This problem is typically solved by writing code to filter all incoming data to make sure that it's valid and meaningful.
PHOCOA's UI state management only responds to manifested FORM parameters, reducing XSS attacks.
Data Validation and Normalization
Data input to a web application, whether via Path Info or Form Submission, needs to be propagated to the model and validated. Ideally, you should be able to detect multiple problems at the same time to make the site easier to use. At some point the data must also be normalized. The errors must then of course be shown to the user.
This problem is typically solved by a number of methods: pre-validating data, integrated validation code in model components, etc.
PHOCOA provides a complete solution for data validation and normalization. A concept called Key-Value Coding provides a common infrastructure for writing validation methods on any object. Normalization of the data occurs inside the validator. Beyond that, the PHOCOA infrastructure provides a centralized location to track all errors in a single request. PHOCOA also provides an easy way to display these errors in the UI. You can list all errors as well as errors for each individual widget.
Web Application Configuration and Deployment
There are many settings that are application-wide and need to be accessible by all parts of the application. This global data can be broken down into two types of data: data that is the same whether the application is running on a Production or Development server, and data that is always needed globally, but changes based on the Production/Development status.
Typically this problem is solved by include files.
PHOCOA configuration handles both of these situations. Application-specific configuration is typically handled by the WFWebApplication object via callbacks, and Deployment-specific configuration is handled via a conf file.
Sometimes web applications need to keep state across multiple requests that is linked to a user's session.
This problem is typically solved using PHP's Session API.
PHOCOA doesn't yet provide any session infrastructure. You are of course free to use PHP's $_SESSION global to manage your own session data.
User Authorization and Authentication
Many web sites today have a "login" capability. Users can log in to access additional functionality or personalization. While the specifics of what a logged in user gets vary greatly among applications, they all share the need to perform authentication.
This problem is typically solved with a special web page to perform authentication, followed by keeping track of the user in a session context.
PHOCOA has a simple authorization infrastructure that requires implementation of only a few methods to login-enable your application. A simple interface allows your back-end application to use whatever authentication protocol is appropriate. PHOCOA's authorization manager also includes support for "Remember Me" functionality.
Component Re-Use and Compositing
Many web applications have "snippets" of functionality that need to be re-used througout the site. Search, login, headlines, are often self-contained "portlets" of functionality that should be re-usable.
This problem is typically solved via includes.
PHOCOA provides a rich compositing architecture. Each module you create is automatically re-usable in other modules, or in the skin itself. PHOCOA provides a variety of compositing and targeting capabilities for ushering users through the site.
Pagination is the "chunking" of large data sets into smaller portions. This prevents a web page from being infinitely long. Pagination also typically includes sorting options for the data set.
While many data access layers already have pagination support, developers are typically left to handle the UI portions of pagination on their own.
PHOCOA provides out-of-the-box support for pagination of PHP arrays, Propel Criteria-based data sets, and raw SQL data sets via Creole. Propel includes several pagination widgets to aid in the display of the paginator navigation, and to help with the process of switching pages, sorting, etc.
Modern web sites need to have clean, simple URLs (i.e., such as www.mydomain.com/products/myProduct) to provide a easy-to-remember URLs and be search-engine friendly.
This problem is typically solved by parsing the PATH_INFO from a URL into your own data structure, then displaying the desired page.
PHOCOA's request parameter system makes it easy declare a clean URL interface for any page.
Interactive web sites built with AJAX are becoming more popular as web users demand that web applications become as interactive and responsive as their desktop counterparts.
PHOCOA's AJAX implementation wraps industry standard AJAX libraries such as prototype.js and Yahoo's YUI library to make it a snap to build rich, interactive web pages.