I have a pretty large site, and I am looking for the most time efficient way to manage it (I am the sole coder).
I am trying to devise a very simple MVC structure (i don't want to use a framework) to help keep all my code in order.
For a huge site, is it better to have only one controller to handle all the pages, or is it better and easier to split them up?
If just one, what is a good example of a non-framework controller?
I would split any logical divisions into different controllers - if it's all static pages, then serve it up with all the same 'static page' controller.
If you have some static pages, a FAQ page (or section), a product list - use a controller for each different section. So the static pages would be pulled from flat files or a database by one controller, the FAQ pages would be generated from a FAQ table by another controller, the products and info would be generated by whatever the source for that is.
Every time the way a page is generated or the data is accessed, use a different controller.
Of course, class inheritance can be used to create the base class with the code needed by any controller.
Not sure what you mean by a non-framework controller - I'd checkout the Zend (gasp) 'Framework', the MVC pattern, and even the controller itself, can be used apart from the rest of the framework.
I tend to split the controllers up based on their responsibility to a specific section of a site/application. This makes maintaining the code so much easier. Furthermore, I group controllers (and views, models) within modules (folders). Here's an example from a current project I'm working on:
Blog
Posts
Comments
Categories
Settings
Posts
Users
The more complex a site, the more modules I use. Although most of my modules only contain one 'Index' controller, I do like the organization they provide.
Then I use a router (front controller) that maps a REST style URI to the proper module / controller / action. Ex: mysite.com/blog/posts/view/7 would call Controller_Posts::view(7) from the "blog" module. An added benefit of using modules is I can have more specific URIs than if I didn't have modules. Although I suppose that could be remedied by using a router that supports defining custom routes, but I'm not too fond of that.
As many other things, it boils down to what you're comfortable with as a developer, but we can probably agree that more organization you have, the better off you are, so long as you don't over complicate things.
As a quick aside, I would recommend you look into using a framework. I understand if you don't want to use one of the ones out there already, as I avoided those too. I ended up writing my own which for the past year has served me very well. It was a great learning experience and it only contains what I want / need. That being said, you might want to look into Kohana and CakePHP - they're not overly bloated IMO and they will definitely save you time should you decide not to write your own.
Typically people split up controllers into controllers focused on specific areas of functionality.
Then they stick a "front-controller" in front of it all, so there's only one entry point to the application. The front-controller's only job is to route incoming requests to the appropriate controller.
Look at the way the Zend_Controller component is set up. It may provide everything you need, and you're free to use it without buying into the complete Zend Framework.
It depends how you other parts will work. If you only have one model file then it's probably not worth splitting up the controller. If you can split up the model into sections as well as the controller, then do that.
However, I often find that there's too much overlap between models to separate them. You might have a model for articles, but if you want to display the top 20 articles in a sidebar on other pages, that code should be in the article model - and you're going to need that on every page.
Honestly though, the only way to do it is try it and see. Start with a single entry point, and if it gets too, unwieldy, refactor it into smaller chunks.
One router/dispatcher, many controllers would be my advice. Controllers ought to map to URLs, which means differing functionality. A controller will collaborate with different services to accomplish each use case, so one controller for your entire app would become too unwieldy if your app has more than a handful of use cases.
Related
I'm building a simple Virtual Learning Environment(VLE) system for a test project with CakePHP. The project contains the following:
Courses
Lessons
Questions
Answers
I've made the Controller, Models and Views for the courses and Lessons and I'm able to add lessons to a course and delete them. I've generally been following cakePHPs blog tutorial and changing as I go along.
This however leaves me with a very rigid structure of content and pages and URL's (I understand how to change the URL's to be more user and SEO friendly with Routes). My pages are all /{controler}/{method}
Part of the project is to create a management panel for the courses. On the page you can see lessons, and the students assigned to the course with links to add/edit these.
I can not however work out how to do this combination of several models into an admin style page. I can think of a few ways of dong this involving perhaps cakePHP pages, or routes and bringing one models data into another's controller to get it into the view. However I am trying to find out the correct way of doing this with cakePHP or failing that in MVC frameworks in general.
I apologise if this is laid out anywhere obvious but I've looked and have yet of find any answer that coveres my issue is a laid out fashion. Unfortunately I really need this spelling out for me as I'm just overwhelmed with a lot of MVC without anyone to ask and haivng only worked in CMS systems.
Just create a Controller called "DashboardsController" or something like that.
Within it's actions, you can load any model(s) you want, then use it just as you would in the respective Controller:
$this->loadModel('Course');
$courses = $this->Course->find('all');
$this->set(compact('courses'));
This is a very common problem/solution, and I believe I even asked this same question a few years ago on here myself (though I couldn't find it). You still retain the MVC structure, as it still acts as the Controller - it just accesses methods from varying models.
It's incredibly common to call more than just the model of the controller you're in, so in a case like this, you just load whichever models you want/need.
You can make a Dashboard.php model as well and just set
$useTable = false;
to tell it you don't need a "dashboards" table.
I have one of these "generic" controllers in almost every project I do, and am not really sure of any other/better way to handle it. This seems the cleanest, easiest, and most logical approach IMO.
I am thinking to create my own simple MVC framework in PHP. I thought it would be good idea to improve my skill in PHP.
I have a questions about admin section, how do you create it?
In kohana, controllers can be in sub-folders:
for example: /controller/admin/admin.php
What is other way? As long code can be shared to parent helpers/libs or parent models.
First thing you have to notice is that Kohana is a HMVC framework. It is a bit different beast, compared to the rest of bunch. In this case admin is not so much a module as it is a namespace (though kohana is still using the PEAR-like "namespacing") for controllers and other classes.
This way additionally lets separate out other parts of application .. lets say you have a lot of code dealing with tagging and tag clouds. Then you can create another namespace/module just for that. And use them as sub-controllers. That's one of HMVC perks.
One other way of separating admin section from general application would be to treat them as separate applications, but then you need another location for shared components (most likely from model layer). Then you have more then one /appliation/ folder on your server.
Or you can do combination of two.
I am assuming here that the reason you want to create yet another MVC framework is indeed to improve your PHP skills, and not to try to create a framework to use in a daily basis at your company, for example. I know that you didn't ask for such advice, but there are so many great MVC frameworks out there (and you probably know many of them already). I think it is a great approach to learn design patterns and increment your skills in PHP (or any other language), though.
As of your question, the most common approaches I have seen is to use different directories, like the "admin" subdirectory you mentioned, for then enforce name suffixes or prefixes for the controllers, like "UsersAdminController.php" e.g, adding "AdminController" at the end.
One thing that using a subdirectory may be better is that it enforces a better separation of concerns, and reduces the possibility of you ending with a lot of classes with simmilar in the same directory, which may cause confusion at some point.
I think creating your own framework is a great idea, if only as an exercise to better understand the structure behind a web app.
I'm doing it so myself, and I think your approach depends very much on how far you want to go.
I started with a multilanguage support subsystem and user database management classes and now I'm moving to content management and database query sanitization.
I keep my classes separated in files and grouped by subsystems in folders, like multilang or admin, I think it's the best approach.
Well, I have been thinking a lot about the first real CodeIgniter site I am coding. I want to modularize the site in such a way that I have a controller that formats the navbar, one that formats a multipurpose right column, and one that formats the content area.
My idea is to have a controller for each state of any part of the site (an example would be the right column, it would have 3 states; new posts, related posts, and search filters). I would also have the content area be many different states aswell (things like search results, view post, new posts, etc).
The problem is that I can't find a way to take multiple controller outputs and compile it into a single template (notice, I said controllers, not views).
I have seen the HMVC extension, but that is going to far for my first site, and am hoping for a more simplistic solution (unless you can prove me wrong, and show that HMVC is easier than what I've seen).
This seems a little wonky to me in an MVC model.
If you're using a single stateful view for your right panel that might change state based on input (i.e. which page the user is currently on), then I would add a model for the panel. The controller's action would be responsible for setting the correct model state (i.e. "you're in home page state"). The model could be responsible for telling the right panel view which child views to load.
That's how I'd probably implement something like that anyway. HMVC seems overkill and with this example, wouldn't be used as intended.
For what you're trying to accomplish the matchbox module suggested in the comments seems way overkill. I don't think that using controllers to format each of these areas is a very good approach to take.
Usually people who want the type of functionality that you're describing when working with CodeIgniter end up using a template library. There are several open source template libraries for CodeIgniter that can easily be found with a google search for "codeigniter template library".
I've never used any of them so I will not recommend any particular library. However the app that I'm working on has borrowed some ideas from Phil Sturgeon's template library. You may not find an exact match to features that you need but at least you'll be able to draw some inspiration from solutions that others have come up with.
This might be an obvious thing to you but - even after reading through a lot of manuals and blogs - I'm still not sure what exactly should a bundle in Symfony2 represent in a webpage. And it's hard to guess it from the simple demo applications.
For example: I have a site which is divided into two parts (one is just a 2nd level domain like example.com and another is dom2.example.com). Each of these two parts has some sections of it's own - sometimes the same (like news) sometimes different.
What would the correct representation of this in symfony2? Should I have
a MySite\site1 and MySite\site2 bundle and do the different sections via different controllers, or
bundles Site1\News and Site2\News, or
bundles MySite\Site1News and MySite\Site2News etc.
...or am I getting all wrong at this?
I am also new to Symfony and will follow the results of this question with interest, but for what it's worth, my take on it is:
A bundle is just that: a group of files, assets, PHP classes and methods, tests, etc. The logic of the grouping can be anything you like. In some cases, it's really obvious what the grouping is and why it's been done -- for instance, if I wrote a blog system for Symfony2 and wanted to release it, I'd make it into a bundle. That's the sort of example used most in the documentation.
But you'd also use bundles for anything you wanted to release as one little feature. Say for instance, this bundle which creates default routes for all your controllers. It's not a fully developed plugin/feature like a blog or forum, but it's a bit of code that I can easily import into my project, it stays totally separate from everything else, it's a bundle.
Finally, you'd also use bundles internally to your project, in absolutely any way which makes sense to you.
My take on your specific situation:
Quick and easy:
MySite\MyCode -- gets the job done, and maybe you don't have any logical way to break up the code you're going to write.
If there's some more unique features between the two sites and you want to separate them out for clarity:
MySite\SharedFeatures
MySite\Site1Features
MySite\Site2Features
If you really like everything in its place, or if you have a complex project, maybe:
MySite\MySiteMain (shared features and catch-all miscellany that doesn't deserve its own bundle)
MySite\News
MySite\Site1FeatureSomethingOrOther
MySite\Site2FeatureSomethingOrOther
I definitely think you want to stick to logical groups of code -- so I think your example "bundles Site1\News and Site2\News" and "MySite\Site1News and MySite\Site2News" wouldn't be the best way to go. Site1 and Site2 are implementations, so making a separate bundle for each site's news page would seem to be counterproductive to me; you'd want to make one news component and build it to be used in two different ways.
As for your two-domains question, you can either point both domains at the same code, and test within your code for what domain is being requested, or you can check out two copies of the same code and change the configuration files slightly (this doesn't necessarily violate the idea of DRY because you'd still edit the code in one place, then update both copies.)
The way I understand a bundle is that it is similar to what CMS like e.g. Typo3 or Drupal call a "plugin". So it should be ideally self-contained and written in a way that it can be used on other projects too.
E.g. in your case I'd create a "staticHtmlBundle" that contains all the static pages of your website, divided within by site.com and dom2.site.com.
Then I would create a "newsBundle" that contains all the news-articles, maybe even database-driven with a little admin-section where you can edit them and assign them to different channels (in your case that is site.com, dom2.site.com). A static page from within staticHtmlBundle would call newsBundle and display its data (like e.g. a listView of the news or a detailView and so on).
If you keep everything as abstract and reusable as possible then you could even publish the newsBunde in the Symfony 2 Bundle repository and share it with the community!
The way I perceive Symfony2 bundles is that they are provide a modular system which allows you to not only extend and override the php code, but also any resources they may or may not include.
Having said that, consider you have an API and you would like to transfer an object.
How would you do that?
Of course, you can do that manually, but wouldn't it be nice if Symfony can do it for you?
My way of doing this would include 3 bundles, JMSSerializerBundle and FosRestBundle.
One bundle for the client side - MyCompany/ClientBundle
One bundle for the server side - MyCompany/ServerBundle
One bundle housing all the data transfer objects I would like to be able to transfer - MyCompany/CommonBundle.
Inside my MyCompany/CommonBundle I would have the classes I would use for my data transfer objects along with the serialization rules I would have to provide the JMSSerializerBundle with. They may be in the form of xml, yml or php annotations.
Once you have an object filled up with the data, you can just use return and FosRestBundle would serialize it for you. Serialization would depend on the routing, so you can have the object serialized in XML for one system and in JSON for another. Key point is you have different serialization formats and versioning you can utilise at later point.
On the client side, you can use simple param converter to convert the received JSON or XML to an object right in the controller with no additional hassle. You can also type in some validation rules, so you can verify if the object is populated as you expect it to be.
In my example, the MyCompany/CommonBundle has objects that would be used by multiple applications and would be identical. Having that as a separate bundle helps you avoid code duplication and makes long term maintenance a lot easier.
I hope I managed to explain this. Any questions?
Ask in the comments. Will update the answer accordingly.
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.