I'm building a site using CodeIgniter that largely consists of static content (although there will be a relatively small CMS backend, and there's code to handle localization/internationalization based on the domain used to access it). Typically, in a situation like this, I'd use a Pages controller that is in charge of rendering static content, but as there are a fair number of pages on the site (30+) it'd quickly end up containing lots of methods (assuming one per page).
Should I break my Pages controller into multiple controllers (that perhaps inherit from it) according to different sections of the site? Should I organize methods differently in the Pages controller? What's the best practice here?
Thanks!
Justin
I'd say split your controller into multiple. Not only it becomes easier to find whatever you need to work on in the file, probably there is a relation between the methods that "belong" to the same section. The end result is a more organized project,
Alternatively, why not have one single method that serves a static page, and work out which page to serve based on url ($id)? You'd have to play with CI routes a bit, in order to still have "site.com/pages/static_page_x" instead of "site.com/pages/view/static_page_x", but if you have a consistent way of accessing your static pages, it would save some typing, give you a way of adding new pages without touching the controller code, and might also come in handy if you want to apply to all the static pages something that you didn't think you'd need before.
Why dont you try to use a helper to detect your URL with the base_url() method and then process it. set a session variable to define the language in the controller...
Related
What we usually see in framework documentations are simple blog-like applications where each page is related to only one model and one controller.
How to deal with the most common case where a single page have to display information from different models?
Example:
A social network home page that shows:
Recent user posts
Recent users
News from the admins
Most played games
Is this supposed to be handled by a single controller that loads all this information from the different models and send it to a view that is potentially broken down into partials / elements?
Someone said in another question that I could create something like a HomePageController for pages like this. What if all that information should be displayed in the sidebar for all pages on the site, how do I handle that?
Typically, you'll collect all the different kinds of data and pass it to the view together:
MVC frameworks generally provide some way to map request URLs (e.g. /offers?id=5) to controllers (or their methods).
Let's assume that you want to display some data on your homepage.
To do this, you'll first define mapping from URL /home to some particular controller, let's say HomePageController.
Using your example data, you'll have something like this in your controller (in method that will handle request):
model.add(dao.getRecentUserPosts());
model.add(dao.getRecentUsers());
model.add(dao.getNewsFromAdmins());
model.add(dao.getMostPlayedGames());
render("viewName", model);
Upon request to some adress mapped to this specific controller, you will get different kinds of data from your Data Access Object (dao), and the add them to your model.
Once model is filled with data, you can pass it to a view ( = render view with this model), and in view you'll display it any way you want to.
I hope that basic flow is now clear to you.
Referring to #BeK's answer:
handling requests that take longer will always need an individual approach. You may choose to load this part asynchronously, you may (and probably will) try to cache as much as you can.
Loading the sidebar:
most of MVC frameworks provide some kind of 'base template' for your view.
That means you can define one part of view (e.g siderbar or footer) that is displayed on every page, and in particular controllers you only care about the dynamic parts. Those solutions are flexible enough to satisfy most of the typical needs.
There are a lot of options depending on what are you displaying in that sidebar - is it static or dynamic? what can be cached? etc.
There are several options here. It really depends on what kind of data you are loading. If one of the data requests takes a long time the view will not be displayed until all the data is gathered. If you break the view down in partials and let them load async, the user will have a better UX. In this way you can have the separate controllers/controller methods, complying with patterns like SRP.
If you want all the data to be displayed in the sidebar of every page, than maybe one controller taking care of it will be an easier solution, but again I would suggest take a look at the data you are loading and especially the time it takes to load all the data. Hope this answers your question or sets you on the right path.
alternate approach to follow SRP is using MVC child actions.
create many models and controller. each controller responsible for its own business logic
eg.
PostsController
NewsController
GamesController
HomeController
starting from HomeController that render the HomePage.cshtml
<div>#Html.Partial("Login.cshtml", Model.CurrentUser)</div>
<div>
<hgroup>
<h2>what's new</h2>
</hgroup>
<div>#Html.Action("WhatNew", "News")</div>
<div>#Html.Action("RecentlyPosted", "Posts")</div>
</div>
<aside>
<h2>Games</h2>
<div>#Html.Action("MostPlayed", "Games")</div>
</aside>
you may fetch list of many controller/actions name as string in HomeController then render multiple child actions in main page.
I have this idea of generating an array of user-links that will depend on user-roles.
The user can be a student or an admin.
What I have in mind is use a foreach loop to generate a list of links that is only available for certain users.
My problem is, I created a helper class called Navigation, but I am so certain that I MUST NOT hard-code the links in there, instead I want that helper class to just read an object sent from somewhere, and then will return the desired navigation array to a page.
Follow up questions, where do you think should i keep the links that will only be available for students, for admins. Should i just keep them in a text-file?
or if it is possible to create a controller that passes an array of links, for example
a method in nav_controller class -> studentLinks(){} that will send an array of links to the helper class, the the helper class will then send it to the view..
Sorry if I'm quite crazy at explaining. Do you have any related resources?
From your description it seems that you are building some education-related system. It would make sense to create implementation in such way, that you can later expand the project. Seems reasonable to expect addition of "lectors" as a role later.
Then again .. I am not sure how extensive your knowledge about MVC design pattern is.
That said, in this situation I would consider two ways to solve this:
View requests current user's status from model layer and, based on the response, requests additional data. Then view uses either admin or user templates and creates the response.
You can either hardcode the specific navigation items in the templates, from which you build the response, or the lit of available navigation items can be a part of the additional information that you requested from model layer.
The downside for this method is, that every time you need, when you need to add another group, you will have to rewrite some (if not all) view classes.
Wrap the structures from model layer in a containment object (the basis of implementation available in this post), which would let you restrict, what data is returned.
When using this approach, the views aways request all the available information from model layer, but some of it will return null, in which case the template would not be applied. To implement this, the list of available navigation items would have to be provided by model layer.
P.S. As you might have noticed from this description, view is not a template and model is not a class.
It really depends on what you're already using and the scale of your project. If you're using a db - stick it there. If you're using xml/json/yaml/whatever - store it in a file with corresponding format. If you have neither - hardcode it. What I mean - avoid using multiple technologies to store data. Also, if the links won't be updated frequently and the users won't be able to customize them I'd hardcode them. There's no point in creating something very complex for the sake of dynamics if the app will be mostly static.
Note that this question doesn't quite fit in stackoverflow. programmers.stackexchange.com would probably be a better fit
I'm building a multi-lingual web application using the MVC pattern as the starting position. The application has a number of forms that users will be interacting with and many of these forms will have fields that do a lookup from a database table, 'Province' for example.
If I need the options in these lists to be displayed in the users' language on the screen, I can see a couple of ways to do this:
In the model. When querying the model, I can provide the language that I desire the results to be returned in. This would allow translations to be used everywhere that data from the model is displayed without changes. However, this also means that the Province model in my example (plus all other application models) now need to know how to do language translations.
In the controller. I can query the model in the controller action as usual and then create a 'Translator' object that I can pass the results into before completing the action. This would imply that each controller action would potentially be duplicating the same translation code, violating the DRY principle.
In the view. Since the presentation of the application is generally expected to exist in the views, and the language of the user doesn't impact the business logic of the system, an argument could be made that language translations belong here. Especially considering that a page could also contain static content that will need to be translated. The downside to this is that it would complicate the views somewhat, especially for the front-end designers who will have to work around the new translation code.
Is there an accepted best-practice for where text translations belong in the MCV pattern for web applications? Does this change at all if I were to be loading the select list options via an AJAX call instead of at page load time?
Thanks for the help!
The best place to handle it is in the view. Your question only references dynamic data from the database, but you also have to handle the static information in your views as well. Best to handle both of those in the same place. A common practice in MVC for handling multiple language is resource strings, separate views for each language, or a combination of both. For information from the database resource strings would work well. You would store a token in the database for the options in the list (that token could be the English translation) and the view would get the appropriate translation from a resource for the specified country/locale. There is a good detailed explanation on this approach in this blog post.
If you need to translate part of your UI, then I would create a helper method that would read a resource file and output a translated string for that resources. E.g.
#Translate("NewUserHeading")
So regarding the UI, it makes sense to handle this in the UI.
If the data that you are going to translate at some point might be shown in a Flash client, or a mobile app, then it should be translated by a server and it should have nothing to do with your MVC application.
Honestly, any interaction with a database should be handled in the model, and that's the only thing handled in the model. Interpreting/organizing that data should be handled in the controller. I guess more information would be need as to where this translation is coming from and how that works to really give a solid answer.
The view will just display strings from a resource file. Including the correct resource file for the locale should do it. In Web applications, it's often a single language JS file defining the UI strings per locale, e.g, strings.en-us.js, strings.pt-br.js and so on.
Some strings do come from the server dynamically, the controller doesn't need to know about it, the model should just grab the localized strings and return is as part of the data request.
So it's either in the view (if it's static) or in the model, (if it's dynamic). Controllers should just translate data from the view to the model and from the model to the view
Another very important thing to consider is WHEN to Translate. Using a once-per-each-translation method like #Translate("NewUserHeading") is fine if you only have 100 translations on your page, but what if you have more?
Because think about it, translation is based upon language choice and that only happens once-per-page or even once-per-session. The way that the Kendo UI people do it in their demo is that way, when the User clicks a new language a new set of server files is loaded. That would mean having something like:
/src/html/en-us/
/src/js/en-us/
/src/html/es/
/src/js/es/
etc..
Check it out at https://demos.telerik.com/kendo-ui/grid/localization
It's a trade off of more work for better performance. The ultimate use-case of translation right now is https://www.jw.org/ with over 900 languages!
using CodeIgniter normally one has to specify the controllers in the config/routes.php file.
This is not to handy, so I would like to be able to do something like this in a controller.
get url parts and check if the first part is specified in an array
if so, load the specified controller, if not, load default controller.
It basically mimics the behavior of the routes file, but there is no need to specify the wildcards before. I am using a base controller I extend with every controller, but I would like to have this controller just load (or include) the needed controller.
Does anyone have any idea how I can do this in a good way?
Thanks in advance.
// Edit
Okay, so here is my scenario.
I have cms and users can choose to include modules (e.g. a gallery).
I need to inlcude all the gallery php scripts without having to have "gallery" in the url.
I figured it would work if I use a "main controller" which loads another controller depending on the modules chosen. I realize this might not be the best way, so if there is a "clean" way to do it, please tell me.
As far as I know models are just for database stuff, so putting a whole gallery in there is not right either. The Plugin itself will of course be a library, but there is going to be some code to load the libs depending on the demands, get the database data, etc.
Thanks
The way you're doing this is incorrect. You never should take over the routing function to do this. What you need is to use some kind of module functionality to include the required methods and models; a module doesn't require to have route-accessible methods, so it's basically a "library" with a model and views.
If I remember correctly there are several plugins that provide this, One was HMVC (google it).
The ideal form would be to load the "Module" on demand from your controller, like you do with the core CodeIgniter Libraries; so lets say you're inside the blog controller action and you want to include the comment module which is used on gallery and on images, you just include the module and call it's methods to get the data which you can then pass to the view as needed; you can even render partials and store them into a variable to pass to your master controller.
Hope this is enough to get you on the right track :)
I may be misunderstanding your question but you want to load your controllers if you go to them and if not you want to go to your default.
If I am understanding correctly you can do a couple things in your routes have a route that takes everything to your default controller.
In your controller have an array of all your controllers then implode the array to a regular expression
$array = [c1, c2, c3, c4];
$str = implode('|', $array);
$regex = "($str)"
now just add your regex to a route
now redirect as you see fit.
But this is really what the routes file is for you you are just dancing around something that should be used.
Before rendering into a view model should be formatted:
multilingual data localized;
date, time values formatted;
numbers formatted.
Who performs all this formatting - Controller or View?
Am I right that all the formatting is performed by the Controller which creates so called ViewModel containing only formatted values and sends this ViewModel to the View?
Thanks in advance!
Eric Petroelje is right, but I would build helper a class(es) to get localised content/dates etc, because localisation isn't always in the views, e.g. sending emails with localised content. I would have something like LocalisationHelper.GetString("MyKey"), or LocalisationHelper.GetDate(Date.Now), where the LocalisationHelper knows the users current locale (maybe from Session).
Then use this directly in the views where possible:
<%= Html.Encode(LocalisationHelper.GetDate(Date.Now)) %>
Design Patterns 101.
Model is for storing data (usually database-backed).
View is for presenting the data (not manipulating it).
Controller is for manipulating the model and passing that to the view (choosing the right locale for instance would go here).
MVC doesn't necessarily mean you have 3 distinct classes, but rather 3 components or layers. These are abstract and don't necessarily have to be tied to one physical class. Inside your Controller layer, that can consist of any number of helper classes or whatever.
I agree with part of what cartoonfox is saying, everything is intertwined. For instance, if you develop a view for a shopping cart, but the model is containing birthday information, then it isn't going to work. It is simply a design pattern to help remove duplication of effort. When you have fewer variables and less noise, it is much easier to focus on what needs to be done and understand it very well.
I had a discussion with our team about using annotations to render forms on a web page. These annotations were placed in the model or entity class. You will often work directly with entity classes, so it eliminates quite a bit of overhead and duplication of effort if you put your annotations here. Because your annotations are placed directly on the model class, you cannot end up with a view for birthday information, it just isn't possible. In addition, by following patterns, you strip out the junk that doesn't add value to the end result. You simply write the business logic and close to nothing else.
Although the annotations were in the same class as the model layer, the presentation or view layer consisted of the annotations and the helper classes. It doesn't need to necessarily be distinct classes or boundaries.
Another example would be. I've worked on some PHP web "applications" in the past. I use applications because they were a monolithic block of code, more or less a single main method with all the logic in there (which is hardly a functional application).
If you don't abstract code into functions and simply use a single method, you will end up with a lot of duplication of effort. If you tried to understand that monolithic code block, you would be in for a heap of trouble (as was I, it was hard to learn what was going on, then I would find a similar block of code somewhere else and be dumbfounded why a few things were tweaked the way they were).
It can be done any way you want, but design patterns such as MVC help you simplify what you write in order to get it to work as well as more easily wrap your head around the solution. Another popular design pattern or approach is divide and conquer.
To answer your original questions:
In Java, localized data would be done transparently by the application. For instance, if you wanted US English locale support, you would create a properties file:
messages_en-US.properties
and then place all your US English content in there. Depending on how much content this may be, you might want to use a different approach.
For my application I have whole pages in a different language so what I do is this. My controller determines the client's locale or a best match. Then it chooses which view to display and passes the model (data) to the view.
If you need dynamic formatting for your date/times, then your controller is responsible for determining which one will be used. Then, your view is responsible for using that converter to format the value.
I'm using JBoss Seam so the MVC design pattern is still used, but more abstractly. I don't have actual 'controllers', but an interceptor which is responsible for handling a specific piece of functionality (determining the client's locale, then another for their date/time preference). My controllers that would be the equivalent of a Spring Controller are action components responsible for handling page actions.
Walter
The view is responsible for this not the controller.
To explain I need to elaborate a bit about what the "view" is:
In both web-based and traditional GUI MVC patterns, the View is responsible for the external representation of whatever parts of the model that are shown. If that means "formatting" data from the model then so be it.
The controller shouldn't format the data - because the controller is responsible for doing things to the model based on events/commands coming in from the outside world. The controller doesn't have anything to do with rendering the output.
Example:
I want to display a shopping cart with several order lines:
Adding things to the cart causes the controller to change what's in the cart model.
Changing my locale causes the controller to change a setting in the user model to indicate preferred locale.
Whenever the cart is displayed, the view has to ask the model for the order lines and decide how to display that - maybe doing locale-sensitive work.
The same customer could ask to see the shopping cart in multiple different currencies. That just means changing what it looks like in the view. It's still the same shopping cart for the same customer with the same things in it.
If this is a web-app made from web template pages, you might embed code to pull in localized messages e.g. <%= message_renderer.text(:insufficient_funds) %>. In this case the "message_renderer" and the template file are both part of the view.
Views aren't necessarily just web-based templates. In some Java-based frameworks for example, we put "view objects" into a velocity template. Those view objects are linked back to objects in the model, but they also perform on-demand rendering and formatting behaviour. Those are part of the view although they're not just a template.
It's a bit confusing with frameworks like ruby on rails and groovy on grails where they call the template the "view" - when a view is really more than just a template. Traditionally (in Smalltalk MVC and in Java's Swing) views are just code that can perform formatting, rendering and any other display-related behaviour.
All that stuff seems like presentation layer logic, so personally I think it should go in the view.
ETA:
I wouldn't advocate for having the view call service layer objects in the general sense, but for localization I think it makes sense.
For example, lets say you have lots of static text on your pages that you have tokenized and stored in a database in various localized forms. I don't think it would make sense for the controller to have to lookup and put all those text tokens in the model. Even though a text token lookup is technically a "service layer" operation, I still think it makes sense for the view to call that service directly via some utility class rather than having the controller do it.