Model View Controller (MVC) Design Mode Portlet Creating Guideline Tag Guide Using Portlet API Tags
Model View Controller (MVC) Design Mode
Portlets must be able to support multiple Internet browsers that are displayed to run on many communication devices. These browsers typically require different display markers. The smaller device's display screen is smaller, usually the display mark has more restrictions.
By implementing the Model View Controller (MVC) design mode, Portlets support multiple browsers and device types. This design contains three entities:
Model, the model data of the data source portlet to be retrieved for portlet is typically retrieved from the external data source and is formatted with the XML document when it is loaded with the Java display bean. View, used to display the output mechanism of portlet data. The display view is usually implemented as a JSP or XSLT style sheet. When using the Java Bean to implement the data model, the previous use of the data is used, and the latter is used when the format of the data is an XML document. Controller, which connects the selected view to the data and guides the operation of the portlet. The controller selects the view you want to display according to the target device or browser, and then pass the data model to the view. The view extracts specific display data to format the data for the browser, and then supplies it to the browser as part of the portal to the portal output.
For portlet development, the MVC mode has the following characteristics:
Depending on the mark supported by the client, the portlet is only responsible for calling the correct controller. The connector is responsible for accessing the content source. Typically, each content source type corresponds to a connector, for example, a connector for POP3 access, a file-based cache. The model represents the content retrieved by the connector. The model is independent of. The controller is responsible for providing appropriate tags (HTML, CHTML or WML) for content.
In the MVC structure, there is a significant separation between the data and representations, which uses a controller component to manage data (model) and the interaction between (or view). The controller understands the environment where the application is called, collects the information to be displayed from the data object, and then uses the appropriate view to apply the appropriate view for the markup language for the current device.
Portlet creation criterion
Portlet API is designed to give you the greatest flexibility to develop portlet developers to develop portlets. By applying some guidelines, you can maximize the performance of the portlet. If you develop servlet using the Servlet API, you will find that some guidelines are very similar to the criteria for creating portlets.
Examples and class variables
The most important rule is to limit the use of instances or class variables in portlets. In WebSphere Portal, only a single instance of the portlet class is exemplified. Even if different users use the same portlet on their pages, or by the same portlet object instance to generate tags. Therefore, each portlet instance will be treated as a single body. This implies that there should be no status or other information between portlet calls using an example or class variable. As a monomer, each instance variable of the portlet effectively has class variables with similar scopes, and problems may occur when accessing variables multiple times in each user's portlet context. It is best to avoid these problems by limiting the use of examples or class variables to read-only values. Otherwise, you can only sacrifice re-enter or thread security.
One exception to this rule is that you can use instance variables. Values do not change variables are safely stored in instance variables. For example, when you initialize the portlet, you can set it in the portlet. Because the configurations between different users or calls do not change, it can be stored in the instance variable. Visit Portal Server
WebSphere Portal is based on an open source called JetSpeed. However, WebSphere Portal contains many new features and features that are not available in JetSpeed, so it cannot guarantee binary compatibility between the two products and interfaces. Typically, you should not write the portlet or portal extension attempted to access the internal components of WebSphere Portal because these extensions or portlets may reduce the performance and operation of the portal.
Portlet efficiency and performance
WebSphere Portal generates different page tags for different users using the same portlet instance. There is a limit on the number of threads to perform these tasks. Realizing the portlet makes it possible to complete its work as soon as possible, so that the response time of the entire page can be optimized.
Optimizations that should be considered are:
Limit the method of synchronization or synchronized code blocks in the processing of the portlet method. Limit the use of complex string operations. This includes:
When possible, use the JSP of the view bean instead of XSL. When JSP is much more than Java objects, the XSL style sheet will cause many temporary Java object exemplary. Consider using StringBuffer to replace the temporary String object. In general, these are more efficient when processing strings and generally do not instantiate other temporary String objects. Determine if the log level is enabled before the message or tracking information is written before the log. See Message and Tracking Record Logs for more information. Limit the loop running for a long time. In JSP, reduce blank and use unconvertable JSP annotation format (<% -%>) instead of using HTML annotation format (). Minimize Java object exemplary.
General Tip of Portlet Output
One of the purposes of writing portlet tags is to provide consistent, clear and complete user interfaces. The Portal Server page is displayed using the appearance and topic defined by the portal administrator. The subject represents the entire appearance and feelings of the portal, including colors and fonts. The appearance represents the border presented around the single portlet. WebSphere Portal is installed with some predefined appearances and topics.
To integrate portlets with organization's portals or custom portals, they should generate tags of class-like style classes that call portlets, rather than using tags or properties to specify color, fonts, or other visual elements. To get more information about these style classes, see customizing your appearance and feelings.
Portlets are only allowed to provide taggers, and then these clips are assembled into a complete page by the Portlet Framework. For example, portlets are provided on the portal page on the HTML table unit (
