I had kinda given up on my PHP framework (as I’d mentioned in “Simplicity via PHP Frameworks” article). But as I embarked on another little web project and realized that I might benefit from some helpers in case the project grows to become less “little.” I could’ve started with a new micro-framework or I could dust off my languishing ccPhp framework. Since my goal with the framework was to get up and running quickly, I figured I’d recall its use quicker than trying to figure out a new one.
So, I pulled the source from my Github repo. It included a small sample—perfect for quickly getting started. I quickly found out that I had left the source in a non-working state (my attempt to use namespaces). There were other gotchas that I had to refresh my memory about (not to mention refreshing my PHP proficiency). So, it did take longer than I would have liked to get up and running.
Getting away from the framework for a while had another backhanded advantage: brain cells familiar with the framework’s details have died, leading me to a fresh look at the framework. I found that it was not as easy to get to core business logic, as I would have liked. What became obvious to me as I was developing the framework, was no longer obvious. Also, my approach for how to solve the problem was a bit different than what I anticipated when I wrote the framework.
I realized that I needed to better describe and organize its interfaces—a refinement rather than a revamping of the original design. I finally added a brief README.md file to the Github project, put more thought into simplifying the interfaces, and refined the code. This should all help get people (including myself) up and running more quickly.
Crystallizing ccPhp Concepts
As I wrote the readme, I crystallized my original concepts more succinctly. I noted that, at its core, it has a very programmatic approach to building a web page. That is, it assumes PHP code will be used to generate content… PHP and content, mixed. Though that can be circumvented through the use of adjuncts (e.g., the Smarty controller that was originally implemented), the base primitives presume PHP/content mix.
Focusing on usage of the framework, I identified different approaches to its usage.
- The original approach assumed the creation of a public stub file that directs to an application-specific bootstrap file (e.g., app.php) which links to the framework via ccApp.php. From there, create a class to generate content. To start, that can be contained in one class, extending one of the provided base classes. This is three groups of code, the public code, the app-specific code, and the framework.
- We can simplify this for some scenarios by allowing the content generation class to be the sole application implementation class. It would link to ccApp.php, but a lot of the content of app.php could have default settings which would be implemented in the ccApp.php framework initialization. This would reduce the minimal groups to two, the public code and the framework, for simple applications.
- Since the approach is programmatic, it would be nice to have a structure that directly paralleled HTML structure.
The original framework purposefully did not impose rules about the organization of application files. If more assumptions were made, e.g., file/directory organization correlating to URL structure, these simple starts could be built upon as needed.
Most of this can be done with adjuncts to the existing framework, with some thought. You can assume that most of this will be part of its evolution.
It took longer than I would have liked, to get up and running. The good news is (1) that I “fixed” problems that I’d left the source code and, more importantly, (2) I have refined the framework to better meet my goal of being easy to use. Knowing too much can lead to a less than ideal solution. Microsoft has shown this, too, in their past. ccPhp is alive, again!