| Putting the View back into MVC. |
[eluser]Pygon[/eluser]
[quote author="dtrenz" date="1205437291"] Are you all saying that all the controller should do is call model methods and load views, and that all data formatting or prep should be handled in the models as well as data access? [/quote] Absolutely not. All data formatting should be handled by the view. The model and controller don't care AT ALL how the data is presented or what it is presented with. [quote author="dtrenz" date="1205437291"] Quote:EXAMPLE: In this example, would you have 2 separate model methods for retrieving the bio text? One that returned the bio, truncated by some string truncate function, and another that returned the whole bio text? I currently have one model for retrieving the bio, and then in the controller, I truncate (or not) before sending the bio text to the view. Which is correct MVC? Either?[/quote] Neither -- Your model should give the view what it asks for (the bio), which the view should truncate if that is how the view wants to display it.
[eluser]zilverdistel[/eluser]
@dtrenz: Concerning the example: I would keep one model for retrieving the bio, and truncate in the view (by passing a parameter from within the controller, not by passing the data). _or_ 1 model, 2 views But common thing is that in my opinion, the view should decide what information it needs, and retrieve it from the model. The controller should define the flow. (=application logic? i don't know, this term has allways confused me)
[eluser]dtrenz[/eluser]
OK. 2 Questions: 1) You keep saying that the view should get data from the model. Do you actually load models in your views? Or is this the CI vs. strict MVC difference again? 2) It seems like proper MVC usage of a view, which would contain a healthy dose of code for the presentation logic, is at odds with the goal of creating designer-friendly view files. Is it not?
[eluser]xwero[/eluser]
Pygon if i understand your explanation correct and the diagram model sentence "responds to state queries" should the routing be a responsibility of the model?
[eluser]Pygon[/eluser]
dtrenz: 1) The model should be instantiated by wheever the caller is, if it has not already been loaded. If the controller has not accessed a model, then it would be loaded by the view. "Loading" however, doesn't really matter where the load comes from -- it's simply instantiating the model for global access. 2) The concept of "designer-friendly" view files is itself a thing of its own. PHP itself was intended as an inline language (the reason you have to start and stop with <?php and ?>  . None of what has been said would PREVENT you from creating designer-friendly methods of handling views. You have to understand that the term "view" in CI is not the same as the "view" structure in MVC.Let me break it down a little. In theory, your view structure should contain two parts: Logical Layer - obtains data from model, determines what other views should be loaded, processes/formats data and sends everything to presentation layers Presentation Layer - works similar to the way the current load->view(name,data) works. This should be a sub-layer. This also allows you to change from CI's current way of creating views, to using any other "designer-friendly" method, like smarty or other template engine. In reality, we're only talking about an additional view layer (a view "controller" of sorts). xwero: I'm not certain of what you mean by "routing". URI Routing is actually a seperate process from MVC and has to be lumped in more with the framework than part of MVC. Static routes and defined routes are really just a way to avoid the controller needing to determine what action to take (ie what view to load). It's similar to the way that requests in a C program are handled by the application and routed to the correct controller in a similar fashion -- this part should be essentially transparent to the controller.
[eluser]zilverdistel[/eluser]
[quote author="dtrenz" date="1205442048"]OK. 2 Questions: 1) You keep saying that the view should get data from the model. Do you actually load models in your views? Or is this the CI vs. strict MVC difference again? 2) It seems like proper MVC usage of a view, which would contain a healthy dose of code for the presentation logic, is at odds with the goal of creating designer-friendly view files. Is it not?[/quote] 1> I load models in the controller, but I pull data from the model from within my views. About the second question: I tried to implement a full (I mean strict, and from my interpretation off course) MVC design, but I failed this, because I didn't include CI itself in the design. (Got a lot of trouble with objects, because in CI they inherit a lot of stuff from CI-superobject, which makes them pretty large. I couldn't store them properly in a session.) 2> You're right about that, and that's why I'm happy CI leaves us the choice. I don't know anything about templating libraries in CI, because I never used them, but my guess is that this problem can be tackled with templating. And also, nowadays with CSS and JS, if you supply the designers with a set of meaningfull (semantics!) id's and classes in the html, they can do everything they want. In other words: webstandards rule! (but that's another topic ;-)
[eluser]adamp1[/eluser]
By the sounds of everyone's argument it seems the Model should do nearly everything, poor little thing. Anyway this is my understanding of MVC from what I have been reading the past days. 1. The model accepts requests for fetching/updating data, checks if its good and performs the action. Return either the data requested or the status of the action (i.e errors). 2. The controller accepts actions from the user in some form and calls models to update data, and decides what UI to display back (view). 3. The view uses the modal indirectly to display data. Now from this it implies the following: Validation should be done by the model, since its data. The view should handle all presentation, this does mean formatting data (since formatting is presentation). Yes that does mean more code but remember its not a template. Quote:You keep saying that the view should get data from the model. Do you actually load models in your views? What I believe it means is it means when it says the view uses the model, is the view uses the model through some other medium, I.E a variable passed from the controller or something. If the model was loaded directly into the view the view wouldn't use the model indirectly, which if you read it says so nearly everywhere that this is the case. The same goes if the view accessed the model object directly. I think the person who has it 100% correct is Pygon, and I quote: [quote author="Pygon" date="1205439144"][quote author="dtrenz" date="1205437291"] Are you all saying that all the controller should do is call model methods and load views, and that all data formatting or prep should be handled in the models as well as data access? [/quote] Absolutely not. All data formatting should be handled by the view. The model and controller don't care AT ALL how the data is presented or what it is presented with. [quote author="dtrenz" date="1205437291"] Quote:EXAMPLE: In this example, would you have 2 separate model methods for retrieving the bio text? One that returned the bio, truncated by some string truncate function, and another that returned the whole bio text? I currently have one model for retrieving the bio, and then in the controller, I truncate (or not) before sending the bio text to the view. Which is correct MVC? Either?[/quote] Neither -- Your model should give the view what it asks for (the bio), which the view should truncate if that is how the view wants to display it.[/quote] Anyway thats my £0.02 (doesn't sound the same as 2 cent).
[eluser]adamp1[/eluser]
I believe this is a document written by the person who created the MVC pattern, I can't be bothered to read now since I have a tone of work to do for tomz and have done none so far  . Anyway I'm sure the answer is in there, personally what ever he says is the right way is the right way.THE ANSWER
[eluser]Pygon[/eluser]
[quote author="adamp1" date="1205445261"]I believe this is a document written by the person who created the MVC pattern[/quote] Unlikely, hehe. The first line is: MVC was conceived in 1978 as the design solution to a particular problem. This is just yet another interpretation of MVC. But again, the original patter was developed for SmallTalk (afaik) and is hard to implement exactly elsewhere, therefore the need for interpretation. Edit: This also appears to be a publication, possibly from a university student as part of a "first draft of a system architecture based on MVC". Still reading.
[eluser]Pygon[/eluser]
I think PAC uses a better acronym for what the objectives of the components of MVC are. Controller (control) - Application's logical layer. What order should things happen in? Model (abstraction) - Doesn't care who, what, when, or where. It's job is just to make changes and return results when asked. A model isn't necessary unless you need to interact with some form of dynamic data. View (presentation) - This defines out everything looks, from whether there should be menus, or not, to how data is displayed and WHAT data is displayed. Here's the deal. If you want to view a web page (not taking action), the your controller really only has one job: Decide what view to show. It doesn't care how the view looks, what data is in the view or anything else. Your business logic is probably only going to determine one thing at this point -- should the user be able to view this page, yes or no? After this decision is made, you're really talking about presentational issues. Should I show this? The user is able to do this so I should probably give him the ability to access that controller. The user shouldn't be able to do that, so I really shouldn't show it. Simply -- 100% of how a page looks should be determined by the view and the responses it gets from models. WHICH page is being shown is the responsibility of the controller. Whether to allow an action to take place also falls to the controller. |
| Welcome Guest, Not a member yet? Register Sign In |
MENU
EXTRA MENU
ABOUT US
CodeIgniter is a powerful PHP framework with a very small footprint, built for developers who need a simple and elegant toolkit to create full-featured web applications.
