In codeigniter,we can easily follow the MVC flow but is it possible to fetch the data from a view to model or controller ?
In a perfect world the view receives data from the controller that receives data from the model(s).
You can reverse/change this order. You can actually do whatever you want, but it's not recommended.
Related
If i use the MVC pattern to create my Spring project, is it wrong to call the Controller from the View?
Is this schema right?:
View calls the Controller
Controller performs operations and put data result into the Model
View reads data from the Model
Edit:
In my index jsp there is a menu with several categories of articles. I want to pass the name of the category to the controller. The controller calls the method of a beans which executes a query and returns the list of articles presents into the database.The Controller puts this list into the model and the View read this list from the Model.
Thanks
What you say (in your comments) is not specially wrong, but it does not make sense.
Either the categories are known when you build the view, and then it is the controller role to collate all information and put it into the model before calling the view with the model.
Or the category is chosen through a user interaction. But at this moment, the JSP is over for a long time : the response has been committed and transmitted to the browser. The only possibility is to prepare a new request (with a form or with ajax), send this new request to the server, where it will be handled by a controller, which will collate data into a (new) model and pass it all to a view
Depends what you mean by calling. But yes, View doesn't know anything about the controllers. It sends HttpRequests, and than the mechanism doing what you describe kicks in. There's the famous schema from spring docs, basically your bullets described via diagram. The point with respect to your question is that the view doesn't call the controller rather sends the request
I think you will find your answers in article mentioned below :
http://docs.spring.io/spring-framework/docs/2.5.3/reference/mvc.html
JQuery’s AJAX “.get” method calls a (php page)method of a controller and the returned data is further processed….but then as we consider it a best practice, controllers are meant to just transfer control to the models and views..A controller never returns anything or echoes any data…so how can we support this argument? I may be wrong..still in the initial learning stages so pardon me if you find the question a bit too naive :(.
One eg. is JQuery’s autocomplete plugin that I was trying to implement which expects an array of users name from the database. Generally, with CI..the flow is View form -> Controller -> Database Model(DATA) -> Controller (DATA)-> Another view…but if I have to implement the JQuery/AJAX way then the controller will have to output data so that the AJAX calling function (get) can grab it. Right?
So what should be the flow without affecting the MVC paradigm?
Regards.
MVC is just a design pattern. It tends to make things easier. But its a way of designing your applications, that doesn't mean you have to stick to it.
I work with Codeigniter and use controllers to reply to ajax. In my case the controller is in charge of receiving the request, and sending data back (just as if I was calling a view or template).
Don't overthink it, use what you want,when you want to, the way best fits your needs.
The other option if you really want to stick to mvc is to have a view which you simply use for ajax responses.
You can either have it simply echo the response, or you can have it json_encode() you response if you are always going to be replying using json.
As Nicolás points out, MVC is a design pattern, not law.
However, you should think of AJAX not as a View but as a transport, a medium through which communication between Controller and View or Model and View happens. Thus your actual View is not represented in PHP anymore but by the Browser itself, or rather its JavaScript code that you are running on it. You can abstract away the AJAX on the PHP side using an RPC server like the Zend JSON-RPC Server.
Also note that for Web Applications, the Model-View-Presenter and similar patterns may be more useful as it keeps communication between View and Presenter.
I am planning to use knockout.js and MVVM pattern on the client side for a Single Page application. So Models, ViewModels would be defined on the client side. I am confused about how we have to structure on the server side.
Now, would controllers just return domain model itself ? Would all the mapping from domain model to ViewModel happen only on the client side ?
In my solution, there is wide gap between the Domain model and the ViewModel. So the above approach would result in a lot of data being returned to client side unnecessarily. Though it seems like overkill, I am thinking about repeating ViewModel and InputViewModel definitions (former represents data rendered, latter represents data to be posted back to controller actions) on server side and also having a mapping layer (based on automapper) to map Domain models to ViewModels on the server side. Does this make sense ? Or is there a better approach ?
I would suggest that you work out what data your view models actually need, then have the controllers build up a server-side view model that contains that data and send it to the client in a JSON format.
This way you are not sending unnecessary data over to the client (or back), you are still able to do much of the heavy lifting on the server and the knockout view models can do what they are meant for: presenting the data to be used by the view.
What you described in point 2 is actually the solution I use the most and it makes sense to me:
I use Automapper on the server side to map between Domain models and ViewModels (.Net objects) that are View specific and contain only the data the View needs.
The Controller Action that is responsible for loading the View the first time, will databind the View to the ViewModel, so that the page is initialized quickly without the need to make an Ajax call.
In the View itself I create the knockout viewmodel, assigning any initial values (if needed) by Json encoding the bounded ViewModel (for example using Asp.Net MVC i would do something like
var boundedViewModel = #Html.Raw(Json.Encode(Model));
That is exactly how I would approach this problem. If this were a straight MVC app, you would still be creating viewmodels.
Sometimes for complicated data sets, I can see a use case for using something like Knockback, which takes the rich data model of backbone.js and combines it with knockout.js
http://kmalakoff.github.com/knockback/
can anybody tell me, why communicates the model direct with the view in the MVC pattern, and why not just throught the controller?
http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller
Sometimes it is too costly to use Controller for simple View/Model communication.
If your view just shows raw data without any operation (filtration, visualization, modification ...) it is easy to forget about Controller.
But this behavior is so abuse-able sometimes it kills all of the advantages of MVC.
And this where MVP comes in:
MVP (Model-View-Presenter) cuts the connection between model and view and every thing pass through man-in-the-middle (Presenter).
The views know of the model and will interact with the model.
If a button is clicked an action message might be sent to a model object in order to get
something done.
If a new value is typed into an entry field an update message might be sent to a model
object in order to give it its new value.
If a value is needed for a display an enquiry message might be sent to a model object in
order to get a value.
I'd like to know where the controller gets the user input from (to feed the model with). Because input media is strongly related to the user shouldn't the view be aware of the concrete way to get the user's data? But how can I separate the controller from the view then? Is it possible to make both completely independent of each other as their purposes suggest?
Example:
When I have an application which uses the curses library for the view it implies that the it's only accessible through the terminal. Using curses methods to read user data in the controller would break encapsulation but calling methods on the view would have nothing to do with displaying the model.
IN MVC, the controller gets its user input from the View.
Consider having the View and Controller communicate through the Observer pattern. The Controller registers itself as an Observer with the View. When the user inputs data into the View and presses Enter, then the View interprets the data and notifies its observers that there is data available. The Controller can then get the data from the View through a public method.
I dont think that the view really has much to do with inputting data actually. I find MVC much easier to visualise if you see the user as communicating with the controller directly. A controller receives data from the user and sends views back. In many systems the view engine has some limited way of updating itself (ie text inputs display what is typed before it is sent to the controller). But for any MVC type architecture you can replace any view with any other view provided they are both capable of handling the same data.
For example. Entering a username can be done on any system that supports entering strings. The controller accepts a string, and so can be used in a web application, a terminal application, or a GUI application.
I think the view should have a callback on the controller to send over user input. In web architecture, the callback is provided through the ability to send the user input back to the server through http requests.
In your case, your ncurse front should probably have some kind of callback method to the controller component to send back user input.
Well,
I'll try to be more specific for you. Giving vague/abstract answers for ppl that you can see, doesn't master the subject, doesnt help.
MVC -> Model View Controler
There are many implementation of MVC, I don't know your case, but I'll give you one.
The most common MVC implementation acts like this..
view <-> Controler <-> Model
In a web scenario..
The view would be your HTML pages and data input would happen in a form.
<form action=/home/createuser method=post>
...code goes here...
</form>
Home would be your controller (a class named home), and createuser a method in home.
public class Home extends Controller {
public void createUser(Userform f){
...create user...
}
}
This form would submit data into the method as parameters. Createuser would them processed to talk to the model and later persist the data if thats the case.