Do you have any comment on it, good, bad or otherwise? I’m about to start converting one of my old scripts to see how it comes out in OOP.
Hi captainccs,
Sorry for taking a while to get back to you… I had taken a step back from thread for a couple days as I wanted to give the topic some more thought before going on, and I saw that you were working through the Codeigniter tutorial - what do you think to it?
I have to admit that I’ve never tried to build my own framework. I’ve used several different ones to build various projects, but I’ve never actually sat down to build my own, so it’s given me some pause for thought.
In response to the description of how your framework currently works, what I would say is that if you’re going to stick with the Page Controller-style approach (i.e one file per ‘page’) I’d move all of the html (even if it is a basic shell) into separate files under a template folder. It will avoid duplication of the layout markup, and makes it possible to swap out the view based on your controller logic - if you wanted to return json instead of html, for example.
I’d be interested in delving a little further into how you currently structure your app-logic.php file (I’m assuming this one is common across all pages? or is it page specific?) and the app-module.php file. What kind of actions might the switch handle? Would you be willing to go through those for a page from your bmwmethod.com site? I thought http://bmwmethod.com/screens/screens.php?side=buy might be interesting to talk about, as it serves different content depending on the ‘side’ parameter… and would it also be an example of two different modules on the same page?
Neat and simple. I can understand people liking it.
I have to admit that I’ve never tried to build my own framework. I’ve used several different ones to build various projects, but I’ve never actually sat down to build my own, so it’s given me some pause for thought.
So much to do, so little time! My problem is that there are too many choices, it takes time to learn any choice you pick and if for any reason you don’t like it or it doesn’t work for you you have just wasted a lot of time. In my trip to the present I fell into several holes, for example, at one time I signed up with a hosting service using Sun servers. Big mistake! I lucked out when I picked php. I didn’t really set out to create a framework but when I got serious requests for back end code I figured I best do it in an organized fashion and the framework evolved. I didn’t sit down to design a framework, it evolved. BTW, I have no formal education in computer science, when i started out it was flying by seat of the pants.
In response to the description of how your framework currently works, what I would say is that if you’re going to stick with the Page Controller-style approach (i.e one file per ‘page’) I’d move all of the html (even if it is a basic shell) into separate files under a template folder. It will avoid duplication of the layout markup, and makes it possible to swap out the view based on your controller logic - if you wanted to return json instead of html, for example.
I’ll have to think about it. Actually, in some projects I have done something similar.
I’d be interested in delving a little further into how you currently structure your app-logic.php file (I’m assuming this one is common across all pages? or is it page specific?)
It is application specific. A website can have multiple applications (blog, contact, whatever) and an application can have multiple pages
and the app-module.php file.
There can be as many “module” files per application as there are distinct views but often I put several related views in one file inside a switch similar to the action switch (see below). A module can be an AJAX response, an html form, a feedback message, the requested output. Whatever the browser is supposed to show.
What kind of actions might the switch handle?
There is some difficulty in the nomenclature. In a piece I read recently the “Controller” refers only to routing the url request to the right code or the right page. I don’t do any of that, I let Apache do it. The controlling part of the application is then called “Command.” That’s what my app-logic does.
The browser requests a page and that’s the page that is served unless it’s a 404, 301 or some other error code. The custom error pages are delivered via .htaccess and the 301, 302 either through .htaccess or my php code. If the code is 200 OK then the app-logic takes over.
It determines if the request is a GET or a POST and what “action” is requested (from the link or the html form). Up to here the script is somewhat standardized and it will become much more so in the OOP version. The rest of the script is one or two switches based on the “action” requested.
switch ($action) {
case "":
// usually first GET with no requests
case "Review":
// review logic
case "Edit":
// edit logic
case "Submit":
// submit logic
default:
// mostly error handling
}
A lot of the code are common functions for error checking, sending email, etc.
Once the “logic” is done the html page renders and the various include modules render the views. I have a bit of a muddle here as sometimes the logic gets the data and sometimes the view gets it. I need to organize this better. But the sql code is in a separate sql.php file.
Would you be willing to go through those for a page from your bmwmethod.com site? I thought http://bmwmethod.com/screens/screens.php?side=buy might be interesting to talk about, as it serves different content depending on the ‘side’ parameter… and would it also be an example of two different modules on the same page?
The screen page is unusual in that I found it best to have two versions of it: buy side and sell side. It’s the same code with different parameters, different defaults.
It is also unusual in that the screens have more than one form and you can request different results. Otherwise it’s all the same:
A get request is always for a fresh page (even if it’s the same page) with or without queries. A post request is different in that the user is looping through the form:
request the form (usually a get)
fill the form
review the form
edit the form
review the form
submit the form
In some cases a form can send the user to one of various pages.
As I think about it, in the OOP version there is likely to be Dispatcher class, a Switch class and a Case class and they need to collaborate creating the action part of the forms. This has been a good exercise in thinking about the conversion to OOP! 
fretburner, converting the contact application was quite easy. I still have to connect it to a database and to the mail script. With OOP the code is more granular. The ‘view’ is strictly view, no processing. I broke up the module file into separate files, each one has a single view. The “command” script controls what the html page pulls in. Initially I worried about how much code the starter script would need but I’m pleasantly surprised by its brevity:
require_once "{$include}classes/_autoload.php";
$cloner = new Cloner;
$contact = new Contact("{$include}contact/");
// set the dependency injection
$contact->setSession($cloner->getClass('Session'));
// notice the "_es" it's the way to localize the feedback
// 'EmailAddress_es' extends 'EmailAddress' - just changes the feedback text
// I'm still thinking about ways to localize classes
$contact->setEmailValidator($cloner->getClass('EmailAddress_es'));
$contact->setFunctions($cloner->getClass('Functions'));
// go do it
$contact->process();
Maybe consider other PHP Framework approaches that use the .htaccess file to route every request to the hidden index.php file. Next to be implemented is the ./config/router.php script that selects the first exact match, if there is no match then the final route is to the 404.php error file.
Instead of the final 404.php file I prefer to route the request to a search controller that parses the URL, searches the database for keywords and return with a list of possible matches. If no match is found then suggest a specific post.
A possible browser command line search “http://mysite.com/this is a test to see if it works” suggests 9 possible matches. Far more user friendly than a modified 404.php with “Error 404 - Page not found”, helpful suggestions and a link to your home page?
That’s “User friendly 201!”
I can implement that without any change to my file structure or changes to .htaccess since my current 404 page is in fact a script. Every page in my setup can be a script by simply adding a bit of php at the top.
$include = "/path/to/include/folder/";
include "{$include}/error404/start.php";
Hi captain,
It certainly looks like you’re headed in the right direction there. I was thinking of suggesting using an autoloader, but you’ve beat me to it!
I do have a suggestion for you on how you could deal with the localisation. Rather than creating additional classes for each language you’re supporting, you could keep your localised error messages stored in separate language files as an array of strings and have your validation classes return messages in the currently selected language. Translating a site into a different language is then quite straightforward, as you only need to provide a new set of language files and localised templates.
I’ve a couple of questions about a few other things in your code snippet:
- You’re passing in a path string when you initialise your Contact class - what does Contact do with this information?
- You’re passing in session, email validator, and functions objects via setter methods - could the Contact class function without these dependencies?
- What does the Functions class do?
Btw, thanks for the comprehensive reply to my previous post… I do intend to reply to it, but I probably won’t have time to write up my thoughts until this evening.