For a PHP MVC application, what is the difference of the job of the index.php file and front-controller? Is the front-controller in the index.php, or is it in a separate file? How do I separate the two and let them work together? Is the front-controller supposed to be a class (or like its own entity)? (If that's the case, then index.php will instantiate the front-controller?)
I know that they have to "set up the environment," which includes defining some constants and etc, but what does what? (-- autoloader, debug stuff, etc.)
I have seen this: MVC with a front controller confusion, but that doesn't solve the problem of the difference between index.php and the front-controller.
Actually, index.php should not contain any meaningful code at all, since it would be only part of your site, that is located inside DOCUMENT_ROOT of webserver. It's content should actually look something like:
<?php
require '../application/bootstrap.php';
It should only include a file outside DOCUMENT_ROOT. And that's all.
This way, if something goes horribly wrong (like, php extension fails after server update) and visitors are exposed to raw php code, it will not reveal any sensitive details.
The point of Front Controller is handle all user input, turn it into a consumable form and, based on it, dispatch a command (usually in a form of method call on an object). In languages like Java, where everything must be contained in a class, a front controller would be a class. But in php you do not have this restriction.
Instead the front controller will end up being part of your bootstrap stage of the application:
// --- snip ---
// the autoloader has been initialized already a bit earlier
$router = new Router;
$router->loadConfig($configuration);
$request = new Request;
$request->setUri($GET['url']);
// could also be $_SERVER['PATH_INFO'] or other
// depends on how url rewrite is set up
$router->route($request);
// the request instance is populated with data from first matching route
$class = $request->getParameter('resource');
$command = $request->getMethod() . $request->getParameter('action');
if (class_exists($class)) {
$instance = new $class;
$instance->{$command}($request);
// you dispatch to the proper class's method
}
// --- snip ---
// then there will be some other code, unrelated to front controller
Also, you should keep in mind that concept of front controller is neither made-for nor demanded-by application that attempt to implement MVC or MVC-inspired architecture.
Index.php should initialize the application and call something that deciphers the route into controller and action, and runs them. Look at Yii, Symfony, CodeIgniter, CakePHP, see what they do. All slightly different but same principle.
An example from Yii's index.php to make the point:
<?php
$yii=dirname(__FILE__).'/../../framework/yii.php';
$config=dirname(__FILE__).'/protected/config/main.php';
require_once($yii);
Yii::createWebApplication($config)->run();
$config gets passed to the web application, which serves as the front controller.
You really should read up on the structure of MVC, specifically when used with PHP. Initialize an instance of front-controller in index.php, and it should render your page if that process is part of the front-controller initialization procedure (__constructor()).
Related
I started not long ago with building my own mvc structure in PHP.
I have seen many people include in home.php page the header.php and footer.
I am currently stuck in finding a solid way to render my views.
I would like to know if it is even possible the way I am combining the header.php, home.php, and footer.php because this is not working for me which made me curious if there is even a native clean way of working with PHP layout structures?
any info would be appreciated. I try my best to explain the code below.
now working with this MVC structure. the router currently checks the req url and gives the controller
example of very basic router:
2 parameters: first the route, second the controller witch should render the view.
public function get($route, $controller) {
if($_SERVER['REQUEST_METHOD'] !== 'GET') {
return false;
}
$uri = $_SERVER['REQUEST_URI'];
if($uri === $route) {
$this->handled = true;
return include (controllers . $controller);
}
}
the routes that are being called:
$router = new Router();
$router->get('/', 'home.contr.php');
$router->get('/home', 'home.contr.php');
$router->get('/about', 'about.contr.php');
$router->get('/portfolio', 'projects.contr.php');
the router calls the controller and in my controller I render the view. with CreateView function
Home.contr.php:
class Home extends Controller {
public function __construct() {
Home::CreateView('home');
}
}
$home = new Home();
the extend controller that should implement the views/layout:
class Controller {
public static function CreateView($viewName) {
require_once views . 'components/header.php';
require_once views . "$viewName.php";
require_once views . "components/footer.php";
}
}
thank you in advance.
Limitations
MVC is a very broad topic with much different understanding so that by the term alone this is hard to answer properly - even in context of a PHP application. You normally refer to an existing implementation of MVC which is not the case here as you want to do it your own (Hint: Read code of existing implementations that is available and about you want to learn more).
Discussion
With that being said, you can find some practical "first next steps" suggestions at the end of the answer.
But I read your question as well that you're concerned about the HTML templates and perhaps also what this has to do with how you wrote your example. So I start a non-binding discussion about the View and then go over to Route and Controller. The Model layer I've kept out of the discussion mainly, at least for that you have to face third-party libraries as otherwise your application structure would not be a good host for broad functionality, this is touched by autoloading.
I have no authority in MVC, I just used some of the early implementations in PHP and applications influenced by them but never implemented it fully. So don't read out any suggestion from the discussion regarding it, it is merely about your example and what came to my mind in specific to PHP. At the end of the day it is you who will find the answer to your own programming questions.
Let's go.
A suggestion/assumption first: You certainly don't want to implement the view creation with the Controller class but with a View class. It would not change much just that the controller does not "care" about it (MVC = Model View Controller).
You can refactor (change) your code by introducing a View class and move the Controller::createView() to View::create() (compare: extract/move method).
Then using require_once - while it may work - it would only work if the template file is only used once. This is certainly not what you want to express here (and later in the discussion we'll see that with the existing example this can also more easily happen than perhaps intentionally thought), instead use require (or include depending on how you want to handle errors) as they will always execute the code in the file (for potential problems redefining controllers, see later in the discussion first routing and then second autoloading).
Apart from obvious code errors (typos) you'd need to address to get it to run (which is a good opportunity to explore PHP error handling and monitoring for your application) you still need to pass the output data of the controller to the view.
This can be so called view models or just objects (in the broader sense) holding the data to be viewed (rendered by the view). Just require/include-ing the (HTML layout) template files won't suffice as they may contain the HTML structure but not the controllers' output data. On the level of the templates this is typically in variables, e.g. the title of the hypertext document:
<title>
<?= htmlspecialchars($title, ENT_QUOTES | ENT_HTML5) ?>
</title>
If this would be the body of a function, the function definition would be:
function outputHeader(string $title): void {
# ...
}
As we don't have a function by requiring the template files, this is just exemplary. However we could create a generic function that handles requiring a template file and passing the variables to the template (compare include_helper()). In that layer you can also do some ground level error handling (try {} catch (Throwable $throwable) {} etc.). For starters you could collect and group such code in the View class.
What you also likely want to prevent is to bind the view within the controllers' constructor method (Controller::__construct(), ctor in short). It forces you to have a named view - and always the same - makes the controller dependent on that view.
That would mean you couldn't configure any view to any controller. While it wouldn't make sense in most cases to allow an any-to-any relationship here in the concrete practice, it allows you to actually have layer boundaries and to not couple things too tightly (compare: Spaghetti Code 1) and to write code on a higher level (in grade of abstraction, compare Layer of Indirection).
An example in a HTTP application would be to do content negotiation. This would happen on the level of request processing (more in the Router in your example), e.g. a HTTP client requests JSON instead of HTML. Now the HTML templates wouldn't fit here. But the Controller could still do the work if not the view template would be hard-encoded.
To keep things more flexible (so you can use it to a greater extend), one benefit of the MVC model is to use (and to a certain degree somehow pass the result of) the Model by the Controller to the View. It helps you define clear boundaries between those three and keep them more apart from each other (less coupled).
The routing then could negotiate and decide what to bring together, similar as in your example for the Controller already but extended with the View (template), each route could be assigned a layout/template.
As this would work quite the same as with the controller - just for the view - let's see where the current Controller not only is standing in the way for the view but already for the routing (if you find a flaw or bug, look around, often they are not in a single place and alone).
While you already configure the routes in the router, the actual routing you've put in the Controller base-class (Controller::get($route, $controller)). Similar to the __construct() method, this makes the Controller implementation dependent on the Route and even implements the routing. This is pretty convoluted and will certainly become awkward. There is also the problem when you add more routes you loose control which one matches as the matching is done within each Controller etc. . In short, while the code may be functional, it just seems to me it can benefit to be at a different place. As it's about the routing, first place that comes into my mind would be the Router itself. The Router then could do the actual work, "do the routing":
$router = new Router(); # <-- bootstrap
$router->get('/', 'home.contr.php'); # <-- prepare
$router->get('/home', 'home.contr.php'); # <-- prepare
$router->get('/about', 'about.contr.php'); # <-- prepare
$router->get('/portfolio', 'projects.contr.php'); # <-- prepare
$router->route(); # <-- do the work here
The Routers get() method then could stay the same from the outside but you would just store the routes inside and when you invoke the route() method, that configuration is matched against your request implementation.
You could then extend the router configuration with the view name.
It would be then that you still have bound a route to a controller and a view, however you have a central location where this is done (configured/parameterized). Controller and View are more independent to each other and you can concentrate more with their own implementation than the overall wiring which now moved into the router.
Finally while being here, what your example also shows is its dependence on the file-system, you have a certain file-naming convention for the controllers and also the view templates. While it is implicitly necessary to place the code into files, at least in your example on the level of the controllers you can already rely on PHP autoloading. While you want to write everything yourself (e.g. not using a ready-made MVC library), I'd still suggest to make use of some standards, like Autoloader (PSR-4) and as being inherently lazy, make the app a Composer project (it has a composer.json file) as Composer allows you to configure the autoloader and there is a well-defined process developing with it (you can also bring in more easily third-party libraries which you'll certainly need within your application logic, so this is just forward-thinking in a good sense, just start without any requirements just using the Composer autoloader).
So instead of hard-linking controller PHP file-paths, you could say instead that a controller basically is a class definition with at least a single method that the router is able to call. With the autoloader in action, the routing configuration would only need to reference that class/method and PHP then would take care to load the class. This could be done as strings (lazy-loading) or more explicit with the First class callable syntax (PHP 8.1). A good middle-ground for starters perhaps is to have one Controller per class and require to have it an interface so that you have a contract (compare: programming against interfaces 1, 2, 3, 4, 5, 6, 7 etc.). You can then simply pass the class-name and handle the instantiation in the route() method.
$router->get(
/* route */ '/',
/* $controller */ MyApp\MVC\Crontroller\Home::class,
/* $viewName */ 'home'
);
<?php
namespace MyApp\MVC\Controller;
class Home implements Interface {
# ...
}
<?php
namespace MyApp\MVC\Controller;
interface Interface {
public function invoke(InputParameter $params): InvocationResult
}
The route() then could check for the interface to verify some class can be used as a controller (instanceof) and would know how to invoke() the controller by passing the input parameters to receive the result that can be further delegated to the template layer.
This is made possible by also introducing the InputParameter and InvocationResult implementations (classes/interfaces) that help to define the layer boundary of the Controller part.
You can then do something similar for the View layer however the output comes relatively late and you're perhaps not yet settled with it (and you may have different template "engines" depending on use-case) so I would leave it more thin and less engineered and try with the Controllers first and do the delegation in the routing until you learn more about your actual requirements (Session handling, Authentication, Content-Negotiation, Redirects etc.).
At the end of the day you have to make your own decisions here.
Next Steps Suggestions
Add at least one test-script that you can run from your development environment "with a single key-press / click" and simple OK/Fail result (e.g. a simple PHP script that you execute in the shell)
Think about how to improve the error handling so you learn about defects faster (e.g. introduce exception and
Fix the bugs first, your code should actually run first of all (it might not produce the intended results in full but it should at least run - your example does not)
Init Composer / add composer.json to your project
Then change the code to your liking which can benefit having it under test first (compare Unit Tests)
I want a shell script I've got to be able to access appController, is this possible, without copying that code into the AppShell ? If so any pointers ?
Thanks in advance
In general, shells shouldn't rely on code inside a controller, some pointers (as requested):
If the Shell has to perform data-related tasks, move the code to the Model. This is good practice in any case (look up 'Skinny Controllers, Fat Models' on Google)
Although not 'standard' supported, you can move the code to a 'Component' (see Components). Components are meant for re-usable portions of code used in Controllers.
If the above options really aren't an option, you will have to manually initialise the AppController. keep in mind that, because you're running from the command line, various things will not be present, e.g. There will be no 'request' and some environment variables (e.g. host name) may not return the expected value!
Manually initialising a Controller
Manually initialising the controller will be something like this;
App::uses('CakeRequest', 'Network');
App::uses('CakeResponse', 'Network');
App::uses('Controller', 'Controller');
App::uses('AppController', 'Controller');
// request/response may be optional, depends on your use
$controller = new AppController(new CakeRequest(), new CakeResponse());
$controller->constructClasses();
$controller->startupProcess();
I am having a controller IndexController.php in which action is something like this
class IndexController extends CustomControllerAction {
public function preDispatch() {
if (!$this->view->authenticated) {
$this->_redirect('/users/login');
}
}
public function indexemailAction() {
//somecode which calculates certain things
}
}
NOw,I need to call the action "indexmailAction" inside the IndexController.php with an independent php file
The php file is indextest.php
<?php
//Need to write some code to call indexmailAction in IndexController.php
?>
What should I write in this file ......
Thanks in advance
I know this is a few years old, and this may not be the intended use of the classes/functions, but I've found the following quite useful in isolated files that are called from the command line.
The problem this solves for me is that it eliminates spawning of Apache processes. The solution is great because I can access the some Controller/Action needed that I would from the URL.
In almost any ZF1 based app, you can copy your index file and keep everything the same and just comment out the following line.
$application->run();
Anything below this line you can access with your autoloaders etc. It's crude, but it works. Unfortunately, you'll soon find yourself with limited access to a lot of the files your application has, and the feeling the only way you can access the files needed is through a Controller/Action.
Instead, I use the following in a new file below $application->bootstrap() ( still removing the $application->run() ):
$front = Zend_Controller_Front::getInstance();
// You can put more here if you use non-default modules
$front->setControllerDirectory(array(
'default' => APPLICATION_PATH.'/controllers'
));
$viewRenderer = new Zend_Controller_Action_Helper_ViewRenderer();
$viewRenderer->setNeverRender(true);
Zend_Controller_Action_HelperBroker::addHelper($viewRenderer);
$req = new Zend_Controller_Request_Http("http://anydomain.tld/controller/action");
// Example just to see how this can be extended
$req->setParam("someVar", "someValue");
$front->setRequest($req);
$front->dispatch();
In the end you have a isolated PHP file that bootstraps everything the same as your main index.php for the web, but you can manually trigger a controller/action as needed, giving you easier access to the rest of the files with how ZF1 intended you to access them.
Controllers are designed to be used in an MVC, not by scripts. Your controller should assemble request variables, direct them to models and return an HTTP response of some sort. Your scripts should act directly on the models instead.
Anyhow, if you insist, you can instantiate a controller class and call methods just like any other class as long as you inject any dependencies that the MVC would have.
If you want logic used in multiple places in your actions, then it should go in an action helper or if very generic code, then in a custom library (/library/custom/)
NB: The authentication would be better suited in a plugin rather than the pre-dispatch method in every controller.
You should not have to call a controller action for this, your logic should reside in your models. Then you can create a new instance of your model and invoke the appropriate methods. example :
require_once '/path/to/mymodel.php';
$mymodel = new Mymodel();
$data = $mymodele->fetchAll();
PS: Maybe you should think of creating a restful api to handle calls from outside your application
UPDATE:
ok, I see now what you need, The best way to achieve it is to call a url instead of a file (e.g. website.com/emails/send), if you are worried about security you can use some preshared key to make sure the request comes from you, send it with the request and check if it's correct in your action.
This might be a bit hard to comprehend so I apologize in advance if this is not clear enough.
I'm writing my own MVC framework and am once again stuck.
I am in the process of writing the controller classes for the framework. Basically this is how it works:
Instantiate class coreController which extends abstract class
coreController sets controller to be loaded by interpreting query string
query string values stored in variables
other variables assigned values
new controller is loaded
new controller checks if an action object needs to be instantiated.
new actioncontroller is loaded
action controller checks if it is the final object required.
action controller is returned as an object to be referenced during the rest of the script.
generic $controller->method() can be called and references final controller loaded.
Another overview:
coreController
pageController
pageControllerActionAdd
return as object to start
$controller->something(); //References pageControllerActionAdd
Esentially what I want to be able to do is be able enter a url like:
http://www.mywebsite.com/page/modify/
and have the script pull up the PageModifyController as a variable so I can execute it's methods.
If you can tell me a better method for what I am doing please go ahead. You don't have to write any code, just the idea would be great. It is just that the way I am currently doing is very confusing and hard to debug. I will end up with multiple nested objects and I don't like the concept of that.
I've been reading a lot of other source code and found that it too can be quite sophisticated.
I actually created a framework that works along the lines you are trying to implement. I think what you are missing is a RoutingHandler class. Routing is the physical manipulation of the URL, which tells your application which Controller to load, and which Action to run.
In my world I also have Modules, so the basic routing scheme is
Module -> Controller -> Action
These three items map to my URI scheme in that fashion. Variables can be appended also like so...
http://www.domain.com/module/controller/action/var1/val1/var2/val2
So, what happens after the URI is parsed, and control is passed over to the appropriate controller and action? Let's make some code up to demonstrate a simple example...
<?php
class indexController extends Controller {
protected function Initialize() {
$this->objHomeModel = new HomeModel;
$this->objHeader = new Header();
$this->objFooter = new Footer();
$this->objHeader
->SetPageId('home');
}
public function indexAction() {
$this->objHeader->SetPageTitle('This is my page title.');
}
// other actions and/or helper methods...
}
?>
In the Initialize method, I'm setting some controller-wide stuff, and grabbing an instance of my Model to use later. The real meat is in the indexAction method. This is where you would set up stuff to use in your View. For example...
public function randomAction() {
$this->_CONTROL->Append($intSomeVar, 42);
}
_CONTROL is an array of values that I manipulate and pass onto the View. The Controller class knows how to find the right template for the View because it is named after the Action (and in a sibling directory).
The Controller parent class takes the name of the action method and parses it like so...
indexAction -> index.tpl.php
You can also do some other fun stuff here, for example...
Application::SetNoRender();
...would tell the Controller not to render inside a template, but just complete the method. This is useful for those situations where you don't actually want to output anything.
Lastly, all of the controllers, models, and views live inside their own Module directory like so...
my_module
controllers
indexController.class.php
someotherController.class.php
:
:
models
HomeModel.class.php
:
:
templates
index.tpl.php
someother.tpl.php
:
:
I can have as many Modules as I need, which means I can separate functionality out by Module and/or Controller.
I could go on, but I'm writing this from memory, and there are some wrinkles here and there, but hopefully this gives you food for thought.
How do I eliminate the need for the "Controller" suffix in the filename of a Zend Framework controller? It just gets tiresome to keep typing that suffix in when creating controllers, and meanwhile the file is already in a controllers folder so it's superfluous.
For instance, by default the homepage on a site goes to "controllers/IndexController.php". What if I want it to go to "controllers/Index.php"?
The latter portion of the class name is hardcoded to "Controller" in Zend_Controller_Dispatcher_Abstract::formatControllerName().
To change it, you'd have to create a custom Dispatcher class that implements Zend_Controller_Dispatcher_Interface and override the formatControllerName() function. Then assign an instance of your new Dispatcher to the front controller in your bootstrap script with $frontController->setDispatcher() before you call dispatch().
Why would you need to change the format of a controller class name anyway? It's not like that PHP file appears in a request URL anywhere.
Sounds like you're bikeshedding.