** 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.
Related
What I'm looking for is a way to remove the model from a set of PHP files that make up a website. It's difficult (for me) to explain.
By models I mean models in an MVC sense.
As an example say I have this website:
index.php
about.php
shop.php
checkout.php
All of the above PHP files use the same database. I have separated the views by adding templates using a view.php file that renders the correct template with values passed to it.
I am not looking to use a framework that's already out there. I'm looking at writing my own in some senses, with only the bits I need to use in it.
If anyone would like to explain why this is not necessary, or a better way of doing things, then I'm open to that too.
Thanks in advance.
Writing you own MVC framework will take time, but you will learn a lot in the process. So, if you have the time/resources to do it I definitely encourage you to do so.
In this context here are some small pieces of advise that may help you:
Create your domain model first. I'm assuming that you are going in the OO way, so think about your domain problem and create the abstractions that best represent your problem. Try to keep it decoupled from cross-cutting concerns, like persistence.
Test a lot, test often. Try to test (and run your tests) as you create your domain model. This will be specially valuable when in 6 months you add a new feature and want to make sure that you haven't break anything. If you can separate your domain model from anything external (like the persistence layer or third party web services) the testing it is going to be a lot simpler. Today PHPUnit is pretty much the de-facto standard for unit testing in PHP.
You don't have to write everything from scratch. There are a lot of libraries that can help you to ease the development of an MVC framework, so that you can concentrate on what you really want to develop. For example, you could use Slim to handle the page routing or you could delegate the persistence stuff to Doctrine 2.
It is always nice to analyze how other frameworks solve things. You may want to look at products like Symfony or Kohana or even check how Elgg handles its views system. Also, if you want to check out something radically different you can take a look at Seaside's architecture.
Coming back to your original question, for me the key is to keep things from different layers as decoupled as possible. While I have only used the version 1, Doctrine 2 seems like a good candidate for persistence, since it allows you to create a domain model that is quite independent from the DB. This is a huge step. The second thing is how handle the view system. This is quite developer-taste dependent. For example, I like to model everything with objects, so I like Seaside's approach. On the other hand, Elgg's way of handling views is quite nice and maybe fits better with the way things are handled in PHP. Here is when you may benefit on doing some research before deciding on a route to go.
HTH
As someone who has written his own PHP framework, and with the same sensibility as yours, I can tell you that using a framework is a fine thing to do. That said, start by writing your own - you'll gain greater appreciation for the true structure and utility of a framework.
You'll want to learn about the Singleton object pattern. It is a major differentiator in the kinds of objects you can develop in your framework.
When you have written a few models that your files/controllers (presuming MVC) include, you will begin to see where to abstract a 'base mode' from which others extend (hint: the DB singleton).
When you start pulling in configs and the like, then you'll have your first framework object from which all other bases do their extension.
I have almost completed a PHP project, using MVC, jQuery and Ajax. It is pure PHP project. I don't use any frameworks in the code right know. I would like to change that.
Doing some research, I found, that Yii turns out to be one of the best frameworks out there.
Is it possible to somehow migrate pure PHP project to Yii?
If so, then how to do this? Which steps should I follow in order to reduce the workload and enjoy the benefits the Yii framework presents?
I'm a total Yii newbie, any insights appreciated.
TL;DR : Don't do it. It's a really horrible idea.
The Rant ..
"Framework" is not a magic sauce, that you add to a project, to make it better and shinier.
Doing some research i found Yii turns out to be one of the best frameworks out there.
What a strange research you have done .. I would love to see the materials. Especially, since I would rank it as 3rd worst PHP framework. Only surpassed in it's awfulness by CodeIgniter and CakePHP.
And the reason for it is the extremely bad quality of code, that this framework displays, combined with the bad practices, that it perpetuates.
Why avoid migration?
From your description is obvious, that you are NOT familiar with this framework and have no previous experience with it.
In management of projects there a subject: risk management. And in this case, adding a previously unused framework in final stages of project would constitute a high probability an high impact risk which also, due to the sage of project, is completely unmitigated.
It means that there is a really good chance that something will go wrong. And when it does, it most likely will sink the project. Or at least push back the release data by significant length of time.
In a perfect world frameworks are used to simplify the repetitive tasks of development, at the cost of some performance. Those are the tasks you do at the start of the project. You are not at the start of a project. This means that you will gain no benefits from this "maneuver".
Why not Yii?
As I noted before, there are also reasons not only for avoiding adding framework to an existing project, but also reasons why to avoid Yii in particular.
The inheritance nightmare
All your controller will extend class CController, which extends CBaseController, which extends CComponent
All your "models" will extend ether CActiveRecord or CFormModel, which extends CModel, which extends CComponent.
Both of there chains contain static variables and execute static methods on multitude of different other classes. Combination of these factors will make debugging extremely difficult and tedious.
Global state
There are several forms of global state. One that people in PHP usually know are global variables. But that is not the only form. Every time you have a class that contains a static variable, it also creates a global state, that can (and almost always - will) cause seemingly unrelated instance mysteriously interact.
Use of global state is a core mechanic. You will see static calls all over the codebase, and the Yii's configuration file would not function without global state.
And every time you call Yii::app() you are accessing and/or changing it.
This makes unittesting impossible for Yii applications. And debugging turns into exercise of using grep on your whole project.
Tight coupling
When you create an application in Yii. It becomes bound to it. You cannot execute parts of your application without launching the full framework. Mostly it is due to the static call, that you end up adding to your code.
Every time you add a static call in your own code, that piece of code becomes tied to the name of the class. That essentially is tight coupling.
As you might have noticed (hopefully), there is another way how to achieve the same effect - the use of new operator. That is another way of coupling some code of yours to a specific name of a class.
No interfaces .. none .. whatsoever
No matter how horrible the configuration of a Yii project is, the configuration file was a well intended gesture. The least harmful way to introduce external code and replace existing components in so messed up codebase.
But unfortunately it brings in the focus the problems caused by lack of interfaces and the existing coupling.
One of the component that developers will try to replace is the CUrlManager. Mostly due to way how you can pass additional parameters.
An interface in OOP specifies the contract between two instances. It lets you define the capabilities of an instance, the methods that can be used by others. When it's not there, in a large codebase, you are left guessing, which methods are required and which are not.
In case of Yii components the problem is compounded even further due to static call and deep inheritance. The above mentioned CUrlManager extends CApplicationComponent, which extends CComponent. Also the same file defines CUrlRule and CBaseUrlRule classes.
When you are writing a replacement, you have to write some code, plug it in the configuration and then test it by running your applications. That way you know which method (or parameter) next you need to add.
Basically, it's the "save-an-see-what-blows-up" method of development.
That's not MVC!
Yii does not implement MVC or any of MVC-inspired design patterns. What it calls "MVC" could be described as ActiveRecord-Template-Logic pattern.
Instead of having proper model layer (yes, it should be a layer), the creator(s) of Yii opted for collection of active record and form wrappers. This forces the application logic to be forced in the "controllers".
On the other hand you have glorified templates, instead of proper view instances for containing presentation logic. It is somewhat mitigated by use of widgets, but those instead suffer from SRP violations, because widgets are forced to contain bits of presentation logic and perform partial rendering. The rest of presentation logic ends up again in the controllers.
And to make it all worse, the "controllers" also have to deal with authorization. This usually will mean, that whenever you change the access scheme, you will have to go through every single instance of CController to check whether it needs to be changed too.
It's not MVC. It's a mess with names taken from MVC design pattern and slapped on some components.
All the small things ..
The framework also comes with few minor issue, that do not deserve a separate section:
Defining more then one class per file:
This will get annoying quite fast, because there will be classes that are shoehorned at the class files with completely unrelated filenames. This will mean, that debugging will quite often require use of search.
Slapped on "modules":
By the looks of it, the modules where added to the framework after the fact. Which is why, when you need to set default module, you will have to set it in the configuration files parameter, that is called 'defaultController'.
I actually recently converted a MVC pattern website I had built from the ground up into Yii. It did take some time to set it all up but in all honesty it was well worth it. I was able to throw away a lot of code because there were already Yii extensions doing what I needed. I would also suggest that you keep your database because you can create the controllers and Models using Gii which will save you a ton of time.
I don't know of any quick solutions to this. It depends upon how the code was written. You have the database and your views so it is not really a complete new project when you take into yii. Yii will generate the database models for you. You already have the views from the existing project. Write the controller and actions and modify the views if necessary.
try these links as they refer to the same problem.
How do you convert an old oop project into Yii
tips on migrating an existing site to Yii
Drupal to Yii Migration
Since you already have a code in mvc, things will be much easier for you to migrate. However, while migrating to Yii, since it can generate controller and model very easily using gii, you can take the advantage of it.
So, first generate controller and model using gii, then you can replace your existing code (by replace I mean, substitute your code to the specific function in the controller and model) to the built in controller and model so that the functionality of your site still works. You can modify your view accordingly. But that won't be much of a work.
You can simply register your script for ajax, jquery and css. Those will work as well.
And yes, Yii is the best framework out there so take as much benefit as you can.
Thanks,
Ujjwal
In this project you converted php to yii framework. Its really easy for you if you do following step.
Since you already have a code in mvc, things will be much easier for you to migrate. However, while migrating to Yii, since it can generate controller and model very easily using gii, you can take the advantage of it.
second, If your database is accurate then 50% work complete.when you create CRUD operation using gii then automatically model-view-controller create.if you create mvc in php then it benifit for you.
third,You can simply include your script for ajax, jquery and css. Those will work as well you create a folder in themes(CSS,JS,AZAX,BOOTSTRAP).
four-Protected->view->layout, where you can change your theme..thats all
you also help www.yiiframework.com/doc-2.0/guide-intro-yii.html
if you think my answer is help you then rating me...thank you.
I have some (basic perhaps) knowledge of the Model-View-Controller pattern and I want to create a site using this. But I find it a bit confusing how to actually implement this. I get stuck in the details.
Say that I have a site where each user keeps some todo lists. How would you approach this?
What classes would you create? Which class would output the HTML, which class would server as the controller and how would it communicate with the view to produce the output? etc.
Sorry if it seems silly and I guess it must be somewhat easy but I am stuck.
For the record:
It is not as hard to do a MVC in PHP, its more related with to be disciplined rather to be a difficulty task.
a) Model(s) (optional, you can use an array in PHP)
<?php
class MyModel() {
}
?>
b) Route (index.php?)
<?php
include "...";
// here we collects all the information, such post,get and path values
$action=...;
$param=....;
switch($controller) {
case "my": // www.myweb.com/my/action
include "controller\MyController.php"; // open the right controller.
break;
}
?>
c) Controller
<?php
include "model\MyModel.php";
switch($action) {
case "add":
// here live the logic, information, call for services and such.
$model=....;
// and finally...
include "view\MyView.php";
break;
}
?>
d) View
<html>
<body>
<?=$model->field;?>
</body>
<html>
As a note:
a) The view should be clean as possible. Think that the view could be created by a web designer that doesn't care about php.
b) The view is always the last step of the process. The view web always returns nothing.
It is very possible to do this without an existing framework, and just create your own. Its not a very difficult task anyway.
Not being application-specific, your MVC framework would have to do the following:
Redirect all trafic to a central page, so that every request gets
handled correctly.
Extract the controller and action from the request url. (for example, a request to http://yoursite.com/Task/Add, you have to translate that to the Add method on the TaskController)
Load the controller class (in our example TaskController). Perhaps using Autoload.
Call the Add method on the Controller
Show the result
There are multiple ways to implement views, you could emulate ASPMVC and have each Controller's action return an ActionResult, which has one method Execute. Then an overload of that, ViewResult would take care of loading the correct view and including it with the proper ModelData.
Here's the precise answer to your question from RASMUS LERDORF himself.
Read through.
Read the following intro to Symphony network:
http://symfony.com/doc/current/book/from_flat_php_to_symfony2.html
Although your question is a little too broad, I think I can provide some help.
The number one question I had when starting out with frameworks was: Which framework, if any, should I use? In your case, I would not try to build a MVC website without a premade framework. Most of the architecture you will end up writing has already been done dozens of times over.
Things like DB abstraction, login systems, etc. are boring to write. Might as well use a framework that already has these things.
I would highly suggest this book: http://www.amazon.com/Building-Applications-Symfony-CakePHP-Framework/dp/0470887346/ref=sr_1_2?ie=UTF8&qid=1315227178&sr=8-2. It will walk you through building a simple MVC website using three different PHP MVC frameworks. By the end of the book, you will have enough experience with each framework so that you can choose which one you like best.
Alternatively, if you'd like to write your own framework so that you can learn how it's done, I'd recommend TJHeuvel's answer. Another option is to read the source code of an existing framework so you can see how others have implemented it.
The comment by Kheldar makes perfect sense. The tutorial actually covers making a micro framework using the MVC pattern.
Although you'd need to add to it - in terms of adding custom routes and some sort of routing engine but apart from that it is a very good baby step into developing your own MVC framework..
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.