I am having a hard time trying to understand the MVC pattern, in particular the role of input fields in this pattern.
1. Conceptual question.
Let’s say I have a document as model and a text area displaying the document. Is the text area a view or a controller?
- Because the text area shows the document (for example, after the user loads the document from disk), it is a view.
- Because the user can interact with the text area (adding/removing/saving the text to disk), it is a controller.
2. Practical question.
Should changes in the document update the text area, or should changes in the text area update the document?
- Changes in the document should update the text area, for example, when the document is changed on disk by an external program, or when the document is also synced with a different input field.
- Changes in the text area should update the document, so that the user’s input is saved.
I was trying to do both via the observer pattern, and that creates an infinite loop (text area changes -> document updates -> text area changes …). How to break this cycle?
1
Is the text area a view or a controller?
The text area is a view, because it is a component the user interacts with. The view is the user interface. Of course this all depends on how complex this text area is.
If the text area is just a plain text input, then I would say it is part of the view.
If the text area is a rich text editor, then what you call a “text area” is an entire UI component that likely has its own set of sub controllers, sub views and sub models to make the user interaction work.
However, if you are not writing the code to implement a text area then it will be a component in the view, and is thus considered part of the view.
Because the user can interact with the text area (adding/removing/saving the text to disk), it is a controller.
A text area should not be loading or saving data from storage. That is what the controller is for.
Should changes in the document update the text area, or should changes in the text area update the document?
It depends.
For a traditional GUI application you could set up a process to monitor the document for changes, and auto update the document on screen, but then you need to deal with merging the document on disk with the changes the user applied to it. This is not an easy task. For this you usually warn the user that the document has changed, and give them the option to load the file again from disk.
When your application has a network sitting in between the file on disk and the text area, as you do with a web application or mobile app that utilizes web services, then it is extra work to set up a streaming web socket to broadcast these kinds of events from server to client. Generally when saving the document is when you check to see if it has changed, and warn the user if it has.
The reverse is also true. In a classic GUI application changes in the text area can easily propagate to the file on disk. This works well, until you have multiple people editing the same file.
In a web or mobile application, you can do the same thing, but you must also deal with the same pitfalls of modifying a shared resource.
In summary, if your application is using a text area, then it is part of the view.
If your application is literally the code required to implement a text area component that is embedded in other views, then it could have its own models, views and controllers.
Most people do not write their own text areas, and use pre-built components, so we consider text areas to be part of the view exclusively.