WebSphere Portal Portlet API

xiaoxiao2021-03-06 92

This section provides a brief description of the Portlet API.

Overview Portlet Concept Portlet API Elements Core Objects Listener Configuration Objects Miscellaneous Object Portlet Event PortletService Deployment Descriptor

Overview

Portlets are a reusable component that can be provided to web-based content, applications, and other resource access. The web page can be accessed via the portlet, web services, applications, and Cindida content supply. Companies can create their own portlets or select Portlet from third-party portlet catalog. Portlet is intended to be assembled into a larger portal page, where multiple instances of the same portlet displays different data for each user.

From a user's point of view, Portlets are a window that provides specific services or information (eg, providing calendars and news) in the portal site. From an application developer's point of view, portlet is an insertable module that is designed to run in the portlet container of the portal server.

Portlet containers provide a runtime environment that instantiates, uses, and ultimately destroyed portlets in this environment. Portlets rely on the portal infrastructure to access user profile information, participate in the window and operational events, communicate with other portlets, access remote content, find credentials, and storage persistent data. Portlet API provides standard interfaces for these features. Portlet containers are not a stand-alone container similar to a servlet container. It is implemented as a thin layer on the servlet container and reuses the functions provided by the servlet container.

IBM is working with other companies to standardize the Portlet API, so that the portlet can be used in collaboration between portal servers implementing this specification. The portlet API provided in WebSphere Portal version 4.1 is the first step towards the Standling of Portlet API. For more information on portlet specification, see

http://jcp.org/jsr/detail/168.jsp

Portlet and Servlet API

Abstract portlet classes are the core abstraction of the Portlet API. Portlet class expands the HTTPSERVLET for the Servlet API. All portlets extend this abstract class indirectly, inheriting from httpservlet, as follows:

... - javax.servlet.http.httpservlet

- org.apache.jetspeed.portlet.portlet

- Org.apache.jetspeed.portlet.portletApterapter

- com.mycompany.myApplication.myportlet

Therefore, Portlet is a special type of servlet. This type of servlet features them easily inserted and run in the portal server. Unlike servlets, portlets cannot send redirects or errors directly to browsers, forward requests, or write any marked to output stream. The portlet container depends on the J2EE architecture implemented by the WebSphere Application Server. As a result, portlet is packaged in a way similar to J2EE Web applications and deployed in a way similar to servlet.

Generally speaking, the management of portlets is more dynamic than servlet. You can apply the following updates without starting and restarting the portal server:

You can use the portal to manage the user interface to install and remove portlet applications consisting of several portlets. The portlet settings can be changed by administrator changes with appropriate access You can use the management portlet to dynamically create and delete portlets. For example, once an administrator creates a new crop, cropping the portlet can be used to create a new portlet instance. The portlet container depends on the J2EE architecture implemented by the WebSphere Application Server. As a result, the portlet is packaged in the WAR file in a way similar to the J2EE web application and deployed in a way similar to servlet. Similar to other servlets, use the servlet deployment descriptor (web.xml) to define the portlet to the application server. This file defines the class file and read-only initialization parameters of the portlet.

The figure below shows the portlet after deploying its WAR file. Each portlet for deployment on the portal server is created on the application server, or a portlet class instance is created on the application server.

The initialization parameter is set by the portlet developer and can be read by the portletConfig object. The Servlet deployment descriptor can contain multiple web applications, each of which is defined by the element. In addition, each servlet definition can point to the same portlet class file, which can create different portletconfig objects for each portlet class instance using different initialization parameters. To get more information, see the web application deployment descriptor.

Portlet deployment descriptor

In addition to the servlet descriptor, Portlet must also provide portlet.xml to define the ability of portlets for portal servers. This information contains configuration parameters specific to specific portlets or portlet applications, as well as general information provided by all portlets (such as portlets supported by portlet). The portal server uses this information to serve the portlet. For example, if the portlet registers its support in the portlet deployment descriptor, the portal server will present the icon to allow the user to call the help and editing page of the portlet.

The following is a sample portlet deployment descriptor with minimal tag.

my portlet application

my portlet

my concrete portlet application

my concrete portlet

my portlet </ title> </ logage> </ concrete-portlet> </ concrete-portlet-app> </ portlet-app-def> To get more information that contains a description of each tag, see Deploying a descriptor. Portlet concept The following image shows that the portlet is placed on the page to place portlets and users access portlets. Note that the first two steps involve the use of persistent data, but for the third step, the data is only available during the session duration. The portal administrator uses the management interface to deploy a new portlet application WAR file or install a copy of the portlet. Both operations create a concrete portlet, which is a portlet that is parameterized by a single portletSettings object. Each portlet may have multiple specific portlets. PortletSettings is a read / write access and is lasting. PortletSettings contains configuration parameters defined in the portlet deployment descriptor. Using specific portlets can run instances of different configurations of many portlets without creating additional portlet class instances. Many specific portlets can be created and destroyed during the life cycle of a single portlet. None explicitly represents the object of the specific portlet. The same specific portlet can be shared between many users. Users or administrators put portlets on the page. This creates a concrete portlet instance, which is a specific portlet that is parameterized by a single portletdata object. Each specific portlet may have a plurality of specific portlet instances. PortletData stores lasting information for portlets added to the page. For example, users can edit stock quotation portlets and save a list of stock symbols for company tracking. The scope of the portletdata depends on the scope of the page where the specific portlet is located. If the administrator places the specific portlet to the group page, the portletdata object contains data stored for the user. This will remain in the user group to view access to the page. However, if the user has an editing access to the portlet on the group page, create a new specific portlet instance for each user of the portlet. In this case, PortletData contains data for each user of the portlet. If the specific portlet is placed on the user's page, the portletdata contains the data of that user. When the user accesses a page containing the portlet, a user portlet instance is created. When the user logs in to the portal, the portal server creates a portletSession for each user's portlet. PortletSession parameterized concrete portlet example is called a user portlet instance. Each specific portlet instance may have multiple user portlet instances. The user portlet instance is a specific portlet instance for a single portletSession parameterized. Each specific portlet instance may have multiple user portlet instances. PortletSession storage is instantaneous information related to a single use portlet. Portlet application The Portlet application provides a method of encapsulating a portlet that shares the same context. The context contains all resources, such as images, attribute files, and classes. All portlets must be encapsulated as part of the portlet application. Specific portlet application The specific portlet application is a portlet application that is parameterized by a single portletApplicationSettings object. For each portlet application, there may be multiple specific portlet applications. PortletApplicationSettings is a read / write access, and is lasting. None explicitly represents the object of the specific portlet application. The specific portlet application contains at least a specific portlet from the portlet application, but no need to contain them. Portlet applications do not provide code, but form a logical group for portlets. In addition to this more logical revenue, the portlet of the same portlet application can also exchange messages. Portlet Portlets allow portlets to display different user interfaces, depending on the tasks required for the portlet. Portlets have four display modes that are defined in the portlet deployment descriptor. The portlet container maintains the portlet mode in the portlet.mode object. Provides the following ways through the Portlet API: view When the portlet is initially built on the portal page, it is displayed in its view mode. This is the normal operation of the portlet. help If this method is supported by portlet, the portlet provides the user with a help page to get more information about portlets. edit If the way is supported by the portlet, the portlet provides the user to customize the portlet by itself. For example, Portlets provide a page to specify its location to obtain local weather and event information. Users must log in to the portal to access the edit method. Configure If the way is supported by portlet, the portlet provides a page for the portal administrator to configure portlets to the user or user group. Portlet API provides a way to determine the current or previous way. All portlets must support view mode. Portlet containers provide users to interact with portlets on their portal page. Click one of the controls to change the way or status of the portlet. The portlet is displayed in the blank title bar in the view mode. This title bar shows editing, help, minimizing, and maximizing icons. Click the pencil to make a portlet in edit. Portlet status The portlet state allows the user to change how the portlet window is displayed in the portal. In the browser, the user calls these status with icons in the title bar, which is the same as the operation method of the Windows application. The portlet status is maintained in the portletWindow.State object with the Boolean value. When you first build a portlet on the portal page, it is displayed in normal status - arranged with other portlets on the page. When maximizing portlets, it is displayed as the entire body of the portal, replacing the view of the other portal. Minimize when minimizing portlets, only the portlet title bar on the portal page is displayed. Portlet API provides a way to the portlet to determine the current state. Portlet API elements This section describes the basic interfaces, classes, and methods of the Portlet API. The following figure shows the structural diagrams of many common objects in the portlet API. Portlet extension by portletadapter Service () 1 portletResponse Createuri () portleturi service () 1 portletRequest GetPortletSettings () portletsettings GetletApplicationSettings PortletApplicationSettings getMode () portlet.mode getclient () Client getdata () portletdata getwindow () portletwindow GetWindowState () portletwindow.state getPortletSession () portletsession getUser () user getPortletconfig () portletconfig getContext () PortletContext GetLog () PortletLog GetService () PortletService 1 PortletRequest and PortletResponse are passed by the Helper method of PortletAptaPter (such as Doview ()). Portlet class Abstract portlet classes are the core abstraction of the Portlet API. All portlet extends the abstraction class by extending one of the subclasses of abstract classes (eg, portletadapter), which provides methods that help developers. Portlet life cycle Portlet container calls the following method 2 of the abstract portlet during the lifecycle of the portlet: init () After the portal is initialized, that is, the portlet is constructed and then initialized using the init () method. The portal always instantizes a single instance of the portlet, and this instance is shared between all users, exactly the same as the servlet shared between all users of the application server. INITCONCRETE () After constructing the portlet, the specific portlet before the first visit to the portlet. PortletSettings instantiates. Service () When you ask portlets to present its content, the portal calls the service () method. The service () method is usually called multiple times during the life cycle of the portlet. For each portlet on the page, it is not called the service () method in the order of the guaranteed order, and may even call the service () method in different order for each request. DestroyConcrete () Use the DestroyConcrete () method to remove the specific portlet from the service. This may happen when an administrator deletes a specific portlet during the running time of the portal server. DESTROY () When the portal is about to terminate, the portlet will cancel the service and then use the destroy () method to destroy. Finally, the portlet is collected and ended as useless information. 2 This represents the method that is called on all portlets. Call other methods for the portlet of the listener. See the listener lifecycle for more information. getLastModified () In addition to the method called during the portlet lifecycle, the portlet container calls the getLastModified () method for each portlet request. This method returns the last time (in millisecond meter) of the change of the portlet content, this time is UTC in the current time and midnight on January 1, 1970 (java.lang.system.currentTimeMillis ()) or is negative (if time unknown). To get more information about when using getLastModified (), see Refresh the portlet cache. Helper class Portlets are not directly extending the abstract portlet class, but extended portletadapter or any other helper class to extend the portlet. Extend one of these classes to help protect portlets from abstract portlet class changes. In addition, it saves all methods of all portlet interfaces, even if portlet does not need to use them all. With the portletadapter class, simply override the truly needed approach. In its service () method, the portletadapter class calls the method corresponding to the portlet. Extending the portlets of this class overwrites Doview (), doedit () and dohelp () methods without having to test the method or write a specific service () method. In addition, portletadapter enables portlets to store variables in specific portlets. Specific portlet variables are different from Java instance variables because they are bound to the portlet class or a non-specific portlet. PortletApaater provides setvariable (), getVariable (), and RemoveVariable () methods and specific portlet variables. Core object The following objects are the most commonly used in portlet: PortletRequest PortletResponse PortletSession Each of these objects is an extension of its copy in the servlet API. PortletRequest PortletRequest objects are passed to portlets via login (), beginPage (), and provide specific data for portlets and allowing it to access further important information listed below. Attributes The attribute is the name / value pair related to the request. Attributes can only be used for the scope of the request. During a request, the portlet can get, set, and remove properties. parameter The parameter is a name / value pair sent by the client, which is part of the request in the URI query string. Usually the parameter is published from the form. The parameter is used for a scope of a particular request. Portlets can get the parameters from request acquisition but cannot set. Client computer Client objects encapsulates information about the user agent on a particular request. From Client's information contains the tag types supported by the manufacturer or client of the user agent. Use the getClient () method from PortletRequest extract CLIENT. Can Client Get the following information: User agent Portlets can get the string sent by the user agent to identify itself to the portal. Tag name Portlets can get a string that indicates the markup language supported by the client, such as "WML". MIME type Portlets get a string that indicates the MIME type supported by the client (eg TEXT / VND.WAP.WML). If the portlet supports multiple device types, it will get the tag name instead of the MIME type. The following table shows the MIME type and their corresponding tag types. Retrieve the MIME type does not distinguish between HTML and ChTML tags. MIME Type Tag Type Text / HtmlHtmlText / VND.Wap.WmlWmlText / HTMLCHTML ability The Capability object is more detailed than the tag type (what is the level of the client supports), such as HTML, JavaScript, or WML table. User data PortletData object represents data for the specific portlet instance saved to lasting storage. For example, users can set up a portlet email application to check new messages every 30 minutes. in The preferences are stored in the PortletData object. Session PortletSession represents instantaneous data of a specific user of multiple requests. With the request comparison, the request does not reserve the data after the request is complete, and the session property can be more than one request record / saved. Portlet settings PortletSettings object represents the configuration of the specific portlet saved to lasting storage. For example, an administrator can set which host and port should be connected to getting real-time data. in The PortletSettings object stores this preference for the specific portlet. the way Portlet.Mode provides the current or previous portlet. PortletWindow PortletWindow object represents the current portlet window status. Portlets can access the object to determine that the current portlet is to maximize, minimize or its normal view is rendered. ModeModifier Before presenting portlets, you can use this object to set the portlet to its current, previous or request. For example, a portlet in an edit mode can handle user operations and allow portlets to return to edit methods to wait for more inputs before returning a view mode. PortletResponse The response object package returns from the server to the client information. PortletResponse passes the BeginPage (), EndPage () and Service () methods and can be used by portlets to return to the portlet output by using Java PrintWriter. Responding to the method of creating a portleturi object or restricting the portlet tag using the namespace of the portlet. Use one of the following methods to create portleturi: Createuri () Create a call mode for the current way portlet Portleturi object Createuri (portletWindow.State State) Create a portlet that points to the call mode for the current mode and a given portlet window status Portleturi object. Createreturnuri () create Portleturi pointing to the caller of portlet. For example, CreateReturnuri () can be used to create a postback button in the edit mode. Each portlet runs in its own unique namespace. Portlets use the EncodeNameSpace () method to bring the property to the portlet output to avoid names with other portlet conflicts. The property contains parameter names, global variables, or JavaScript function names. Portleturi The portleturi object contains the URI to the portlet instance and can be further expanded by adding a specific portlet or by additional operations. Operation is an activity of a particular portlet, but before calling the portlet service () method, it needs to be executed in the result of the inbound request. For example, when the user enters the data in the portlet editing method and click the Save button, the portlet needs to process the published data before generating the next tag. This can be implemented by adding the save operation to the URI of the representative save button. The complete URI can be converted to a string that can be embedded in the tag. PortletSession PortletSession Save the specific user data of the specific portlet instance of the portlet, create a portlet user instance. The specific portlet instances differ only in the data stored in their portletdata. The difference between the portlet user instance is only in instantaneous data stored in their portletations. Any persistent data must be stored using portletdata. Information stored in the instance variable of portlet is shared between all specific portlet instances (or even all specific portlets) through read and write access. Make sure that the instance properties are not used for user-specific data. On the other hand, you must carefully treat the portlet to a session, especially if the portlet runs in a cluster environment, the environment is where the shared database serialization session. Anything stored in a session must also serialize. Similar to httpsession, PortletSession is not available on anonymous page. During login, the portlets will be automatically created for each portlet on the page. To get portletSession, you must use the getSession () method (available in portletRequest). This method returns the current session, or if there is no current session, and given the parameter "CREAT" is True, it will create one and return it. Listener Portlet API provides a listener that adds more features to portlets. To enable the functions of the listener, the portlet must implement one of the following interfaces. PortletSessionListener PortletpageListener PortletTitleListener PortletSettingSttributesListener PortletApplicationSettingSattributeSlistener PortletSessionListener In addition to the specific portlet instance of the portlet that appears on the page, the portlet may have a finer granularity. PortletSessionListener enables portlets to identify the lifecycle of the user portlet instance: Login () After the user logs in to the portal, each portlet creates a session for the user. The specific portlet example and a combination of a user session creates a user portlet instance. The launch of the user instance is sent by the portal to call the login () method on the portlet. This method allows the portlet to initialize the user's PORLET session instance, for example, to store properties in a session. Logout () When the user ends a session with the portal, the portal server calls the logout () method to notify the portlet user's session instance is terminating. The portlet will then clear any resources of the portlet user instance. Portletpagelistener Portlets are not used to write control or consciousness of the output order of all portlets on the page. PortletPageListener allows the portlet to start and end insert tags on the page. BeGinPage () Call the BeginPage () method for each portlet () method that resides on the page before the start of each page and any service () method of any portlet on the page. Similar to the service () method, each portlet on the page is not called the beGinPage () method in the promised sequence surface, and may even call the beGinPage () method for each request. This method allows the portlet to output JavaScript visible to all portlets, or even set cookies or headers. After EndPage () After the end of each page and the service () method of all portlets on the page, the endpage () method is called for each portlet on the page. Similar to the service () method, not the endpage () method is called in the order of the guaranteed order, and even for each request, the endpage () method is called in different order. For example, portlets can insert a JavaScript that needs to occur after all other elements of the page are written to the end of the page. Listener life cycle When implementing portletSessionListener and portletpagelistener, the following methods are called on the portlet during the life cycle. Init () non-specific portlets and portletconfig together initialize. INITCONCRETE () specific portlets and portletsettings are initialized together. Login () User Portlet instance is initialized together with PortletSession. BeginPage () portlet may start an output every page at each page of each request. Service () portlet may present an output in each requested portlet window. Endpage () portlet may present an output at each page of each request. Logout () destroys the user portlet instance. DestroyConcrete () destroys specific portlets. Destroy () destroys non-specific portlets. PortlettittleListener As shown in the title bar, the portlettitlelistener interface is used to allow a condition (for example, device type for accessing the portal) or user input (for example, the user who sets up on the edit page) to change the portlet title. If a listener is not implemented, the portlet is displayed on the <title> element (<Language> below) of the Portlet deployment descriptor. PortletSettingSattributeSlistener This interface listens to the changes to the portletsettings attribute, similar to the Administrator to configure the specific portlet. PortletApplicationSettingSattributeSlistener This interface listens to changes to the portletApplicationSettings attribute, similar to the Administrator to configure the specific portlet application. Configuration object Portlets use the following objects to retrieve and store data, depending on how to use data: PortletConfig PortletSettings PortletApplicationSettings Portletdata PortletConfig PortletConfig Configure its initialization to provide non-specific portlets. Configure information with the portlet class. This information takes effect for each specific portlet from portlet. The PORTLE configuration first reads the descriptor from its Servlet deployment. This information is defined by the portlet developer. The configuration is read-only, and the portlet cannot be changed. Pass PortletConfig to the portlet in an abstract portlet's init () method and use GetInitParameters () to access specific portlet configuration parameters. The portletconfig parameter is the name / value pair available throughout the non-specific portlet lifecycle. The parameters of non-specific portlet are defined by the <init-param> tag in the Servlet deployment descriptor. PortletSettings PortletSettings objects provide its dynamic configuration to the specific portlet. Configure information that has a specific portlet. This information is valid for each of the specific portlets of the specific portlet. The specific portlet configuration is first read from the portlet deployment descriptor. This configuration is read-only and only when the portlet can be written by the portlet in the configuration mode. This information is usually maintained by the portal administrator and may be changed when the portal server is running. The portlet can get, set, and remove properties during a request. To submit changes, you must call the Store () method. PortletSettings objects can be accessed by the getPortletSettings () method available for PortletRequest. Typically, it is used to use GetAttribute () to access specific portlet configuration parameters. The attribute is the name / value pair of the entire specific portlet lifecycle. The specific portlet attribute is defined by the <config-param> tag in the portlet deployment descriptor. PortletApplicationSettings PortletApplicationSettings object provides its dynamic configuration to the specific portlet application. Configure information about portlet applications that have all specific portlet shares included in the application. The specific portlet application is first read from the portlet deployment descriptor. This configuration is read-only and only when the portlet can be written by the portlet in the configuration mode. This information is usually maintained by the portal administrator and may be changed when the portal server is running. During a request, the portlet in the application can get, set, and remove properties. To submit changes, you must call the Store () method. PortletApplicationSettings can be accessed by the getApplicationSettings () method available by the PortletSettings object. It is used to use GetAttribute () to access specific portlet configuration parameters. The attribute is the name / value pair of the entire specific portlet application lifecycle. The specific portlet application properties are defined by the <context-param> tag in the portlet deployment descriptor. Portletdata PortletData has data for specific portlet instances. Each of the page has a specific portlet instance. PortletData contains persistent information about the specific portlet instance, while portletsSession only contains instantaneous data of the user portlet instance. There is a specific portlet instance on each of the portlets on the page. The page can have a single user (personal home page) or a single user group (group page). PortletData contains specific user data on the Personal Home page, which contains specific group data on the group page. The portletdata object stores the property as name / value pair. The portlet can get, set, and remove properties during a request. To submit changes, you must call the Store () method. The data is read-only and only when the portlet can be written by the portlet in editing mode. Miscellaneous object The following objects are used by portlets: PortletContext PortletLog PortletWindow User PortletContext The portletcontext interface defines the portlet view of each portlet container that runs in. PortletContext also allows portlet to access its available resources. For example, using context, portlets can access the portlet log, accessing the portlet to all portlets in the application, which is a common context parameter, get the URL reference to the resource, or access the portlet service. A very important detailed information about PortletContext is described below. INITPARAMETERS The parameter is a name / value pair available in all portlets in the web application. These definitions under the <context-param> element in the Web Deployment Descriptor. For example, if a set of portlet sharing includes a context parameter named "Webmaster" named "Webmaster", each portlet may get that value and provide "mailto" link in their help. Attributes The property is a name / value pair available in all portlets in the web application. Portlets can get, set, and remove properties. The context of the attribute is stored on a single machine and is not distributed in the cluster. Localized text The GetText () method is portlet to access the resource bundle in a given language environment. Resource by PortletContext, portlet can be loaded or included in the portlet application scope. The available methods include include () and getResourceceAsStream (). Include () method is usually used to call JSP for the output. Message delivery Communication between portlets and shared data by message delivery, or sending notifications may be possible. Send messages by using the send () method. For more information, see Portlet message delivery Portlet service PortletService object allows portlets to be insertable through dynamic discovery. Log PortletLog objects provide portlet logging information, warning, or error messages. The log is maintained by the portlet container. Enable or not enable the log log is determined by the portlet container. For more information, see Message and tracking logs. This object can also be obtained from getPortletLog () from the PortletApter class. PortletWindow PortletWindow object represents the window of the package portlet. For example, on an HTML page, the Portlet window can usually be rendered as a table unit. The portlet window can send events on its various window controls, such as the user clicks minimized or off. Portlets can ask the window in turn on its current state. For example, the portlet may exhibit its content differently, depending on whether it is maximized. PortletWindow is available using the getWindow () method of the portletRequest object. User The USER interface contains methods accessing user properties such as a full name of the user or username. Portlet event The portlet event contains information about events that may require a response. For example, an operating event will be generated when a user clicks on a link or button. To receive the notification of the event, the portlet must implement an event listener in the portlet class. Operating Event: Generate when the HTTP request is received by receiving the portlet container associated with the operation (such as when the user clicks on the link). Message Event: Generate when another portlet in the portlet application sends a message. Window event: Generate when the user changes the status of the portlet window. Before generating new content requirements (and therefore portlet), the Portlet container sends all events to their respective event listeners. If the listener finds another event when the listener is processed, the event will be queued by the portlet container and transmitted at the moment of the portlet container. It is guaranteed to send it and happen before the content production phase. Once the content is started, there will be no further events will be sent. For example, a message cannot be sent from BeGinPage (), service () and endpage (). The result message event will not be sent and substantially discarded. Implement the event listener directly in the portlet class. The listener can access portletRequest from events and responses using the portletRequest or PortletSession property. Operating event When receiving the HTTP request associated with portletivity, send an ActionEvent to Portlet. To receive an operation event, the portlet class must implement an ActionListener interface and an object with the portletAction type. PortletAction links to the URI that uses the portleturi class and its addAction () method. ActionEvent can be used to get associated portletAction and portletRequest. Typically, portletAction is linked to the HTTP reference or button in the HTML form. The ActionEvent that is then click the ActionEvent to transmit the associated portletAction back to the portlet, which can act in sequentially different processing paths based on user operation. Portlet operations can transmit any information. However, it should not store requests, response, or session objects. This information is part of the operational event and will be sent to the registered listener. The following shows how JSP uses URIs, including portletAction. When the user clicks the "Add" button, a new HTTP request is sent to the operation URL of the form. <Form method = 'post' action = '<% = EditBean.getadduri ()%>>>>> Name: <input name = 'bookmark.name'> URL: <input name = 'bookmark.URL'> <Input Type = 'Submit' Name = 'AddButton' Value = 'Add'> </ Form> The following shows how ActionListener distinguishes operation. Public void actionPerformed (ActionEvent Event) { PortletAction_Action = event.getAction (); IF (_action instanceof defaultletlet) { ... DefaultPortletAction Action = (default) _action; if (action.getname (). Equals ("add")) { ... See Using Persistence Code Example, showing how to add an action to the portlet and create an actionListener. DefaultPortletAction Portlet API is available to the defaultportletAction class default parameters, and the portlet can use it to implement the portletAction object. You can create portletAction based on defaultletAction, or use it to implement your own portletAction. The following shows how to create defaultportletAction: DEFAULTPORTLETACTION AddAction = New DefaultPortletAction ("Add"); The following shows how to put the portletAction to the URI: Portleturi Adduri = response.createuri (); DEFAULTPORTLETACTION AddAction = New DefaultPortletAction ("Add"); Adduri.Addaction (AddAction); Window event Whenever the user clicks on one of the control buttons that change the window status, if maximizes, minimizes, or recovers, WindowEvent is sent by the portlet container. For example, when the user maximizes the portlet displayed in its normal status, you can display more information using WindowEvent. To receive a window event, you must implement the WindowListener interface in the portlet class. The Portlet API provides a WindowAdapter class that implements an empty way for WindowListener. By expanding Windowadapter, portlet developers only need to implement the callback methods required for portlets. Without Windowadapter, all callback methods must be implemented, even if the method is empty. See refreshing the portlet cache for examples of WindowListener. Message event If the recipient portlet is a member of the same portlet application, and the message event can be sent from a portlet to other portlets as a portlet being sent. In addition, DEFAULTPORTLETMESSAGE can span all portlets of the portlet application boundary and sent to the page. MessageEvent can be sent to other portlets only when the portlet is in the event processing cycle of the portlet container, otherwise an exception will be thrown. There are two different types of messages: Single Addressing message: Send a message to a specific portlet by specifying the portlet name on the Send () method. Broadcast News: Send messages on all portlets on the page. When a portlet is changed to another portlet, the message event is useful. You must implement an object with a portletMessage type, which is passed through MessageEvent. The portlet of the received message must implement the MessageListener interface and objects with portletMessage types. To get an example of how portlet can send a message in mutual messages, see the portlet message. PortletService In order for the portlet to use the insertable service by dynamic discovery, the portletspacement interface is provided. PortletService is accessible from the portletContext.getService () method to find the appropriate factory to get the service, create a service and return it to the portlet. Various services can be implemented through different suppliers, such as SearchService, LocationService, ContentAccessService, or MailService. Portlet API provides ContentAccessService. Create your own portlet service Writing the portlet service contains four steps: Define the factory registration service that implements the service written service If you want to implement your service with your existing interface, step 1 is not required. If you want to reuse the existing service factories, this situation is also applicable to step 3. Define interface Defining the portlet service interface requires the same strict consideration as defining any public API interface. The portlet service interface must only extends the PortletService interface in the org.apache.compate package, which is similar to the logo, which is similar to the Java API's Serializable interface. Below is a HelloWorldService sample interface. Package my.portlet.service; Import org.apache.jetspeed.portlet.service. *; Public Interface HelloWorldService Extends PortletService { // my service's method Public String Sayit (); } Write service implementation The service implementation must implement the PortletServiceProvider interface of the org.apache.jetspeed.portlet.Service.SPI package, which in addition to the service interface, you can use the portlet service lifecycle method. For example, the portletServiceConfig parameter of the init method allows you to access the service configuration (see the registration service to get more information). Package my.portlet.service.Impl; Import org.apache.jetspeed.portlet.service. *; Import org.apache.comjetspeed.portlet.service.spi. *; Public Class HelloWorldServiceImpl Implements HelloWorldService, PortletServiceProvider { Private string it = null; Public void destroy () { // do nothing - no resources in us } Public void init (portletServiceConfig config) { IT = config.getinitParameter ("my_message"); IF (IT == NULL) IT = "Hello World !!!"; } Public String Sayit () { Return IT; } } Writing the factory Usually, you don't have to write your own factory because there are two class factories that are provided with the portal server in the org.apache.jetspeed.portLetcontainer.Service package. PortletServenticeDefaultFactory always returns a new instance of a given service, PortletServiceCacheFactory always returns the same instance as a given service. You can use one of these plants instead of as a single implementation. The factory must implement the portletServiceFactory interface of the org.apache.jetspeed.portlet.Service.SPI package. Below is a factory class of HelloWorldService: Package my.portlet.service.Factory; Import org.apache.jetspeed.portlet.service. *; Import org.apache.comjetspeed.portlet.service.spi. *; Public Class HelloWorldServiceFactory Implements PortletServiceFactory { PortletServiceProvider PSP = NULL; Public PortletService CreatePortletService (Class Service, Properties ServiceProperties, ServletConfig ServletConfig Throws portletServiceunavailableException { IF (psp! = null) { Return PSP; } Else { PSP = New HelloWorldServiceImpl (); PSP.INIT (New PortletServiceConfigIMPL) Service, ServiceProperties, servletConfig); Return PSP; } } } Registration service To insert a service into the portal server, the corresponding class file must be copied to WAS_ROOT / LIB / APP. Then you must change the portletServices.properties file in the WP_ROOT / App / WPS.EAR / WPS.WAR / web-INF / conf directory: Provide configuration parameters for implementation as the corresponding service type to implement registration factories for implementation # PortletServices.properties Org.apache.jetspeed.port.Service.default.Factory = Org.apache.jetspeed.PortletContainer.Service.portletServiceDefaultFactory ... My.portlet.service.helloworldService = my.portlet.service.impl.HelloworldServiceImpl My.portlet.Service.Impl.helloWorldServiceImpl.Factory = my.portlet.service.factory.HelloWorldServiceFactory My.portlet.service.impl.HelloworldServiceImpl.my_message = Hello World (Properties)! ... Content access service Various services can be implemented through different vendors (eg, SearchService or MailService). Usually when you must use a proxy, the Portlet API provides ContentAccessService from the internal network. This service allows portlets to access content from JSP and Servlet from a remote Web site or portal web application. (Instead, the portletcontext.include method can only contain local JSPs of the portlet application: ContentAccessService Import org.apache.jetspeed.portlet.service.ContentAccessService; . . . ContentAccessService Service = PortletContext.getService (ContentAccessService.Class); // Get a URL URL URL = Service.getURL ("http://www.ibm.com", request, response // incrude the content of a web site inTo the portlet Service.include ("http://www.ibm.com", request, response // include a jsp or servlet belonging to the Portal Web Application Service.include ("/ Templates / Weather.jsp", Request, Response); . . . Tip: Direct access to the shortcomings of the special network resource is that the content is simply taken and written to the output of the portlet. This means that all links related to other pages or images will be disconnected. These issues can be resolved by analyzing content or using some enhanced browser portlets. ContentAccessService also opens an SSL connection with a remote application. In addition to specifying the security protocol (HTTPS) for the include () method in the URL, the code is the same as the unacceptable code (see Example: ContentAccessService). However, the portal must be configured as described in the portal configuration to support SSL, see PortletServices.properties. Deployment descriptor The WAR file of the portlet application must contain two descriptor documents: web application deployment descriptor and portlet deployment descriptor. The servlet definition in the web application deployment descriptor must have the same order as the portlet definition in the portlet deployment descriptor. Web application deployment descriptor Like other servlets that comply with J2EE models, portlets and web applications deploy a descriptor (Web.xml) together is packaged as a WAR or EAR file. This descriptor defines each portlet to become a servlet, contains the unique identifier of each portlet, portlet class, and initialization parameters. To get more information about the WEB application deployment descriptor, see the Java Servlet specification version 2.3. Portlet deployment descriptor The DTD of the portlet deployment descriptor is located in WP_ROOT / App / Web / DTD / Portlet_1.1.dtd. The descriptor of a single WAR file is saved as file portlet.xml, and must begin with the following XML and DOCTYPE statements: <? XML Version = "1.0"?> <! Doctype portlet-app-def public "- // ibm // DTD portlet application 1.1 // en" "portlet_1.1.dtd"> The structure of the portlet.xml is displayed below. Click any tag to get more information about it. <? XML Version = "1.0" encoding = "UTF-8"?> <! Doctype portlet-app-def public "- // ibm // DTD portlet application 1.1 // en" "portlet_1.1.dtd"> <portlet-app-def> <portlet-app uid = "uid"> <portlet-app-name> portlet_Application_name </ portlet-app-name> <portlet ID = "portlet_id" href = "Web-inf / web.xml # servlet_id" Major-Version = "Version" minor-version = "version"> <portlet-name> portlet_name </ portlet-name> <cache> <expires> Number </ expires> <Shared> Yes | NO </ share> </ cache> <allows> <maximized /> <minimized /> </ allows> <supports> <markup name = "html | wml | chtml"> <view output = "fragment" /> <Edit Output = "fragment" /> <help output = "fragment" /> <configure output = "fragment" /> </ Markup> </ supports> </ portlet> </ portlet-app> <contRete-portlet-app uid = "uid"> <portlet-app-name> portlet_Application_name </ portlet-app-name> <context-param> <param-name> name </ param-name> <param-value> Value </ param-value> </ concrete-param> <contRete-portlet href = "# portlet_id"> <portlet-name> portlet_name </ portlet-name> <default-local> locale </ default-local> <logage local = "local"> <title> Title </ Title> <Title-Short> Short Title </ Title-Short> <Description> Description </ description> <keywords> Keyword1, keyword2 </ keywords> </ logage> <config-param> <param-name> name </ param-name> <param-value> Value </ param-value> </ config-param> </ concrete-portlet> </ concrete-portlet-app> </ portlet-app-def> <portlet-app-def> Required. A top element containing information about the portlet application. This element exactly includes a <portlet-app> element and one or more <contRete-portlet-app> elements. <portlet-app uid = "uid"> Required. Contains information about portlet applications. The UID of each portlet must be unique in the portlet application. See Portlet UID Code. The following is the child elements of <portlet-app>. <portlet-app-name> Need and only one need. Indicates the name of the portlet application. <portlet ID = "id" href = "href" major-version = "version" minor-version = "version"> At least one is needed. Contains elements that describe portlets belonging to this portlet application. ID and HREF is required. In the portlet application, the id must be unique. HREF attribute points to the logo of servlet, such as Web-inf / web.xml # servlet_id shown. Use version properties to maintain and support multiple portlet versions of portlets. Here is the child element of <portlet>: <portlet-name> Required. The name of the portlet. This name does not appear on the portal page. <cache> Optional. Describe how the portal handles the output of the cache the portlet. Here is the child element of <cache>: <expires> If <cache> is specified, it is required. Indicates the number of seconds required to refresh the portlet output. 0 Indicates that the portlet output is always expired. Each request causes the portlet to refresh its output. This is the default setting if <cache> does not exist. Any number greater than 0 indicates the number of seconds required for cache portlet output. After the cache time expires, the subsequent request causes the portlet to refresh its output. -1 indicates that the portlet output is never expired. After the portlet is initialized, it is no longer refreshed. <shared> If <cache> is specified, it is required. Indicates whether the portlet output is cached and shared with all users or for each personal user. Specify "YES" or "NO". <allows> Optional. Indicates the status of portlet support. In a portlet, you can specify <allows> elements must not exceed one. These settings only affect the portlet presentation in the HTML. Here is the sub-elements of <allows>: <maximized /> Optional. Indicates if the portlet is maximized. When maximizing, the portlet replaces all other portlets on the portal page page. If this element exists, the maximum button is rendered on the title bar of the portlet. <minimized /> Optional. Indicates if the portlet can minimize. When minimized, the portlet is only presented as a title bar. If this element exists, the minimization button is presented on the title bar of the portlet. <supports> Required. Indicates how portlet supports and tag types. All portlets must support view mode. Other ways must only be provided when portlets support other ways. Here is the child element of <supports>: <markup name = "name"> At least one is needed. Indicates the type of tags supported by this portlet. Name is one of the following values: HTML WML Chtml indicates a <Markup> tag for each tag type, for example: <markup name = "html"> ... </ Markup> <markup name = "wml"> ... </ Markup> Here is the child element of <markup>: <view /> Required. This portlet supports the view. <edit /> Optional. This portlet supports editing. This element is optional. If you support editing, the portlet must provide a method for user call to customize portlets to use them. <Help /> Optional. Indicates this portlet support help. This element is optional. If you support help, the portlet must provide a help output, which will display the location of the portlet when the user clicks the help icon. <configure /> Optional. Indicates the configuration of this portlet support. This element is optional. <contRete-portlet-app uid = "uid"> At least one is needed. Contains information about the specific portlet application. The following is the child elements of <concrete-portlet-app>. <portlet-app-name> Need and only one need. Indicates the name of the portlet application. <context-param> Optional. The specific portlet application accepts a pair of <param-name> and <param-value> elements as input parameters. A specific portlet application accepts any number of context parameters. When an administrator configures a specific portlet application, you can change the context parameter. Use XML annotations to provide help information, indicating which values that the portlet application can accept. The only configuration setting for the specific portlet application consists of its PortletApplicationSettings. <contRete-portlet ID = "ID" href = "href"> at least one. Contains an element that describes the specific portlets belonging to this specific portlet application. ID and HREF is required. In the portlet application, the id must be unique. HREF attribute points to the logo of the portlet, such as #port shown in #portlet_id. Here is the child element of <concrete-portlet>: <portlet-name> Required. The name of the portlet. This name does not appear on the portal page. <default-local> Required. Indicates that if you are unable to determine the language environment you want to use when the client language environment is not determined. <logage local = "local"> At least one is needed. Each supported for portlet Locale provides a <language> element. Locale can be one of the following values: EN English de German fr French ES Spanish JA Japanese Ko Korean ZH Simplified Chinese EN_TW Traditional Chinese PT_BR Brazilian Portuguese IT Italian He Hebrews CS Czech Czechlovak Tr Turkish PL Polish Below is the child element of <Language>: <Title> Each <language> element requires only one <title>. Please specify one for a given Locale translated portlet title. <title-short> Optional. Short title indicating translation. <description> Optional. Provide a translation description for portlets. <Keywords> Optional. Provide any translation related to portlet. <config-param> This portlet can be accepted as a pair of <param-name> and <param-value> elements of the input parameters. Portlets accept any quantity configuration parameters. When an administrator configures the specific portlet, you can change the configuration parameters. Use XML annotations to provide help information, indicating which values that the portlet application can accept. The only configuration setting of the specific portlet consists of it. PortletSettings. Link servlet, portlet, and concrete portlet The definition of the servlet in web.xml must have the same order as the definition of portlet.xml. The servlet identity must be referenced by the portlet deployment descriptor using the <portlet> tag. As shown in the following table, the HREF attribute indicates the path to the WAR file in the WAR file as an anchor in an anchor. Portlet.xmlweb.xml <portlet ID = "portlet_1" HREF = "Web-INF / Web.xml # servlet_1"> <portlet-name> mail </ portlet-name> ... </ portlet> <servlet ID = "servlet_1"> <servlet-name> mailportlet </ servlet-name> ... </ servlet> <portlet ID = "portlet_2" href = "Web-INF / Web.xml # servlet_2"> <portlet-name> Calendar </ portlet-name> ... </ portlet> <servlet ID = "servlet_2"> <servlet-name> CalendarportLet </ servlet-name> ... </ servlet> Each specific portlet definition uses the HREF attribute of the <concrete-portlet> indicating his parent portlet. As shown in the following table, the HREF attribute indicates that the portlet identifies as an anchor. Portlet mark specific portlet mark <portlet ID = "portlet_1" HREF = "Web-INF / Web.xml # servlet_1"> <portlet-name> mail </ portlet-name> ... </ portlet> <contRete-portlet href = "# portlet_1"> <portlet-name> mail box </ portlet-name> ... </ concrete-portlet> <portlet ID = "portlet_2" href = "Web-INF / Web.xml # servlet_2"> <portlet-name> Calendar </ portlet-name> ... </ portlet> <contRete-portlet href = "# portlet_2"> <portlet-name> group calendar </ portlet-name> ... </ concrete-portlet> Guidelines for portlet applications UID The UID of the portlet application and the specific portlet application must be able to clearly identify them in their usage zones (probably around). In order to make it possible, it is highly recommended to follow these guidelines. Use the namespace of the portlet to add some portlet application specific description to the UID to add some of the uniqueness in the namespace, for example: com.ibm.wps.samplet, for example: com.ibm.wps.samplet .mail.4969 Add a suffix to the corresponding specific portlet application, for example: com.ibm.wps.samplet.mail.4969.1 In the application, the portlet identity must be unique.</div><div class="text-center mt-3 text-grey"> 转载请注明原文地址:https://www.9cbs.com/read-95653.html</div><div class="plugin d-flex justify-content-center mt-3"></div><hr><div class="row"><div class="col-lg-12 text-muted mt-2"><h2 class="h6 mb-0 small"><a class="text-secondary" href="tag-2.html">9cbs</a></h2></div></div></div></div><div class="card card-postlist border-white shadow"><div class="card-body"><div class="card-title"><div class="d-flex justify-content-between"><div>New Post(0) </div><div></div></div></div><ul class="postlist list-unstyled"> </ul></div></div><div class="d-none threadlist"><input type="checkbox" name="modtid" value="95653" checked /></div></div></div></div></div><footer class="text-muted small bg-dark py-4 mt-3" id="footer"><div class="container"><div class="row"><div class="col">CopyRight © 2020 All Rights Reserved </div><div class="col text-right">Processed: 0.042, SQL: 9</div></div></div></footer><script src="./lang/en-us/lang.js?2.2.0"></script><script src="view/js/jquery.min.js?2.2.0"></script><script src="view/js/popper.min.js?2.2.0"></script><script src="view/js/bootstrap.min.js?2.2.0"></script><script src="view/js/xiuno.js?2.2.0"></script><script src="view/js/bootstrap-plugin.js?2.2.0"></script><script src="view/js/async.min.js?2.2.0"></script><script src="view/js/form.js?2.2.0"></script><script> var debug = DEBUG = 0; var url_rewrite_on = 1; var url_path = './'; var forumarr = {"1":"Tech"}; var fid = 1; var uid = 0; var gid = 0; xn.options.water_image_url = 'view/img/water-small.png'; </script><script src="view/js/wellcms.js?2.2.0"></script><a class="scroll-to-top rounded" href="javascript:void(0);"></a><a class="scroll-to-bottom rounded" href="javascript:void(0);" style="display: inline;"></a></body></html><script> var forum_url = 'list-1.html'; var safe_token = 'xp0iOPxO1LsIVkrF7J1xfKpH35Gj2YFWgeXwGIuNO_2BF251zXv8ngxjF_2FH2EEZFI3tEelburHOnR6_2BBx_2FS7_2BtOA_3D_3D'; var body = $('body'); body.on('submit', '#form', function() { var jthis = $(this); var jsubmit = jthis.find('#submit'); jthis.reset(); jsubmit.button('loading'); var postdata = jthis.serializeObject(); $.xpost(jthis.attr('action'), postdata, function(code, message) { if(code == 0) { location.reload(); } else { $.alert(message); jsubmit.button('reset'); } }); return false; }); function resize_image() { var jmessagelist = $('div.message'); var first_width = jmessagelist.width(); jmessagelist.each(function() { var jdiv = $(this); var maxwidth = jdiv.attr('isfirst') ? first_width : jdiv.width(); var jmessage_width = Math.min(jdiv.width(), maxwidth); jdiv.find('img, embed, iframe, video').each(function() { var jimg = $(this); var img_width = this.org_width; var img_height = this.org_height; if(!img_width) { var img_width = jimg.attr('width'); var img_height = jimg.attr('height'); this.org_width = img_width; this.org_height = img_height; } if(img_width > jmessage_width) { if(this.tagName == 'IMG') { jimg.width(jmessage_width); jimg.css('height', 'auto'); jimg.css('cursor', 'pointer'); jimg.on('click', function() { }); } else { jimg.width(jmessage_width); var height = (img_height / img_width) * jimg.width(); jimg.height(height); } } }); }); } function resize_table() { $('div.message').each(function() { var jdiv = $(this); jdiv.find('table').addClass('table').wrap('<div class="table-responsive"></div>'); }); } $(function() { resize_image(); resize_table(); $(window).on('resize', resize_image); }); var jmessage = $('#message'); jmessage.on('focus', function() {if(jmessage.t) { clearTimeout(jmessage.t); jmessage.t = null; } jmessage.css('height', '6rem'); }); jmessage.on('blur', function() {jmessage.t = setTimeout(function() { jmessage.css('height', '2.5rem');}, 1000); }); $('#nav li[data-active="fid-1"]').addClass('active'); </script>