1. By default, an UpdatePanel control is refreshed when either one of its child controls causes a postback or another UpdatePanel in the page is refreshed. This behavior can be altered with some public properties—namely UpdateMode, ChildrenAsTriggers, and Triggers.
2. If there are multiple update panels on a page, if one gets refreshed the other would also get refreshed.
a. This is because the UpdateMode of the update panel is set to "Always" by default. You can set it to "Conditional" to refresh conditionally and not always.
b. The ChildrenAsTriggers property is a Boolean property (true by default) that determines whether child controls of a panel act as triggers of AJAX postback events.
3. Have smaller panels that bring back just the minimum amount of markup you need for that particular click.
Saturday, August 1, 2009
Friday, June 5, 2009
MVC - Model View Controller
Being an ASP.NET programmer, I have always struggled to understand the three components of MVC and how are they supposed to interact with each other. What are the advantages of MVC and if at all the pattern is followed by ASP.NET WebForms?
But before we delve into other subjects, let's try to understand MVC.
MVC divides an interactive application into the three areas: processing, output, and input.
The model component encapsulates core data and functionality. The model is independent of specific output representations or input behavior. The model is an object that represents some information about the domain. It's a nonvisual object containing all the data and behavior other than that used for the UI
View components display information to the user. A view obtains the
data from the model. There can be multiple views of the model.
Each view has an associated controller component. Controllers receive input, usually as events that encode mouse movement, activation of mouse buttons, or keyboard input. Events are translated to service requests for the model or the view. The user interacts with the system solely through controllers.
Any changes to the information are handled by the third member of the MVC trinity: the controller. The controller takes user input, manipulates the model, and causes the view to update appropriately. In this way UI is a combination of the view and the controller.
From Martin Fowler...
A request comes in to an input controller, which pulls information off the request. It then forwards the business logic to an appropriate model object. The model object talks to the data source and does everything indicated by the request as well as gather information for the response. When it's done it returns control to the input controller, which looks at the results and decides which view is needed to display the response. It then passes control, together with the response data, to the view. The input controller's handoff to the view often isn't always a straight call but often involves forwarding with the data placed in an agreed place on some form of HTTP session object that's shared between the input controller and the view.
There are two principal separations
1. Presentation and model
The presentation depends on the model but the model doesn't depend on the presentation.The presentation acts as the observer of the model: whenever the model changes it sends out an event and the presentations refresh the information.
2. View and controller
To support editable and noneditable behavior, which you can do with one view and two controllers for the two cases, where the controllers are strategies for the view. In practice most systems have only one controller per view, however, so this separation is usually not done. It has come back into vogue with Web interfaces where it becomes useful for separating the controller and view again.
Application Controller
The purpose of an Application Controller is to handle the flow of an application, deciding which screens should appear in which order. It may appear as part of the presentation layer, or you can think of it as a separate layer that mediates between the presentation and domain layers.
They're useful if your system has a lot of logic about the order of screens and the navigation between them. They're also useful if you haven't got a simple mapping between your pages and the actions on the domain. But if someone can pretty much see any screen in any order, you'll probably have little need for an Application Controller. A good test is this: If the machine is in control of the screen flow, you need an Application Controller; if the user is in control, you don't.
But before we delve into other subjects, let's try to understand MVC.
MVC divides an interactive application into the three areas: processing, output, and input.
The model component encapsulates core data and functionality. The model is independent of specific output representations or input behavior. The model is an object that represents some information about the domain. It's a nonvisual object containing all the data and behavior other than that used for the UI
View components display information to the user. A view obtains the
data from the model. There can be multiple views of the model.
Each view has an associated controller component. Controllers receive input, usually as events that encode mouse movement, activation of mouse buttons, or keyboard input. Events are translated to service requests for the model or the view. The user interacts with the system solely through controllers.
Any changes to the information are handled by the third member of the MVC trinity: the controller. The controller takes user input, manipulates the model, and causes the view to update appropriately. In this way UI is a combination of the view and the controller.
From Martin Fowler...
A request comes in to an input controller, which pulls information off the request. It then forwards the business logic to an appropriate model object. The model object talks to the data source and does everything indicated by the request as well as gather information for the response. When it's done it returns control to the input controller, which looks at the results and decides which view is needed to display the response. It then passes control, together with the response data, to the view. The input controller's handoff to the view often isn't always a straight call but often involves forwarding with the data placed in an agreed place on some form of HTTP session object that's shared between the input controller and the view.
There are two principal separations
1. Presentation and model
The presentation depends on the model but the model doesn't depend on the presentation.The presentation acts as the observer of the model: whenever the model changes it sends out an event and the presentations refresh the information.
2. View and controller
To support editable and noneditable behavior, which you can do with one view and two controllers for the two cases, where the controllers are strategies for the view. In practice most systems have only one controller per view, however, so this separation is usually not done. It has come back into vogue with Web interfaces where it becomes useful for separating the controller and view again.
Application Controller
The purpose of an Application Controller is to handle the flow of an application, deciding which screens should appear in which order. It may appear as part of the presentation layer, or you can think of it as a separate layer that mediates between the presentation and domain layers.
They're useful if your system has a lot of logic about the order of screens and the navigation between them. They're also useful if you haven't got a simple mapping between your pages and the actions on the domain. But if someone can pretty much see any screen in any order, you'll probably have little need for an Application Controller. A good test is this: If the machine is in control of the screen flow, you need an Application Controller; if the user is in control, you don't.
Subscribe to:
Posts (Atom)