Just been looking at the way I am structuring my classes and wondering it there is a better way.
I have forms which pass the information through to the process class. This class just forwards everything onto my main class which then does the work. When the work is done, it then passes the information through to the database class to carry out the sql.
If in the main class there is an error, the error goes back to the process class. The process class sets a session variable true is the error is there.
It then goes to the referrer which is the original page and on that page I have code which leaves an error message if the session variable is present.
I know this possibly isn't the best way to explain things, but does it sound like a reasonable way to do things?
I am just trying to improve the way I write classes!
Thanks
The workflow you describe somewhat reminds MVC but it probably isn't. If you are interested in making the internal architecture of your application more structured and easier to understand then here's something to read and experiment with:
Model-View-Controller
The Model-View-Controller (MVC) Design Pattern for PHP
Model View Controller MVC tutorial
Related
** simplified question **
I am learning oop patterns and I am looking to build my own simple mvc framework. I would like this to have a front controller but I am finding it difficult to find any credible information for implementing a front controller with MVC.
In particular I am confused about whether the front controller should initiate the entire triad or whether the front controller simply calls the controller and the other parts do the rest.
I have noticed classes like route, router and bootstrap and I am wondering what these particular classes do and whether they are dependent on the front controller itself.
Actually that's not a question, you're just trying to get suggestions on how to proceed while building your own MVC framework.
So I'll try to provide an answer / consideration as generic as your question.
1) "I'm learning OOP Patterns": patterns are as much powerful as dangerous in the wrong hands. What I'm trying to say is that you should start building your fw without trying to use every patterns you come across the net just because it is used or talked about by the big ones. You can refactor you code later providing each step an higher level of abstraction: this will naturally involve using the patterns you'll be reading about and a better understanding of them.
2) "confused about whether the front controller should initiate the entire triad": that's up to which level of coupling you're aiming to have in your mvc.
You can have your Front Controller handling everything like:
bootstrap: load config and instantiate database connection and so on
request: get the needed data describing what was asked
route: handle the request
response: return what was asked
But what if the configuration is needed somewhere else? Maybe in a CLI running script? You'll be naturally detaching the bootstrap component from the router to use it anywhere else is needed. And the same is for the other components.
3) "classes like route, router and bootstrap".
Imagine to have your big class handling everything. How will you be testing your methods? Will you manually call the script with different inputs? Will every testing method have to check for the input, the routing and the output at once?
Providing an abstraction level upon every component involved in your Front Controller encapsulating it in a proper class/object/module, will give you far better testing capabilities.
I'm talking because I've been down that road before creating exactly what you're talking about: https://github.com/OverKiller/PHP-Router
But I had to face hard testing capabilities and deep coupling.
I'll be rewriting it soon, abstracting the request, the route and the response component.
But I had my experience and I'm proud of it!
You should do the same.
What I'm trying to say is: do not try to build the next Ultimate SymZendCakeIgniter PHP Framework all at once.
Take your time, take your time to read and take your time to learn.
And for god sake: *even before reading anything about design patterns get a nice book about T-E-S-T-I-N-G
I hope I was useful.
My problem is actually not the ajax loading itself, more the capability to load it without javascript. I mean, I cope easily when I code my whole project just based on ajax-availability OR just without the use of ajax.
//EDIT: Although Arend already had a more or less valid answer, at the same time 'there is no direct answer to this question'. However, I'd like to see some other approaches of developers for scenarios like mine though! Even just a few links can help!
Basically I just get frustrated, coding everything twice on the same page to make sure that both users without and with Javascript enabled have the same experience. It's annoying and I was always wondering how others solve this problem.
When I update for example two divs with dependency on the same variables, it gets messy. Here's an example:
non-js-version
require 'classobject.class.php';
$another_var = 'something';
$class = new classobject($_POST['variable']); // just an example to show that this is dynamic - I'm aware of injection!
$function = $class->returnsth(); // returns 1
if(isset($_POST)) {
echo '<div id="one">Module 1 says:'; $require 'module_one.php'; echo '</div>';
echo '<br /><br />';
echo '<div id="two">Module 2 says:'; $require 'module_two.php'; echo '</div>';
}
Now in module_two.php and module_two.php I have code that executes differently depending on the return variable of $function.
Like:
if($function >= 1 && another_var != 'something') {
// do stuff
}
else {
// do other stuff
}
Now as this works easily with a reload, when I want to load the two modules on keyUp/enter/submit or whatever, I have basically a few problems:
I have to send the $_POST variables manually to the modules to use them
I have to re-execute the class & it's methods and make a link (require_once) to them in each of the module-files.
As $another_var is not existent in the modules, I'd have to send this variable to each modules, too (with post for example) and then before it can be used, I'd have to 'change' it like $another_var = $_POST['another_var'];
I find this mildly annoying and I wonder how you guys do that. I hope my way of coding is not too silly, but I can't think of another way. It's probably hard to relate to my very basic example, but to bring a whole project with the code would be too much. To sum it up, I'm looking for a better way to code and clean this mess up - there must be a way! I thought about sessions, but for compatability I don't want to rely on them either (if someone doesn't allow cookies).
In case you can't relate to what I'm trying to accomplish with that way of having my code assembled, I'll explain a scenario I'm facing quite a lot (not important if you already understand my misery):
Basically I have my index.php page where everything gets executed, with the html body and css styling and so on. This page expects some variables, that get set from the page that requires the index (like $another_var in my example).
Now other variables can get set too (from a form for example). Depending on that different classes and methods load new variables (arrays) that get used in while-loops in my modules to echo everything out.
Hope that's not too abstract. Think of a booking system where some variables are set from the page you are coming from (the event you want to book) and then a few more things get set by the user (a timespan, some preferences,...). In the end it's supposed to show results from the database all the way to the end-result - you can say the user narrows the results from step to step.
There is no direct answer to your question, but there is some food for thought.
Seperation of concerns
You can think about if you can perhaps seperate your buisness logic and layout logic. Often the use of a template engine can help greatly with that. I've had positive experiences with for example Twig or Smarty (was some time ago, not sure how they measure up right now). It requires you to write your code in a (less linear) way, but more logical.
A typical example of an OOP like seperation of concerns might be something like this:
$this->setParam('Myparam','myvalue');
if ($this->isAjax())
{
$this->setTemplate('ajax.php');
$this->setLayout(false);
} else {
$this->setTemplate('normal.php');
$this->setLayout('Mylayout');
}
return $this->render();
It is an imaginative situation, which can be found in many MVC like applications and frameworks. The main idea is that you should have the possibility to seperate your layout from your data. I would suggest looking at some of the modern frameworks for inspiration (like symfony, codeigniter, zend framework).
Glossary / Often applied concepts in a decoupled PHP application
Here is a quick list of concepts that can be used.
Example mvc in php: http://www.phpro.org/tutorials/Model-View-Controller-MVC.html
Note: I don't really like the implementation. I much more prefer the existing frameworks. I do like the explanation in total of this tutorial. E.g. for me this link is for learning, not for implementing.
Silex
For a simple decoupled php micro-framework I would really recommend silex, by the makes of symfony2. It's easy to implement, and to learn, but contains mainy of the concepts described here; and uses all the php 5.3+ goodies such as namespacing and closures.
see: http://silex.sensiolabs.org/
Frontcontroller Pattern
Only have one, and one only point of entry for your code. I usually only have one, and one only point in your application. Usually a frontcontroller 'dispatches' the request to the rest of the application
http://en.wikipedia.org/wiki/Front_Controller_pattern
Routing
A routing system is often used in combination with the frontcontroller pattern. It basically describes which URL is connected to which module / controller. This allows you to change the way people access your app without changing the urls.
See: https://stackoverflow.com/questions/115629/simplest-php-routing-framework
Controller
A controller is the place where buisness logic is applied. Getting the data from the database, checking privileges, setting the template, setting the layout, etc. (although this is also moved outside the controller if it becomes too big of a seperate concern).
Model
The model basically is the layer in which use manage your database. This can be a simple class where you move all your mysql_* functions, or it can be a full-featured ORM. The main philosphy is that all the logic related to fetching and placing information in the database is seperated.
One step up: ORM
An often used method in applications are Object Relational Models, these 'map' SQL records to PHP objects. Doctrine and Propel are two of these well worked out libraries. I heavily rely on these systems in my development. In this sense, the doctrine or propel part will represent the model layer.
Doctrine: http://www.doctrine-project.org/
Propel: http://www.propelorm.org/
Other ORMS: Good PHP ORM Library?
PHP ORMs: Doctrine vs. Propel
View:
The view usually consists of a templating engine. Some use plain PHP as a template, others, such as symfony create a seperate scope in which variables are placed. There are many discussions and opinions about what is best, one is right here on stackoverflow:
Why should I use templating system in PHP?
PHP vs template engine
Ones I like:
- Twig: http://twig.sensiolabs.org/
- sfTemplate: http://components.symfony-project.org/templating/
- Smarty: http://components.symfony-project.org/templating/
Decoupling mechanisms:
Event based systems
Using events in your can help to seperate the code. For example if you want to send an email after a record has been saved, events are a good solution to do that; in general the model should not have to know about email. Thus events are a way to connect them: you can let your -email-send-class listen to certain records in order for them to send the right email. (Perhaps you'd rather want your e-mails send from your controller, this is probably a matter of taste).
Dependency injection
When using OOP code in PHP many relied on having singleton classes running around (configuration, etc). From an OOP point of view, this can be considered bad, because it's hard to test it, and it's not considered very elegant to have dependencies running around like that. Dependency Injection is a pattern that came form Java and is now used in the newer frameworks to get around this. It might be a bit difficult to wrap your head around, but you will see it coming back in several new frameworks.
Dependency injection in php: Dependency Injection in PHP 5.3
Frameworks:
A lot of these methods are difficult, or a lot of work to implement yourself. Many will reside to a framework for this. You may or may not need a framework. You may, or may not want to you a framework, it's your choice. But it's still useful to learn how the frameworks do it, and not try to reinvent the wheel yourself.
The no-framework php frameworks: https://stackoverflow.com/questions/694929/whats-your-no-framework-php-framework
Good habits: https://stackoverflow.com/questions/694246/how-is-php-done-the-right-way
Frameworks worth looking at (imho): CodeIgniter, Kahona, CakePHP, Symfony (1.4/2.0), Silex, Zend Franework, Yii. There are many many more, each with their dedicated fans and haters.
I wrote something like this with PHP. I already had abstracted the rendering of every page such that I define a $content variable and then require('layout.php'). The $content variable is just a big HTML string.
I wrote a PHP function to determine if request was AJAX or not.
The non-AJAX responses render the layout with $content in the middle, b/t header and footer layout content.
AJAX requests basically get this: json_encode(Array("content"=>$content)). And I use jQuery to get the HTML out of the JSON response and modify the DOM. Using json_encode() will handle escaping the string for javascript.
In the end, I effectively have AJAXified every page w/o over-engineering a complex solution.
Any browser that supports AJAX can also open a link in a new tab/window to simulate the non-AJAX request. (Or bookmark/share a link, too.)
Greetings all!
Looking for some help with MVC in a PHP context. Currently I am building a small, lightweight MVC framework to help expedite application development at work. It's a long hard separation eliminating inline code - at least with numerous projects looming overhead and the temptation to utilize it ever-present.
I understand most of the basic requirements of MVC, and I've already begun porting some of my existing classes that are in Singleton pattern over as utilities in my new framework (these are mostly basic 'handlers' to perform site services - a class for file uploads, authorization, wrapped PDO database queries, error printing etc.)
What I can't seem to grasp moving forward after reading much documentation is the best approach to instantiating views. In my old, inefficient design I would switch off a $_GET variable to switch ouput from within the home view. Just going off intuition, this seems like an extremely bad way of getting the job done.
I've looking into CodeIgniter, and it would seem that there are predefined functions for loading views within that framework. What is the best approach to such an application design? Would it be a class based 'link factory' that utilizes the same variables to fetch content, select the proper view file, and place it in the page flow? Also, how could the new view be included between the header and footer includes in the root index without using switches? This is the only thing really confusing me - I really hope I have worded myself clearly enough.
Thanks all as ever!
I highly recommend "PHP Objects, Patterns, and Practice" by Matt Zandstra. A good bit of the book deals with creating MVC frameworks and would be very, very helpful to you.
It covers these patterns (which you can also research elsewhere):
Front Controller
Application Controller
Page Controller
Template View
View Helper
While I'd suggest going with an established, flexible framework (like Zend), to answer your question, here are the steps involved as I see them (understand I stopped trying to write this kind of stuff a while ago, this is based on my understanding of the existing frameworks I've used).
Some kind of router parses the request and translates to a controller object with an action (or takes the default) and optional parameters. The router then calls the controller object's function matching the action.
The controller object (usually extended from a generic controller object) process the request and determines what data to pass to the view, as well as what view to use. Most frameworks setup a default view based on the action, but ultimately it's up to the controller to decided what view to use.
The view takes the data and displays it.
That is my very simplified take on the process.
I am in the early stages of creating a small-medium sized web application by myself. I read "PHP Objects, Patterns, and Practice," and I decided to use page controllers because quick production is a high priority. Page controllers were also appealing because I am unfamiliar with PHP frameworks and creating an elaborate front controller seems to currently outweigh the project. My plan is to release the page controller version of the website ASAP and see if the audience likes it before committing to more complex software designs.
That said, I might decide to add more 'modules' and developers down the road...at which point I really should switch to a front controller. The above mentioned book describes that "it is not impossible to start with page controller and move toward the front controller pattern," but the wording of "not impossible" has me worried that it may be fairly difficult.
My questions are:
How 'hard' is it to make the transition from page controller to front controller design? While working on my page controller-based app, what should I be careful with to create code that allows a smooth transition to front controller design? The ideal situation would be to rewrite/restructure the code as little as possible and tack on the front controller with related classes/objects. Right now I'm only cautious about maintaining MVC, so any advice from experienced developers would be great. Thank you.
I think your main concerns should be to put "business logic" into properly designed model classes. In other words, don't put such logic in your page controllers directly. Instead, use your page controllers to parse input, such as GET and POST, instanciate the correct business logic objects, and call the correct methods on those to do the actual data crunching.
The page controllers should also be responsible for choosing a view to display - don't output things in the business objects, simply return data for the controller.
By using this approach, you should have most of your code in the model classes, and if/when you want to rewrite to using front controller, you will only need to change the page controllers to work with a front controller, hopefully not having to modify anything else.
I read the book you mentioned about 3 or 4 years ago as a first introduction to object oriented programming and I found it a great book, but I have to say that I only really got to grips with the whole thing once I started to use CakePHP and root around in its code to see how things are done in practice. The examples in the book can be a little confusing at times.
I recommend having a second look at some of the frameworks out there, Cake is good, Yii is meant to be even better. It doesn't long to get a system set up with them, and as long as you're prepared to have a good look under the hood, they can be an invaluable learning tool.
I am trying to create simple php framework .But i am not sure about class structure for example which classes should extend to which classes .Firsly i am know that some basic classes such as Router , View classes have to access some basic data such as requested url or requested ccontroller and action so how can i import basic data to these classes .If my question is not clear please explain your own experiances and ideas about frameworks.or if you know please talk about known framewoks such as zend , cakephp or symfony
There is no best class structure. Depends on what you are trying to do. Do you mean purest MVC design? Most testable? Most easy to understand?
There is a simple rule of thumb:
Either you have a need that the standard frameworks can not fulfill
or you should use a good standard framework that does what you need.
In the first case the restriction will be the driving aspect in your design.
There are no general design rule for class structures in frameworks. But try to keep this in mind, if you decide to write your own one:
Minimize dependencies between modules
Always try to give default values
Try to minimize the overhead
Talk a lot with peers about it to find flaws early.
If you've never worked in someone else's framework you will have no idea what ideas work for you and what don't. If you've only ever worked with dis-organised spaghetti code, then you will have some idea of what makes sense for you. If you've made substantial re-organisation to dis-organised spaghetti code in more than one unrelated project, you should have a good idea of how you think in building a framework. :-)
If you don't have a firm idea of how you want to write a framework, but you want to write one, I think you need to start with nothing and build it organically. However, you should have some idea how you want it to look like, even if it's something as silly as where you want the include files to live. In other words, all you need is a starting point. Then it's a matter of re-factoring ugliness as you encounter it. Before long, you will have a database handler, a dispatch mechanism, perhaps a data access layer, just maybe even a templating system!
Responding to #MrFox, though, you should be aware of dangerous dependancies. Obviously a data access layer will depend on a database handler; so what you don't want is for your database handler to depend on your data access layer. In fact, you don't want them to have intimate knowledge of each other, either. It should be a reasonably "black-box" interface.
Also, a number of frameworks try to build "one" object heirarchy. This means they think an Action is-a Model is-a Database Handler. I personally have problems with this mis-applied abstraction, so this is a heads-up to not be afraid to spurn this idea if it doesn't work for you, either. As #Tyndall said, there's no one, single "right" way to do it.