I beginner in PHP and I sill struggling to understand about controller, view and rout. I do so many thing to showing my code in view.
I write this to connect the function index in file ChargeController
Route::get('/', 'app\http\controllers\ChargeController#index');
So, how can I knowing that code was integration as MVC in PHP?
thank's
Laravel follows MVC design pattern (Model-View-Controller).
Model interacts with database (Laravel's ORM is Eloquent)
View is responsible for rendering.
Controller handles the user input (form inputs, data, validation etc.)
In the web, we have web sites and their urls. You visit a site and move inside a site with urls. Laravel has own Router which maps urls to a controller's action (in your case / maps to ChargeController's index method)
Your request goes into controller's method then you validate user's request if needed. After that you have validated user inputs (string, array, file etc.) with these inputs you may some database queries that handles by Laravel Models.
Controller give/get all information via Models. Then pass these information/data to view.
Laravel has Blade templating engine. It has directives to help you to use PHP inside HTML. Blade view names ends with blade.php (for your example it is resources/views/charge/index.blade.php) from there your controller returns view with givin data from laravel model to your controller.
In some cases, you don't use Laravel's Blade, and directly returns JSON response from your controller to be consumed by your frontend (VueJS, React, Flutter etc.)
So basically how it works is when you navigate to http or https://yourhost.com (with no path, the default path will be /), your application will try to check if the path / is registered. By defining the code on your question, it is registered and Laravel will run whatever method that linked to that path. In this case, it will run your index method on ChargeController class. Inside that index method, you may be needing some data, which you can access using Models class that Laravel provides. After getting those data, you also need to register which view to show with the data inside that index method. If you registered your view and design it correctly, the path / will show the view along with your provided data.
Inside MVC, all of the view's logic, animation, etc. is also coded inside the view file, which makes it different from other design patterns. For ex. there's a MVVM design pattern (Model-View-ViewModel), this pattern separates the view's logic and put it inside the ViewModel file. (see MVVM for more information)
Related
I am creating an MVC inspired PHP framework, mainly for learning purposes.
I basically have the framework created and am building an app on it and improving the framework as i go along.
I am still confused/not sure about certain aspects of this sort of architecture, and at the moment i am questioning my implementation of the View part.
How i have set up my framework:
Its a very simple set up, for example: you go to the url /post/post_id, this will load index.php which will instantiate the router. The router will then check the url and instantiate the correct controller and method based on the url. In this case it would be PostController, and the method would be a default method that would use the post_id to get the posts data from the relevant model. Next the controller would set up a "data" variable that will hold the data to pass on to the View, and this is where i am confused - should it send to its own View object (a view class file dedicated to the PostController), or to a generally used View class that is used by all controllers to load an html file?
At the moment my controller is sending data to the View class, this data includes what template file should be included/shown, and the actual data for the page (what we got from the Model through the controller).
My question is this:
Should this type of system have one View object that renders all of the views (html files) based on what data is given to the "render" method, or, should each controller that eventually sends data to the View have its own View object/class?
Meaning, should PostController send a request to the general view class, the same one that is used by all controllers to renders pages, or should the PostController send to a dedicated View Class (call it PostView if it makes it clearer), and this class will then render the specific html file?
Basically if it should be one View class for all controllers that will render what ever html file the controller tells it to, or if there should be many View classes, one for each page load.
NOTE:
I know a lot of questions have already been asked about MVC in PHP, but i could not find an answer to my question in any of the answers.
A bit about MVC:
In the original MVC pattern (presented by Trygve Reenskaug in 1979), the controller updates the model, the model notifies the view about the changes, and the view pulls its data from it. Though the pattern was thought for desktop applications - each M-V-C "triad" beeing related to a single control in a window (a button, a textbox, a checkbox, etc). So, each control on the screen had an MVC "attached" to it.
Since, in web applications, the model-to-view notification step is not (or can not be) present, the original pattern can not be applied as is to them.
But a most similar approach can still be relatively easily implemented: the controller updates the model, the view pulls data from it (irrespective of the controller). I think it's called "Web MVC Model 2".
There is a multitude of web MVC variations. You are using one in which the controller takes the role of an intermediary between the model and the view.
So the controller is the only one component communicating with the model.
The view's responsibility:
The responsibility of the view component is the presentation logic - which should not be assumed by the controller at all. Beside loading and rendering template files, this kind of logic involves the preparation of the data fetched from the model for displaying purposes. The result of the preparation should, preferably, be a list of values of primitive types (strings, booleans, integers, arrays, etc) which can be easily "injected" into the template files during the load-and-render process.
Examples of presentation logic:
Example #1: If you would fetch the value 123.45 (from the column amount of a table revenues) from the model, the presentation logic would consist of formatting it to the string 123.45 USD, in order to be displayed in a template file.
Example #2: Formatting a fetched date value of 28/05/2019 to 2019-05-28 by using a code snippet like this:
$fetchedDateFromModel = '28/05/2019';
$time = strtotime($fetchedDateFromModel);
$formattedDate = date('Y-m-d', $time);
The value of $formattedDate would then be "injected" into a template file.
Example #3: Setting a boolean value based on some model data, in order to be used in a template file for deciding if a button ("Get Bonus") should be active or not.
$paidAmount = 512.79; /* model data */
$isActiveGetBonusButton = false;
if ($paidAmount > 500) {
$isActiveGetBonusButton = true;
}
The answer (in respect of your chosen MVC approach):
By using a View instance in all controllers, you would be forced to perform specific presentation logic in each controller - before passing its result (e.g. the list of the prepared values) to the used View instance, in order to further just be "injected" in a specific template file.
Whereas, if you are implementing a dedicated view class (like PostView - which, preferably, inherit a base class View containing the render() method) for a controller class (like PostController) - so a 1:1 relationship, but see it as a loose one! - you can pass the data fetched from the model, in an unprepared form, from the controller to the view. The view class would then correctly take the responsibility of preparing the data for displaying prior to actually load and render a specific template file. E.g. of performing the whole specific presentation logic.
Note: In "Web MVC Model 2" - where, ideally, the controller has no knowledge of the view component - the above argument is more obvious:
the PostController just updates the model (when an update step is required);
the PostView fetches data from model, prepares it for display, and displays it (by loading & rendering a template file like posts.html.twig, for example). In other words, the view component performs the whole presentation logic by itself.
The best way, IMO, is to have this View or Template class do all the work related to views with just one simple method: render(string $templateName, array $context = []).
This allows for easy extension or creation of adapters. You should make your controllers use this method. If you use a DI Container in your framework, you could do a TemplatingAwareInterface and implement that with a trait that allows setter injection. That will inject the templating service on fetching from the service container. That way, you can use $this->templating->render() in your controller, without having to either make it global, nor constructing the templating service inside the controller, nor injecting the container into the controller.
Having one view class for each type of controller is cumbersome, harder to maintain and I don't really see a reason for it.
I'm doing registration and login form using cakephp. I'm new to cakephp framework. I have downloaded and installed cakephp on my system. And I've already connected into my database table. I've made few changes in core.php and database.php.
I'm following these tutorials to do registration and login form.
http://alvinalexander.com/php/cakephp-user-registration-form-example-recipe
http://www.grasphub.com/2013/01/simplest-registration-form-in-cakephp/
http://karven.wordpress.com/2009/07/30/create-simple-user-authentication-using-cakephp-auth-component/
I've tried everthing. But none of them does not works. I don't know where i need to create these php files. I'm new to MVC design pattern too... Here anyone give me some step by step procedure to finish this simple task.. I'm not ask any coding here.. I want some step by step procedure..
It may look a bit hard, but when you understand its scheme it becomes super simple:
The model layer handles everything about data. It will silently connect to the database configuration declared in the variable "useDbConfig" in the model (if not declared, it will connect to default config). They are stored in the Models folder. "Handles everything about data" means that it fetches the data from a datasource, validates data that will be saved, formats data, etc.
Models can attach a behavior. Think of it as an "interface" in OOP terms (not the same, but somewhat close). They provide common functionality between them (for example, TranslateBehavior makes data for that model translatable). They are stored in the Models/Behavior folder. You can call them in the array variable $actsAs, or load it on the fly. For example:
public $actsAs = array('Translate');
The controller layer handles all actions that will be done with the data. It will silently instance the model with the same name as the controller to handle the data, but you can tell a controller to instance many different models to suit your needs. They are stored in the Controllers folder. Usually functions in controllers are called actions, because when a HTTP request is handled in your server, it will be delegated to the corresponding function in your controller. Say, http://www.example.com/users/login will call your action login() inside UsersController.
Controllers can attach a component. It's the same as a behavior, but specifically for controllers. They are stored in Controllers/Components folder. For example, PaginationComponent makes the data fetched in a controller paginable, so you can sort it, divide it by pages, etc. You can call it in the variable $components, or load it on the fly. For example:
public $components = array('Paginate');
The view layer handles all your presentation. It means that they have all the HTML + Javascript that the user will see. It's called from a controller after an action is resolved. It silently will render the view inside View/ControllerName/action.ctp, It means that, for example, when login() action has finished, it will then render the view View/Users/login.ctp. Views usually use the layout default to render, but you can change it in the variable $layout inside the controller. You can pass variables from controllers to view through the function $set() in the controller.
Views can use helpers; they are the same as components and behaviors, but for the views. But you have to declare them in the controller in the variable $helpers. They are stored in the Views/Helpers folder. For example, the default HtmlHelper lets you make some tags easier, like <img>, <a>, <script> or <link> for css.
Also views can use elements. They are kind of blocks that you can reuse in any view or layout you want. You just create an element in Views/Elements folder, and use them with $this->element('nameOfTheElement');.
In summary, you for the login you will need an User.php model, an UsersController.php controller, and a login.ctp view. In the controller you will need the AuthComponent to load, because it will handle the login. In the view you probably will need the HtmlHelper and FormHelper, but they are loaded by default. And in the login() function in the controller, you just check if Auth->login() succeeds or not, and take the proper actions.
Once you're more experienced, you can look at the convention called fat models, skinny controllers to be more organized.
Good luck!
I'm new to Zend Frameworks and MVC type programming (not PHP though) and I'm trying to provide API access to data on my server using the Zend Framework.
I'm using Chris Danielson's article (http://www.chrisdanielson.com/2009/09/02/creating-a-php-rest-api-using-the-zend-framework/) as a base.
I want to provide access to data in the following formats:
(a) http://www.example.com/api/createevent
Data will be POSTed here, success will return an id, otherwise an
error message/code
(b) http://www.example.com/api/geteventdetails/1234
GET request will return data
(c) http://www.example.com/api/getregistrationdetails/1234
GET request will return data
(d) http://www.example.com/api/getregistrationdetails/1234/567
GET request will return data
Questions:
There is a default file which is located at \api\application\controllers\VersionController.php which enables handling of URLs of type: http://www.example.com/api/version . Should I be creating a separate file located at: \api\application\controllers\GeteventdetailsController.php which handles requests of type (b) (and one for every type of request)? If not, where should I be placing my code to handle these multiple request types?
How can I get the parameters passed in (b) to (d)?
To do requests (b) to (d), I need to fetch information from my server's database. Where should I place the code that does the actual MySQL query?
I have used routes a lot in ZF, but not the Rest implementation, having swatted up on the docs and on the tutorial you linked to - I will do my best to help you...
It might be worth looking at the docs for the Rest router (about 1/3 down the page) - it explains that it will automatically create routes for you based on the method of the request; so your naming format of createevent, geteventdetails, etc shouldn't be needed.
Question 1.
Rather than creating the file
\api\application\controllers\GeteventdetailsController.php
I'd create the file
\api\application\controllers\EventsController.php
This will be one controller to handle all the event actions, be that getting, posting, putting, etc. Your suggestion is too specific for the controller as the get, put, etc will be handled at the action level.
Question 2.
The routes described in the docs show you that the final parameter (:id) will be assigned to a parameter in the controller called id.
So accessing the URL /events/ using GET will invoke the indexAction() in your EventsController.php file
And accessing the URL /events/99/ using GET will invoke the getAction() in your EventsController.php file. You can access this id from the controller like this
$id = $this->getRequest()->getParam("id");
OR
$id = $this->getRequest()->id;
You should then write code to query the database for a listing of events or for a specific id. Which brings us nicely on to...
Question 3.
Rather than putting the code for querying the database for events into the controller you should create models for your database tables and rows. I'd recommend using the existing setup in ZF for Zend_Db_Row and Zend_Tb_Table to do this. This will ensure your application/website is MVC.
Putting the code inside the contrller may hinder development later, for example when you write a registation form for an event at a later date in another controller. The logic for creating the event will be duplicated, once in the new controller and once in the Rest controller. You'd be better off centralising this logic into a model for manipulating and querying events.
I hope that helps!
I've been using the CodeIgniter framework for PHP and am enjoying it, but I notice that it seems to require a controller for every view. I'm wondering if there is a way to call a specific model from the view itself, rather than route through a controller. I understand that use of a controller is best practice in most cases, especially where the data from the model needs to be modified in some way, but I have cases where I just need to do a strict data pull to the view (which is loaded via ajax), and setting up a controller for that seems superfluous.
Any thoughts? Thanks in advance!
You're fundamentally misunderstanding MVC, at least as implemented in CI.
All URLs on your site (at least those that utilize the CI framework) are mapped to functions (methods) within controllers.
http://myCIsite.com/controller/method[/var1][/var2]...
It doesn't matter whether the URL is accessed via regular HTTP or via AJAX. This is always a one to one mapping. Because of this, you should think of the controller/method combination as the "web page". Do not think of the view as the web page.
Models and views are subordinate to controllers. The controller delegates specific responsibilities to them - database interaction for models, and page output to views.
Because models and views only serve to perform delegated responsibilities, their use is not required in any given controller/method. Help pages, for example, generally have no need to interact with a database, so there is no model utilized by the controller/method combination that serves a given help page. Likewise, form handlers frequently redirect to another page upon completion of processing. As such, there is no view corresponding to the form handler (but there is (likely) a view called from the controller/method in the redirected to page).
Furthermore, models and views do not necessarily correspond on a one to one basis with individual controllers/methods. Any given model can be loaded and used from within several controllers. Similarly, a controller could have a single monolithic view that is used by all methods, or each method could be assigned its own view. (Or, as I just said, a given controller/method could utilize no view at all.)
Finally, CI does not enforce strict MVC separation. You can interact with the database and echo HTML all from within the controller and CI will not complain. Nevertheless, this separation and delegation of responsibility is followed because logically separating the responsibilities makes the code easier to read and helps you follow the DRY principle in your coding.
The fundamental Understanding is that the "web page" corresponds to the controller/method. The view and model, when used, handle delegated responsibilities for the controller/method.
I'm wondering if there is a way to
call a specific model from the view
itself, rather than route through a
controller.
That's not possible as of what I know, the main abstract class of the CI controller imposes restriction to use a controller otherwise you will get a fatal error.
And actually what you say will break the best practice of MVC design pattern. You got to go to model through a controller not view.
I'm a bit confused as to exactly what you're trying to achieve. The controller's value, aside from just being a clean way to handle incoming requests, is to manage the interaction between the models and the views and to determine which views to load. It's also entirely reasonable to load model data directly from your views, but how did you get to your view in the first place?
I guess I'm just having a hard time seeing the context here..
To run a query via Ajax you still need to provide a URL / path in the javascript call. You can not get around the fact that a controller function has to "catch" this call; you can not map a url directly to a model. All you need is 3-4 lines of code in your controller.
Via URI routing you can map a URL to a different controller, so you don't "require a controller for every view". I always create a controller called "ajax" to handle those requests.
A basic ajax call with jquery can be something like this
$('#prod_img').load( "http://domain.com/ajax/get_img", {'color': 'blue', 'url_title': 'bla' } )
You can echo stuff in your controller, so rather than trying to bypass the controller you should be looking into how to do away with the views. This will actually be easy, you can load the db class in the controller just as you can in a model.
But if you really don't want to use MVC perhaps Codeigniter is not the framework for you.
You should read more into the principles of MVC.
Views are strictly for presentation of data, the model shouldn't communicate with views directly.
But still if that's what you want then just pass $this->db from the controller to the view and use it in the view.
Then again, this is NOT a good practice.
I am working on a CMS using CakePHP and I want to create a dynamic menu which is the same on all the pages the user can access. So I figured out to create in the layout (since it shared among so many pages and view) but I don't seem to know how to acces the model and get the data from the database to construct the menu. any help is appreciated.
That's because for proper MVC separation* in Cake you're not supposed to access the Model from the View. The only part with access to data should be the Controller (via the Model), which hands it down to the View, which simply displays the data.
As such, using a beforeFilter callback in your global AppController to set() the data is probably the best choice.
In emergencies you can always access anything from anywhere by loading an instance of the needed Class using ClassRegistry::init, but you really shouldn't.
* Actually, in "proper MVC" there's no problem with the View getting data directly from the model. You shouldn't do that in templates necessarily, but View related code can well get data from the model to visualise the model state. It just doesn't really work that way in Cake, because Cake is not proper MVC and default Cake views are only templates.
An alternative could be requestAction, it allows you to call controller actions from views/layouts, and in those actions you can then access the desired model(s).