What It Is
Here is what I've done so far:
core/
controllers/ (contains the controllers used by the app)
models/ (contains the models used by the app)
views/ (contains the views used by the app)
base_controller.php (the controller every other extend)
base_model.php (the model every other extend)
vendors/
phprouter/ (a simple router class)
pimple/ (a simple DI container class)
configuration.php (contains all the app configuration)
index.php (includes the configuration, vendors, base model, base controller, sets the DI container up and route the request)
See the code here: http://pastebin.com/pxUpUvv6
Please note that the given code is just an example, therefore the controllers, models, views aren't in place yet. Also, it may be buggy—as untested—, but it doesn't matter right now.
Request Flow
The client requests index.php.
The configuration, vendors, base controller, base model are included.
The DI container and the dependencies are initialized, we can now inject them anywhere.
We map controllers to URL and the router does its job.
The controller is fetched (although this is not in the example code, as noted above).
We do some stuff.
The method then calls ::call_model(), which includes the corresponding model from core/models/, and then calls the same method we're using from the model class corresponding.
The model is fetched.
More stuff.
The model then calls ::call_view()', which includes the corresponding view from core/views/.
The view is fetched and render the page to the client.
FYI: Corresponding
Examples of controller, model, view which correspond:
Controller Controller_Products::list() at core/controllers/Controller_Products.php
Model Model_Products::list() as core/models/Model_Products.php
View at core/views/Model_Products_list.php
Issues Being Faced
Actually, I feel a bit uncomfortable with this structure. Dunno, it seems to be far from scalable, modulable...
Does only the basic folder structure—core{, /controllers, /models/, /views}, vendors at the root—looks good to you?
I feel like I should get __autoload() outside of index.php, which seems a little too big to me. If so, what about DI container?
Maybe if I get to needing more than two external library, it should be better not to have them included one by one, manually? But how?
Putting all the configuration in a file configuration.php at the root looks to me like old-fashioned PHP4. Thanks to the power of Pimple, I could embed this configuration directly into it but yet, where?
I think the way I handle ::call_model() (core/base_controller.php) and ::call_view() (core/base_model.php) is a bit awkward. Would you agree? What'd be a simplified way to redo the whole thing?
Considering all my issues, would it eventually be better for me to use a framework as Symfony?
If something isn't clear, feel free to ask.
Thanks.
Yes.
You can use autoload and DI container together. There is example, how autoload can be used with naming convention. I recommend to use spl_autoload.
With autoload you can remove all (or almost all) includes.
In index.php, I guess.
Yes, it's wrong way. First of all, try to not use static methods. Also, models should have methods with descriptive names, not just 'call me and I will do all what I can'. It's more complex problem - you need to understand how Controller and Model should do their cooperation. As variant, read some books. Controller should call methods of Model, to get data for some situation. Model it's not just place for code of controller. Different controllers can use different models. Models too can use another models.
Answer to this question can not be objective :)
Related
As the title says, I just want to ask if this is a bad thing or not if I inject all views, models, controllers and other classes like helpers into the container (IoC) for example like the following image.
Sample:
Note: In this case, I make my own base view, model and controller for my component so I don't use default Joomla instance like JModelLegacy::getInstance(); or JControllerLegacy::getInstance();.
Thanks.
This is what I did. I've tired of constant changes that breaks extensions and force to rewrite them without any actual benefit.
I have forced all MVC classes of Joomla and added my prefix to them. Everything works just fine.
I do not think you will have a problem to load everything at once. At least with the list you've shown. If you would have extension with hundreds of views and models, may be you could be hurt.
On the other hand why would you do that? Decouple your library off Joomla's and it will load everything automatically.
I have read a lot of SO topics about this already, but still haven't found (or have been able to create) a proper answer.
I am working on a small MVC framework and I want some global class/object that I can call from my controllers (but maybe models too).
There are a couple of routes I can take:
Global variable
Static class/Registry
Dependency injection
The internet seems to agree that the DI is the best route to take. I think I have grasped the idea, but am not comfortable yet. So I want to throw in some background information; I will probably be the only one working on the project, it is a small project, all my controllers extend the main Controller (so I could just load one library like class there).
As a concrete example, I want to have an array of categories. So I started out with putting that array in the CategoryController. But now I noticed I kinda want to use that array in my frontview and in ProductController as well. Obviously I don't want to load all of CategoryController into ProductController.
You could also say I could put that array in some kind of configuration or settings file, because of the simpleness of this example, but that's why it's an example. I will probably expand on it with more functionality.
So to summarize: In PHP (specifically inside a MVC model) how can you give your classes (mainly Controllers) access to some kind of common class or other sharable functionality.
Your controllers are created by "something" (usually a front controller). So when the controller is created, you could inject a dependency injection container.
And in your configuration/bootstrap (before the controller is created), you should add you categories to the container.
That way you can access the categories from every controller.
Please note that this is a simple example that doesn't totally fit the spirit of dependency injection. The best solution would be to inject directly the categories (instead of injecting the container). But that can become a lot of work if you generalize that pattern (lots of dependencies to handle in your front controller).
A solution would be to use a dependency injection framework that could do that for you.
For example I work on a DI container that lets you inject stuff with annotations (PHP-DI), but there are several other libraries for DI so you have a choice.
My 2 cents:
In a small self-made mini-framework I have done some time ago, I have created a global singleton class named Application, and anything/everything which should be accessible from anywhere/everywhere was a property or method of this class.
In my case, there was a $db property for database access, a $user property to access the user data and methods, an $input property for a "powered" $_REQUEST access, and so on.
Of course, you have many other options, suitable for different scenarios. This approach simply worked fine for me on that occasion.
Now, if you want to access a controller from another controller, this really sounds strange. This "thing" that you want to access should be a model class, a library class, or anything else, but it should not be "locked" inside a controller class. Indeed, the controller should be "as thin as possible", and focus on calling the appropriated methods from other classes, based on the user input (request) and then calling some output method to generate and send the answer (response).
Finally, although I've read some criticism and complaints about it (as well as praises too), I do make use of static methods a lot, mainly for classes which are more "helpers" than anything else.
I'm thinking of re-working my MVC before I get to far along with it. At the moment it uses a sinle controller which takes the user input and determines the model. The model has maby differ methods which I call actions, because one is called automatically. The model loads its view file, which again holds many different methods. The model can set properties which can be used in the view. Then the controller calls th template classwhich parses the output for display.
Is this the bst way to do it?
Or should each different part (news, contact, about) have its own controller, which loads a specific model and view. Essentially, instead of grouping methods into a single file, it uses multipe files.
I'm kind of lost as to how I should do it.
Cheers
Start using a MVC that works and is well-known like in Symfony or Cake. From that you will decide:
what do to in your own, knowing the best practices;
to drop your own if you feel like you can save time by using theses.
If you are thinking of advancing your own MVC model, like #e-satis have said, you will need to experience what is happening in already developed systems. However, as based on my experience in designing MVC model and determining what is there in opensource community, I stick back to my own MVC for two good reasons. One reason is the flexibility of customization and the other is own MVC privacy.
I used the following approach for MVC design pattern.
A Router.php file identifying user-request urls. This router will be able to fetch controllers and include the file and call the controller default method.
The loaded controller is also able to load other controllers if required to function. This is done using a global method, where all controller Class will extend to a MainController Class which is able to call to other controllers.
I do use a global registry to set and get variables from one controller to the other.
The Models are used to get the Data from Table, and most of my Models will represent Database functions which includes CRUD (Create Read Update Delete). So that a controller can easily manipulate database table data using a model.
Naming conventions in all controller, models, and views is also important, if you want to system to be more intelligent to identify the required action knowing the file name.
I use the Views separately for each type of controller. And these views will be sent to a Master Template View file.
Same as models, the controller will be able to set Views to Master View.
There are other customizations which you can do, like applying security methods before calling a class, or after calling a class/controller/model/view etc.
This is done by the MainController, which it will always look into a folder with autoload class which states what files should be loaded before and after of different actions during the process of building the content and delivering the output.
MVC is not a small scale idea, but it is a design idea which can always be developed. There are so many PHP MVC open source frameworks to be found if you know how to search the major search engines like google.com
But I do advice you that, MVC is not a good solution if you are simply developing a small dynamic website, as it will consume more time in developing compared to developing small websites. MVC is ideal, if you have business logic and needs system automation in order to avoid most routine tasks of developing, and like that I would say MVC is most ideal for larger applications.
The model loads its view file
The Controller should act as a Mediator between the Model and the View.
The Model shouldn't be aware of the way the view renders it, and also the View shouldn't be aware of any kind of logic of the Model.
In theory, if your MVC is well structured, you should be able to represent the same Model with different types of Views (HTML, XML, JSON for example).
Build FrontController which parses request uri and decides which controller to load and which method to run. With .htaccess rewrite all request to index.php
//index.php
class FrontController{
function run(){
//parse request uri here /comment/new
//load controller comment
//run controllers method new and pass some request attributes
}
}
// ../controllers/comment.php
class Controller_Comment extends Controller{
function new($request){
//do stuff here
}
}
is it usual to use controllers in models?
then you have to include the controller in the model?
Models should not be using controllers.
To clarify, using the MVC pattern, the user communicates with the controller which manipulates the model which dispatches its results to the view back to the user.
Image taken from The Model-View-Controller (MVC) Design Pattern for PHP
Update to Doug's response:
The most logical way to explain how the components work is by starting from the model, then going through the controller, and finally reaching the view. And "MCV" would not have been nearly as appealing a name to the ear as "MVC."
Taken from Chapter 1 of Beginning ASP.NET MVC 1.0 by Simone Chiaretta and Keyvan Nayyeri.
No it is not common. You should never have to use your controllers from your model.
If you feel the need to, it probably means code that is currently in your controller should live in a shared library, or actually be in the model to begin with.
It is of course proper to use a model from a controller.
Update
Code that doesn't directly relate to a specific database table/record (model), or doesn't directly respond to a user's action (controller), would be a good candidate for a utilities or library file.
This is more normal, and where you load it depends on if you are using a framework or not. If it just your custom app, you can just do a require_once in your model and use the utility methods from there.
straight to the point :
I am using Kohana, and I am looking at another script written in plain PHP. In the script, I have a class ShoppingCart. If I am to convert the script to Kohana, where am I to put the class, its methods and its properties?
Is it in my existing default controller? Or should I put it in a separate controller? Or as noobie as it may sound, will I put it in the model?
That depends on the specifics of the class I suppose. To be honest I don't know anything about Kohana, but there's probably a place for "vendor files" somewhere. Maybe it's best to place it there and write wrapper functions for it in your controller. If the class already integrates well with Kohana you may instead choose to use it as a controller or model directly. Or you might want to take the time to rewrite it to make it work as a controller...
Only you can evaluate the best place for it, there's no hard and fast rule here.
Kohana has a folder for 3rd party libraries. The main one is under system/vendor, you can put it in you application/ as well.
Many PHP class loaders require details like your filename should be the same as the class name (at least that's what I read in the Kohana documentation) if you want the classes to be automatically loaded.
If you need to use 3rd party code in your app it's recommended that you create a folder in your app / module folder called 'vendor' and place all of that code there.
You can then include the files by calling:
include kohana::find_file('vendor', 'filename');
If needs be you can also create a wrapper for the external library, a good example of this is the email helper which uses the 3rd party Swift email library.
If you're porting your own class to kohana then you need to work out what the class will be doing and categorise it accordingly.
If the class will be fetching items from some kind of database then you should make it a model. Libraries are usually sets of code that you want reuse across controllers / models, such as authentication, calendar generation etc. Controllers are used for passing data from models to your views / libraries.
See the docs for more info
As per kohana convention, you should place custom classes in application/libraries folder. However for this, you need to know how to get the class to work after putting it there. If you can't figure that out, you can do anything like putting it in your controller or making another controller of it, etc.