Presentation Layer

MicroStrategy Web products provide support for J2EE and .NET technologies. With the separation of the presentation layer from the business logic, this architecture supports virtually any platform or operating system. MicroStrategy Web products are built on a single code base that can run on Windows, UNIX, or Linux. The architecture shares feature parity, synchronized enhancement schedules, and structural integrity across all operating systems.

When comparing the J2EE and .NET architectures, the architecture differs only in the presentation layer. These differences are highlighted in this section. For information on the other layers of the architecture, refer to the remainder of the architecture section.

The following customization tasks involve modifying objects within this presentation layer:  

• Cosmetic changes such as look and feel, page layout, and navigation  

• External Security Module for single sign-on and user mapping

The presentation layer is the topmost layer, and consists of either JSP files for the architecture with J2EE presentation layer, or ASP.NET files for the architecture with .NET presentation layer. These pages contain HTML and MicroStrategy custom HTML tags. The pages primarily act to lay out the contents of various Web components such as beans, and other GUI elements such as shortcuts, toolbars, and menus.

Servlet or ASP.NET file-Controller combination

In the architecture with J2EE presentation layer, the servlet invokes the Controller, whereas in the architecture with .NET presentation layer, an ASP.NET file invokes the Controller. The Controller either initializes the application or processes the incoming request. The Controller retrieves data from the HttpServletRequest object to determine what needs to be done. It also interacts with application data objects such as application-level beans, localized strings for internationalization, and so on.

After determining what needs to be done, the Controller instantiates and initializes one or more Web beans and ties them to the HttpServletRequest object. To satisfy this request, the beans may use one or more Web objects (which in turn use the XML API). Once all objects have been initialized, the request is redirected to the root JSP or ASP.NET page. The JSP or ASP.NET page uses the HttpServletRequest object for any other data it requires, and then directs transformed XML content to the HttpServletResponse object. It uses the associated Web beans to construct the desired content and place it appropriately in the page.

The servlet or ASP.NET file works along with the following objects:

• Controller object: This object encapsulates all the logic required to initialize the application and handle all incoming requests. All Controller classes implement the Controller interface found in the com.microstrategy.web.controller package. The Controller object is a platform-independent class that encapsulates all initialization and request processing logic. 

• RequestState object: This object is used for managing the information that each application needs to store about an incoming request. All Request State classes implement the RequestState interface found in the same package. The RequestState object is a platform-independent class that records information about the state of the incoming request.

  The RequestState interface represents the amount of information exchanged between the servlet or ASP.NET file and the corresponding AppController. It contains, for example, the Container Services instance created by the Servlet or ASP.NET file and initialized for the request. The AppController provides an implementation of the RequestStateinterface that contains all the information it needs to handle any incoming request.

  The servlet or ASP.NET file asks the AppController for a request state object instance. The AppController creates one to hold all request-specific information. The servlet or ASP.NET file initializes it with the Container Service instance that it has created.  The servlet or ASP.NET file calls processRequest, passing in this RequestState object. The servlet or ASP.NET file can then query the RequestState object to determine whether the request is complete. This is the case if binary content such as images, PDFs, and so on is returned. If the request is not yet complete, then the servlet or ASP.NET file asks the AppController for the page to redirect to and forwards the request on to that page.

  This is helpful for integrating MicroStrategy Web's request processing into an existing servlet or ASP.NET file.  

• ContainerServices object: This object is used to delineate platform dependencies. The ContainerServices object implements the ContainerServices interface. This allows portability of the application to specifics of the Web container such as Java Servlets or ASP.NET. The ContainerServices object is a platform-independent class that provides an abstract set of services found in any Web container.

With the exception of the servlet or ASP.NET file, the Controller, the ContainerServices object, and the RequestState object, the remaining objects in the presentation layer are either text files or images.

The role of the servlet or ASP.NET file-Controller during the execution of a request is described in the Page execution flow section.

MicroStrategy custom HTML tags

MicroStrategy custom HTML tags and tag helper objects are a part of this layer as well. These tags simplify the use of Web and application beans in JSP or ASP.NET files. Most of the HTML functionality provided in the pages is implemented using these custom HTML tags. These tags appear in a page with static HTML tags. This allows easier integration of MicroStrategy-provided content with other forms of custom content. These custom HTML tags make use of tag helper objects to display container components and object properties.

Implementation in J2EE and the .NET architecture

The code for custom HTML tags is almost identical in the J2EE and the .NET architecture except for the inclusion of the runat="server" attribute in ASP.NET code. Consider the following code example that is responsible for displaying a report on the Report Execution page .

JSP code:

<web:displayGuiComponent name="report_area" isContainer="true"/>

ASP.NET code:

<web:displayGuiComponentrunat="server"name="report_area" isContainer="true"/>

In the .NET architecture, a .NET bridge is used to communicate between an ASP.NET client and the Java components. The underlying layers of the MicroStrategy Web architecture are built using Java technology. Thus, a .NET bridge is provided for communication between the .NET files in the presentation layer and the Java components in the underlying layers. This ensures that you do not need to perform any additional tasks to make use of the multi-layered architecture.

The Custom HTML Tags Reference provides detailed information about these tags. It includes:  

• What attributes can be found in each element, and whether each is required or optional.  

• A description of each element along with usage.

See also

• Fundamentals of customization: Page content and layout  

• Fundamentals of customization: Modifying the template (highlights differences between J2EE and .NET environments)  

• Fundamentals of customization: Creating a New Page-section or Page-template File (highlights differences between J2EE and .NET environments)