Editing Model–view–controller (section)

===Controller===
Accepts input and converts it to commands for the model or view.<ref>[http://www.codeproject.com/Articles/25057/Simple-Example-of-MVC-Model-View-Controller-Design Simple Example of MVC (Model–View–Controller) Architectural Pattern for Abstraction]</ref>

A Smalltalk-80 controller handles user input events, such as button presses or mouse movement.<ref>{{cite book |last1=LaLonde |first1=Wilf R. |last2=Pugh |first2=John R. |date=1991 |title=Inside Smalltalk |url=https://books.google.com/books?id=RRkiAQAAIAAJ |location=U.S.A. |publisher=Prentice-Hall Inc. |isbn=0-13-467309-3 |page=8 |quote=The controller is responsible for interfacing between the user and the model/view. It interprets keyboard characters along with mouse movements and clicking.}}</ref> At any given time, each controller has one associated view and model, although one model object may hear from many different controllers. Only one controller, the "active" controller, receives user input at any given time; a global [[window manager]] object is responsible for setting the current active controller. If user input prompts a change in a model, the controller will signal the model to change, but the model is then responsible for telling its views to update.<ref>{{cite book |last1=LaLonde |first1=Wilf R. |last2=Pugh |first2=John R. |date=1991 |title=Inside Smalltalk |url=https://books.google.com/books?id=RRkiAQAAIAAJ |location=U.S.A. |publisher=Prentice-Hall Inc. |isbn=0-13-467309-3 |page=11}}</ref>

In WebObjects, the views handle user input, and the controller mediates between the views and the models. There may be only one controller per application, or one controller per window. Much of the application-specific logic is found in the controller.<ref>{{cite book |author=<!--Staff writer(s); no by-line.--> |date=May 2001 |title=WebObjects System Overview |url=https://developer.apple.com/library/archive/documentation/LegacyTechnologies/WebObjects/WebObjects_5/WebObjectsOverview/WebObjectsOverview.pdf |location=Cupertino, CA |publisher=Apple Computer, Inc. |page=28}}</ref>

In Rails, requests arriving at the on-server application from the client are sent to a "router", which maps the request to a specific method of a specific controller. Within that method, the controller interacts with the request data and any relevant model objects and prepares a response using a view. Conventionally, each view has an associated controller; for example, if the application had a <code>client</code> view, it would typically have an associated <code>Clients</code> controller as well. However, developers are free to make other kinds of controllers if they wish.<ref>{{cite web |url=https://guides.rubyonrails.org/action_view_overview.html |title=Action View Overview |author=<!--Not stated--> |date=<!--Not stated--> |website=Rails Guides |access-date=October 27, 2022 |quote=Typically, the views share their name with the associated controller action...}}</ref>

Django calls the object playing this role a "view" instead of a controller.<ref name="djangoviewtemplfaq" /> A Django view is a function that receives a web request and returns a web response. It may use templates to create the response.<ref>{{cite web |url=https://docs.djangoproject.com/en/4.1/topics/http/views/ |title=Writing views |author=<!--Not stated--> |date=<!--Not stated--> |website=Django Documentation |access-date=October 27, 2022}}</ref>