Maybe you’ve used a CMS like WordPress, Drupal, or Joomla. But what if those had too much baggage? Too much dead code? Too much un-tested code or code that’s so cumbersome to use you’re stuck building your own?
I’m thinking about starting another book this summer called Build Your Own PHP CMS. Not only will I update Build Your Own PHP Framework, but I’ll describe in detail what you’ll need to do to create your own CMS from scratch.
There’s almost a hundred different PHP frameworks out there. Some are big some, are small. All of them do about 80% of what you need the way you want it, but the 20% that’s not usually takes you the most time/effort/money.
This book shows you how to build your own PHP Framework using a PHP Framework template called GinPHP.
Visit the website to learn more http://www.phpframeworkbook.com.
MVC (Model View Controller) design patterns all the rage, in fact, the MVC pattern is pretty much standard with every web framework.
The idea is to keep code separate, the assumption is that with this separation comes ease of maintenance, and allows for developers of different skill sets to work in different areas. Here’s a short description of each:
- The Model – This represents the data that the application operates.
- The View – This represents the web pages that render the model in a form that makes it easy for users.
- The Controller – This takes input from the view, calls associated model classes, and manipulates that data and input with business logic to direct the user to another view.
The reason this was created was because of Model-1 Web Design. Here you had business logic, model logic, and display all on the same dynamic web page usually a JSP (Java Server Page) or ASP (Active Server Page). This was ugly and certain parts of maintainability were hard, but was efficient in certain aspects.
The problem comes in with MVC is an over engineering and overly abstracted mechanism for just pushing data into and out of a database, which is essentially what a web application usually is. So how can you avoid the problems of model 1, with the over engineering of model 2? You use a Model 1.5 architecture.
What is Model 1.5? Well first it will help to describe Model 1 and Model 2.
Model 1 – This is a web application design pattern for web scripting languages like JSP, ASP, or PHP, that take all the elements of a web application, business logic, data abstraction and connetions, and presentation/layout then puts them into a single page, or script.
Model 2 – This is a web application design pattern that separates the elements into an MVC design pattern, MVC standing for Model View and Controller.
Introducing the Model 1.5 Design Pattern.
This pattern takes the efficiency of model 1, and component of model 2 and combines them into something that is both efficient and maintainable.
What does it look like?
First, the application consist of web pages (scripts) that talk to other web pages and use a set of objects to communicate with the database or encapsulate the business logic.
Second, the application employs functional programming techniques, to share business logic across different web pages or areas of your application.
Third, the database layer is generated and employs a inheritance model that allows for overrides of certain CRUD operations, while at the same time providing application specific functionality and very easy level of maintainability.
How many times have you heard that Framework fill_in_the_blank will save time and prevent developers from doing things their own way. Or Frameworks save time by eliminating some of the redundant work on application development.
These might be true, but how many times has a the same framework been proposed for creating a 5 page website, or using an entire logging framework to write the results of one job to a text file, when no one ever reads that log…
So I will create the following rules for when using a Framework is OK, if it does not pass this test, roll your own.
- Does the framework configuration/ training take the same time or longer than the coding of said functionality? If yes, don’t use a framework.
- Is application connecting to multiple tables for Create, Read, Update and Delete transactions? If yes, perhaps some type of database framework is needed, that could be it, don’t install an elephant when you need a mouse.
- Does application require standardization for reuse/resale or for multiple programmers of varying skill? If yes, use a framework unless it contradicts with rules 1 and 2.
- Is application or library going to be reused and distributed open source? To facilitate the code and adoption it’s often easier to create when people are already use to the patterns and coding of an application, in this case, unless it contradicts with the rules above, use a framework.