The architecture of the portal UI is based on the Model-View-Control (MVC) design pattern. The MVC paradigm allows you to separate the code that handles business logic from the code that controls presentation and event handling. Each page in the portal is made up of a combination of at least one Model and View, and one or more Controls.
Model classes store the data for a page or page section. A single page might use one or more Model classes, depending on how much of the page data can be shared by other types of pages. A Model defines how data is accessed and set for a given page, including any functions necessary for security or data validation and modification. Models encapsulate calls to the portal server API and also store UI-specific data. Data that is globally accessed by the UI is available from the ActivitySpace object (discussed on the next page). All other data should be stored in a Model.
View classes contain HTMLElements and HTMLConstructs that describe how the data from the Model should be displayed to the user. In the portal UI design, DisplayPage objects are used to aggregate View objects to encapsulate all the information needed to render a particular page. Some Views are common throughout the portal and some are specific to certain pages. For example, the banner that makes up the majority of the portal is a common View that defines the color scheme and where the search section will be displayed. In contrast, the View used to create and modify data within a User Profile is specific to the User Profile function and is seen only on that page.
Control are actions or sets of actions that are executed when a specific event is triggered. Multiple Controls can be defined within a page, each with its own functional specification. For example, one Control might produce a popup window that allows the user to browse for a specific object and places the selection within the View, and another could save the new data to the Model.
The diagram below shows a simplified version of how the classes used for the Login page interact with each other using the Model-View-Control (MVC) pattern.
|
 |
The Control either redirects to another page or returns to the same page with new data since the Model has been updated. In this case, the Control redirects to the MyPage.
The Interpreter gets the HTML for the page requested by the Control from the appropriate View, in this case the MyPage View.
The View returns the HTML for the page.
The Interpreter sends the HTML for the page back to the browser.
Note that the redirect from the Login page to the MyPage occurred without returning to the client. These Server Redirects are handled by the Interpreter. The portal favors server redirects over regular redirects (i.e., Response.redirect) because they avoid unnecessary roundtrips to the client. Regular redirects are used in a few cases; for example, some Security Modes require a redirect to switch between HTTP and HTTPS pages.
Next: Activity Spaces