I'm learning the OO and MVC paradigm (using Codeigniter and PHP). I continue to find warnings such as this: If you find yourself pasting the same code into multiple files, then you aren't using OO/MVC properly. So, here's a question for more experienced programmers.
I have a create-user form that I am using two very similar versions of:
Version 1 (at /volunteer/register) is created by an anonymous user. The form lives in the volunteers controller, and needs to be verified by an admin.
Version 2 (at /admin/create_volunteer) is created by a logged-in admin. The form and validation is nearly the same, but it is submitted with different parameters.
Another, similar example:
I want to build different user dashboards that share a template, but will be used by different user roles and have different functions and information based on role. As I see it my choices are:
Create a Dashboard controller with three functions defining the data loaded into the dashboard template.
Add the a dashboard function to each role's controller (Volunteer, Admin etc).
Create a controller for each case (Volunteer, Admin, etc.)
I apologize if this appears sophomoric but essentially I'm looking for rules-of-thumb to determine how to design architecture in MVC.
My questions:
In the first example, is my logical choice of controllers (Volunteer & Admin) less than ideal? Is code replication in this case an acceptable practice?
Can anyone recommend architecting tools to establish logical consistency and good workflow for MVC?
Especially since the two forms are not the same (different rules, different interface) there's absolutely nothing wrong having two separate view files if you need it. Loading the same view file in two different controllers or methods is perfectly acceptable, indeed it's appropriate. If there are only a few tweaks that need to be made, try to reuse the view file by passing different data to it.
If you want to simply load the form view file in different instances, that would save you some code duplication. Just set different rules and if needed, pass different data to the view. It's similar to using the same form to create and edit something in two different methods. If the output is going to be totally different, just write separate view files. If it's the same output but with different data - definitely reuse it.
Don't get obsessed with trying to not duplicate view fragment code - if you are writing even more code to force the reuse of a view file by modifying it for different instances, it kind of defeats the purpose. Try to just make it a general practice to make your code as reusable as possible.
So, without seeing your actual code - I'd say don't worry about it. In my experience, view files for front-end and back-end are almost always unique (completely different UI). In general, if you find you are duplicating the same very similar code a lot, it's time to write a function, class, or template for it.
It seems you would like to use some ACL for distinction between roles (Volunteer and Admin) that will check whether requested module or action can be accessed.
Creating different controllers for the roles doesn't seem to be a good choice since this architecture could not be reused - you don't want to reuse specific Admin or Volunteer functions in other applications but rather a module that lets you create and control such roles.
You would like to reuse a code offering particular functionality, this might be one controller, one model and some view files.
Most programmers consider duplicated code as a sign that the solution to a problem still can be improved.
If the problem in your case is that the from is defined in one controller but you need to use it in another controller as well, then you need a better place to define the form so that both controllers have access to it independently from each other.
Make the form configurable so it's possible to reuse it.
Related
Overview: I am building a CMS using PHP, and I am trying to implement this using MVC. I am trying to extend my code using this structure, as it represents an accurate representation of MVC and it is quite straightforward. To communicate with my database I use Domain Objects and Data Mappers.
Questions:
Is it really necessary to have a 1:1:1 mapping between a model, a view, and a controller?
Example: For a blog system, when displaying a blog entry page I would create a controller called DisplayEntryController, and a View called DisplayEntryView. The view would get its information from the BlogMapper class (which communicates with the DB to retrieve the current blog entry) and a CommentMapper class (which communicates with the DB to retrieve the comments for the current blog entry). Is this good practice, considering that view works with 2 model objects? If not what is the alternative? If yes, how can this be implemented in a generic way?
Can multiple controllers handle one page? For the example above, would it be possible to have a DisplayEntryController and a CommentController handling the relevant parts of a page displaying the blog entry? If yes, how would the 2 controllers coordinate?
Thank you in advance. Examples will be greatly appreciated.
Most PHP MVC implementations I've seen on the web use the page approach to organise their MVC. E.g. for the Home page, you have one view, one controller and one model. Routing for 1:1:1 mapping in MVC is straightforward, as you can enforce the location and naming of your MVC components, and when a request for the Home page comes it automatically looks for the following classes: HomeView HomeController and HomeModel.
This obviously doesn't work well in larger projects. How should routing be handled to support routing to multiple models (DataMappers), multiple views, without creating an overcomplicated router or adding a complex dependency injection layer?
Example: As discussed above, when displaying a blog entry you display
the blog entry code and the comment section. To achieve this, it
communicates with two DataMappers, the one which gets the blog entry,
and the one which returns the comments for the blog. How can the view
be assigned to work with these two datamappers to get the data from
the DB?
There is no requirement to have a 1:1 mapping of the model, controller and view.
MVC works of a concept of a tiered approach to handling your application, with each tier being handled by 'agents' to implement the way they see fit. To explain this further, consider the following scenario.
Assume you process data, then hand them over to someone to store. You don't care where they store it and how they store the data, as long as the information is available again when you need it. You can happily go about processing your data, and then say to them for example 'This is project data for Client X, store it,' and later say 'Can you give me the project data for Client X.'
SO MVC works on this approach, whether the data storage guys dump all data together or pack them away is not important to you. However, what is important is the interface between the two parties when sending and retrieving. For example, you could decide to store the information as either Client data, or Project Data, or both.
Likewise, you could have agents collecting data and handling it to you to process. You don't care how many interfaces they use (for example, phone, web, email, mobile devices), but you care about what data they hand you. (Of course a rule might dictate that only web information must be handled). So the interfaces for collecting data might be different.
Therefore, each agent can use the most efficient method (and even combine or split them) to get the system working in their side, and therefore there is no mapping of the data.
I will be working on project that has different theme for each domain (same application will be serving multiple domains).
I need to change location of templates completely outside the application folder, possible on another volume
I need to make it work with multiple domains with multiple themes - i guess theres cache problem
S how to do this stuff with Symfony2 and twig?
EDIT: I will try to ask this: What or where do I need to rewrite to get custom logic on locating specific templates that symfony uses to render pages.
I can't say if first point of your question is a bad practice (and don't know even if it possible, but I would say yes).
However, what I would do is some kind of "manager" that will takes responsibility for choosing what kind of template render, based onto your own logic. Some kind of "intermediate level" between actions and views.
You could create it as a service and use everywhere, without have need to instantiate it every time.
It could read a file for configuration or, even (but less springy), use a class-internal configuration.
Algorithm could be something like this:
Take into account your request
"Eat" data and "spit out" the correct template (name)
Pass template (name) to your view
Extend (dinamically) the template given by your manager
Please, don't ask me some code because it could result in some hundred lines :)
I'm fairly new to Codeigniter as well as MVC and I'm having a bit of trouble figuring out the best way to accomplish this.
I need to build an app that allows users to apply to various programs offered by some institutions. However, these institutions must all have a spot in the app yet they want their independence from one another—not sharing one application page for all programs. For instance Institution 1 wants a section of the site to only view and apply to their programs and Institution 2 wants a section of the site to only apply to their programs.
What is the best way to accomplish this? Should I create a separate controller for each institution?
E.g. sitename.com/inst1/apply, sitename.com/inst2/apply
Each of these controllers would essentially be identical with the same create/read/update/etc functions though. What are best practices in this situation? Thank you!
You can create folders to serve your functionality properly. This is widely used for APIs.
For example. You can have your folder structure like this.
- application/
- controllers/
- inst1/
apply.php
- inst2/
apply.php
With this, you'll have the URL endpoints like.
index.php/inst1/apply
index.php/inst2/apply
I think you have it right, you'd create controllers for each institution allowing you to change what data you were pulling for each. The views could be shared since all the functionality would be in the controller/model which is one of the more important aspects of MVC to begin with, the ability to separate those layers and reuse what you need where you need without duplication. If you set up your pages as a template you could even pull different templates to feed the views to that would be institution specific.
For this you probably want to use the same controller and instead handle the variation through passing your function a different uri segment which you can read about here
. In my codeigniter applications i like to keep a specific functionality within each controller or model. So it might look something like:
sitename.com/my_controller/my_function/my_argument
Where the function in your controller looks like:
public function my_function($argument){
//stuff goes here
}
You can of course use your routes file to make the url look however you'd like.
Just build a single controller, and make a flag to differ them. In the view file you may check for this flag to decide weather to show programs and apply or not.
Your url would be like that:
sitename.com/inst/1/apply, sitename.com/inst/2/apply
note: you may also change the numbers in the url with words; to better seo.
I am a beginner with CodeIgniter still struggling to get a complete grasp on how to use the MVC ideology most cleanly.
I am writing a basic CMS system with the ability to vote on entries and follow people etc, consequently, I have found myself using the same or similar pieces of code across multiple views here and there consisting of various pieces of html and logic such as:
Voting panel
Follow/Unfollow panel
Login/Logout panel
Code to check if a user is logged in etc...
I am wondering where to put this code so it can be unified? I am thinking a helper is the way to go? If I declare the helper in the controller, it can be called from the corresponding view right?
Some of the elements are dynamic - such as a follow/unfollow button - It would need to check if you are already following the user or not and display the appropriate button, which would require a model to check. What I have now is that all the logic is in the controller and it returns an appropriate button, but it seems weird to be returning formed html code in a controller return as well. Should it be more like:
controller checks if you are following someone
the controller passes a boolean to the view
the view calls the helper with this value to draw the appropriate button
Also, as a secondary question, I have been doing a fair bit of looping through mysql arrays in foreach loops to process mysql results returned from the view. It seems like my views are getting somewhat complicated, but I can't think of another way to do it, although perhaps this should be done in another helper as well?
Apologies if this is a naive or repetitive question, there is indeed a lot of discussion surrounding this subject but it is not always easily relatable to another project.
Helpers are certainly one way to modularize anything that isn't DRY. Another is to use Partial Views. CodeIgniter looks like it supports partial views. Here's a good breakdown - not PHP specific but the discussion should be agnostic.
As far as handling user logins is concerned, you will probably want to use a static class and the singleton design pattern, which will allow you to check to see if a particular user is logged in or not anywhere in your application. There is a good tutorial here
http://www.phpandstuff.com/articles/codeigniter-doctrine-scratch-day-4-user-login
Loading the helper, I don't believe loading it in your controller will automatically load it in your view. I think you have to re load the helper in your view file, or you have to autoload the helper. (cant remember off top of head but Im pretty sure).
Regarding looping through the mysql results, you should be using a model for this, always. Any functions which are grabbing or sorting information from your applicaiton, should be done within the model. Then, in your view file you loop through the results and format the data how you choose to.
When developing http://newspapair.com which has the vote functionality you mentioned I used helpers and custom classes to spread the functionality across multiple views.
Helper - has functions without a class. So a standalone function or group of functions can be placed in a file and saved as a helper.
For instance I used a helper with generic form processing functions for NewsPapair, instead of a static class. But this is not the "best practices" thing to do. I did it this way because I already had the functions from a previous project.
As far a looping through MySQL results, try to write a query that allows the DB Server to do the heavy lifting. This will make your code more efficient. Perhaps ask a question about a specific query with example code. Plus do all of the data gathering in your Model.
1) Where does the homepage of your website fit into "controllers"? I've seen some people use a "page" controller to handle static pages like, about, home, contact, etc., but to me this doesn't seem like a good idea. Would creating a distinct controller just for your homepage be a better option? After all, it may need to access multiple models and doesn't really flow well with the whole, one controller per model theory that some people use.
2) If you need a dashboard for multiple types of users, would that be one dashboard controller that would have toggle code dependent upon which user, or would you have say a dashboard action within each controller per user? For example, admin/dashboard, account/dashboard, etc.
3) It seems to me that using the whole simple CRUD example works like a charm when trying to explain controllers, but that once you get past those simple functions, it breaks down and can cause your controllers to get unwieldy. Why do some people choose to create a login controller, when others make a login function in a user controller? One reason I think is that a lot of us come from a page approach background and it's hard to think of controllers as "objects" or "nouns" because pages don't always work that way. Case in point why on earth would you want to create a "pages" controller that would handle pages that really have nothing to do with each other just to have a "container" to fit actions into. Just doesn't seem right to me.
4) Should controllers have more to do with a use case than an "object" that actions can be performed on? For all intensive purposes, you could create a user controller that does every action in your whole app. Or you could create a controller per "area of concern" as some like to say. Or you could create one controller per view if you wanted. There is so much leeway that it makes it tough to figure out a consistent method to use.
Controllers shouldn't be this confusing probably, but for some reason they baffle the hell out of me. Any helpful comments would be greatly appreciated.
1) I use a simple homebrew set of classes for some of my MVC stuff, and it relates controller names to action and view names (it's a Front Controller style, similar to Zend). For a generic web site, let's assume it has a home page, privacy policy, contact page and an about page. I don't really want to make separate controllers for all these things, so I'll stick them inside my IndexController, with function names like actionIndex(), actionPrivacy(), actionContact(), and actionAbout().
To go along with that, inside my Views directory I have a directory of templates associated with each action. By default, any action automatically looks for an associated template, although you can specify one if you wish. So actionPrivacy() would look for a template file at index/privacy.php, actionContact() would look for index/contact.php, etc.
Of course, this relates to the URLs as well. So a url hit to http://www.example.com/index/about would run actionAbout(), which would load the About page template. Since the about page is completely static content, my actionAbout() does absolutely nothing, other than provide a public action for the Front Controller to see and run.
So to answer the core of your question, I do put multiple "pages" into a single controller, and it works fine for my purposes. One model per controller is a theory I don't think I'd try to follow when working with Web MVC, as it seems to fit an application with state much better.
2) For this, I would have multiple controllers. Following the same methods I use above, I would have /admin/dashboard and /account/dashboard as you suggest, although there's no reason they couldn't use the same (or portions of the same) templates.
I suppose if I had a gazillion different kinds of users, I'd make things more generic and only use one controller, and have a mod_rewrite rule to handle the loading. It would probably depend on how functionally complex the dashboard is, and what the account set up is like.
3) I find CRUD functionality difficult to implement directly into any layer of MVC and still have it be clean, flexible and efficient. I like to abstract CRUD functionality out into a service layer that any object may call upon, and have a base object class from which I can extend any objects needing CRUD.
I would suggest utilizing some of the PHP ORM frameworks out there for CRUD. They can do away with a lot of the hassle of getting a nice implementation.
In terms of login controller versus user controller, I suppose it depends on your application domain. With my style of programming, I would tend to think of "logging in" as a simple operation within the domain of a User model, and thusly have a single operation for it inside a user controller. To be more precise, I would have the UserController instantiate a user model and call a login routine on the model. I can't tell you that this is the proper way, because I couldn't say for sure what the proper way is supposed to be. It's a matter of context.
4) You're right about the leeway. You could easily create a controller that handled everything your app/site wanted to do. However, I think you'd agree that this would become a maintenance nightmare. I still get the jibbly-jibblies thinking about my last job at a market research company, where the internal PHP app was done by an overseas team with what I can only assume was little-to-no training. We're talking 10,000 line scripts that handled the whole site. It was impossible to maintain.
So, I'd suggest you break your app/site down into business domain areas, and create controllers based on that. Figure out the core concepts of your app and go from there.
Example
Let's say I had a web site about manatees, because obviously manatees rock. I'd want some normal site pages (about, contact, etc.), user account management, a forum, a picture gallery, and maybe a research document material area (with the latest science about manatees). Pretty simple, and a lot of it would be static, but you can start to see the breakdown.
IndexController - handles about page, privacy policy, generic static content.
UserController - handles account creation, logging in/out, preferences
PictureController - display pictures, handle uploads
ForumController - probably not much, I'd try to integrate an external forum, which would mean I wouldn't need much functionality here.
LibraryController - show lists of recent news and research
HugAManateeController - virtual manatee hugging in real-time over HTTP
That probably gives you at least a basic separation. If you find a controller becoming extremely large, it's probably time to break down the business domain into separate controllers.
It will be different for every project, so a little planning goes a long way towards what kind of architectural structure you'll have.
Web MVC can get very subjective, as it is quite different from a MVC model where your application has state. I try to keep major functionality out of Controllers when dealing with web apps. I like them to instantiate a few objects or models, run a couple of methods based on the action being taken, and collect some View data to pass off to the View once it's done. The simpler the better, and I put the core business logic into the models, which are supposed to be representative of the state of the application.
Hope that helps.