HTML and CSS Reference
In-Depth Information
Views this is the code used to display information to the user. there is no logic of any
kind done here; a view, in the web app context, should be as close to plain html as
a typical request made to an mVC-based app should closely resemble these (see Figure 5-3 ).
Figure 5-3. A diagram showing the order of operations for a typical MVC request
there's a lot of disagreement on how an mVC-based app should work, this is our take.
let's take a walk through the steps shown in Figure 5-3 with the application we're building in mind.
the user interacts with the client application—the controller—by passing a command via
the uniform resource indicator (uri). this could be a presentation attendee filling out and
submitting the question form, or upvoting a question. or it could be the presenter marking
a question as answered. this results in a request being made from the client application
to the server.
the controller processes that request, determines the action based on the request
parameters. it then interacts with the appropriate model based on those inputs.
a model within mVC can also represent, or contain, the data access layer. in our
application, this is the case. so when the model is interacted with as a result of a user
submitting a question, it will result in the question being stored in the database. if it's
a result of a question upvote, the fact that the question has been upvoted will also be
persisted. after the model has handled the interaction, it returns the appropriate data to
the controller.
the controller processes the response from the model and delivers it to the view.
the view updates according to the response from the controller. a question being
submitted may result in the view changing to show all the questions for the presenter
while highlighting the newly added question. or in the case of an upvote, the question
may change position in the view.
Search WWH ::

Custom Search