Blueprint for PHP Applications: Cornerstone

[ previously in this series: PHP Best Practices: Creating A Blueprint for PHP Applications ]

Bringing together a library of PHP best practices is no small feat. Even though there are numerous repositories of PHP information spread throughout blogs, Wikis, magazines and PHP web sites; it is not easy to pull together a consistent and complete picture. The detail provided doesn’t always fit with the detail provided by someone else. Nor is the context always present to give you the Why, What and How in one bundle of knowledge.

In order for us to do this blueprint building and to provide that full view, we will need to have clearly stated goals and focus. This “cornerstone” of the blueprint process is just that.

Process

The process for developing the Blueprints for PHP Applications can be simply stated as:

1. Define an application area or component
2. Publish a straw-man set of best practices and samples for that area
3. Receive community feedback and iterate
4. Integrate best practice into library and application kernel
5. Integrate best practice into reference application
6. Repeat for the next area or component

Now having said that, expect that the process will change and be tuned for what actually happens and works best. But like anything, you need a starting point and that is exactly what this is.

You may ask, “why start with a straw-man rather than community feedback on the area and THEN build the straw man?” This is a very reasonable question (and suggestion), but there is nothing harder than starting with a blank slate and asking a large body of people to build something from nothing. Without a starting point it can become an endless argument, an unfocused effort, or may sit there with everyone waiting for it to begin. It could also end up a masterpiece. But to avoid the other higher probability outcomes we will start with a straw-man that can be wrung through the machinery of the community to find the best answer at the end. The straw-man will be based on research from the current body of knowledge available for the subject area, and possibly even new ideas and challenges to the status quo.

Concrete Goals

The goals as stated in PHP Best Practices: Creating A Blueprint for PHP Applications are to end up with a full mental picture of what makes up a typical PHP application, an application kernel demonstrating best practices at the core of the application, and a reference application showing broader use of all recorded best practices in their natural habitat. This will be manifested as:

• A series of articles exploring the best practices, generating discussion, and rounding up the community
• A living document that describes an application, components and functional areas to act as an architectural guide and vocabulary
• A living document that is the library of best practices as extracted from the series of articles
• A repository of code representing the application kernel with snippets made available to the prior documents
• A repository containing the reference application

This group of deliverables must live and breath together and stay up to date and in sync at all times. It is a living cookbook for building PHP applications as well as a manifestation of the practices in running code. Navigation through the blueprints should work in all directions: from the diagrams to the practices to the code, conversely from the code to the practices, from the diagrams to the code, and so on. Context will always be maintained.

Some of the difficulty will be in mixing different ways of looking at some of the same areas of an application. For example, security will intersect the front-end filtering of input parameters, and also the back-end creation of SQL for the database, not to mention many other places around and in between. Internationalization (referred to as I18N from now on to reduce typing of a very long word) will matter everywhere from front-end input through storage options for your database, affecting indexing collations, time zone support, translations and process. Other areas are less broad and focus in depth on one specific area. The model for presenting the blueprints will support these different intersecting and localized views.

Philosophical Goals

We have a process. We have concrete goals. But what do we care about, what makes this blueprint usable, how do we pick between option A or option B? We need a guiding philosophy. I happen to have one handy, or at least a list of core tenants:

• Nothing stands in the way of our application’s success
• Simple is better, but not to the extent that we sacrifice what we need
• Readability and understandability over saving bytes of code
• Auto-discovery over configuration, reams of XML config files need not apply
• Flexibility keeps us nimble
• Open-mindedness will hold the greatest truths
• Generalize first, then specialize once you have that under control

This list will not answer every question we face yet it feels good to have it coaching us along. It is a philosophy, not a rule set. Take it for what it is.

Application Model

The brainstorming diagram in PHP Best Practices: Creating A Blueprint for PHP Applications starts to show that there are distinct areas of web applications. What it doesn’t show as well are those overriding subjects that intersect multiple areas. What we need is a way to talk about the application model working with at least four levels:

1. Elemental
2. Component
3. Architectural
4. Overriding

Elemental issues are small, stand-alone topics that apply anywhere a situation applies. For example, using PATH_SEPARATOR to build path names rather than literal slashes, or better yet using a path building class or helper function, or a URI style class to make sure we always build platform neutral paths correct for the protocol and use. See? Focused on one small topic.

Components are nice size functional areas of an application. Application configuration, session management, page messages, form handling are all examples of component-level items. They work within boundaries and do not tend to overflow (that much) into neighboring territory.

Architectural goes a step larger with topics that cross components, or deal with their interaction and their structure. An example would be exposing services to both the outside world as well as internally so that you can work easily between traditional web, AJAX and remote service client models. We will dance between component and architectural issues frequently as one affects the other.

Overriding are items that you must remember everywhere and apply at all times including I18N, Security and Scalability. These will impact all other levels from Elemental through Architectural. If you do these wrong in one place, you pay later. They are therefore always in the back of our mind and will be sprinkled throughout other discussions.

As we work through best practice after best practice, they will be categorized into these levels and related to each other as needed.

Getting started

About now you are wondering if I will ever stop talking about the best practices and get on with actually working through them. Guess what. Coming soon… Blueprint for PHP Applications: Bootstrapping

Digg This!