JBoss® Portal 2.7.1

The compiled Java class implementing javax.portlet.Portlet (through javax.portlet.GenericPortlet )

default-object.xml is an optional file, it is used to define the layout of the portal. It can be used to define the different portals, pages and windows. The same result can be obtained through the administration portal. Note that the definition of the layout is stored in database, this file is then used to populate the database during deployment which can be very useful during development.

portlet-instances.xml is also optional, it allows to create a portlet instance from the SimpleHelloWorld portlet definition. Creating instances can also be done through the administration portal. Note that the definition of instances is stored in database, this file is then used to populate the database during deployment which can be very useful during development. Having portlet-instances.xml and default-object.xml included in this package ensures that the portlet will appear directly on the portal by just deploying the web application.

This is the mandatory descriptor files for portlets. It is used during deployment..

This is the mandatory descriptor for web applications.

All portlets must implement the javax.portlet.Portlet interface. The portlet API provides a convenient implementation of this interface, in the form of the javax.portlet.GenericPortlet class, which among other things, implements the Portlet render method to dispatch to abstract mode-specific methods to make it easier to support the standard portlet modes. As well, it provides a default implementation for the processAction , init and destroy methods. It is recommended to extend GenericPortlet for most cases.

As we extend from GenericPortlet , and are only interested in supporting the view mode, only the doView method needs to be implemented, and the GenericPortlet render implemention calls our implementation when the view mode is requested.

Use the RenderResponse to obtain a writer to be used to produce content.

Write the markup to display.

Closing the writer.

Define the portlet name. It does not have to be the class name.

The Fully Qualified Name (FQN) of your portlet class must be declared here.

The <supports> element declares all of the markup types that a portlet supports in the render method. This is accomplished via the <mime-type> element, which is required for every portlet. The declared MIME types must match the capability of the portlet. As well, it allows you to pair which modes and window states are supported for each markup type. All portlets must support the view portlet mode, so this does not have to be declared. Use the <mime-type> element to define which markup type your portlet supports, which in this example, is text/html . This section tells the portal that it only outputs HTML.

When rendered, the portlet's title is displayed as the header in the portlet window, unless it is overridden programmatically. In this example, the title would be Simplest Hello World Portlet .

Tells the portal where this portlet appears. In this case, default.default specifies that the portlet appears in the portal instance named default , and on the page named default .

Instructs the portal to overwrite or keep this object if it already exists. Accepted values are overwrite and keep . The overwrite option destroys the existing object, and creates a new one based on the content of the deployment. The keep option maintains the existing object deployment, or creates a new one if it does not exist.

Here we are creating a new page to put the new window on. We give that new page a name that will be by default used on the tab of the default theme.

A unique name given to the portlet window. This can be named anything.

The value of <instance-ref> must match the value of one of the <instance-id> elements found in the HelloWorldPortlet/WEB-INF/portlet-instances.xml file.

Specifies where the window appears within the page layout.

Specifies where the window appears within the page layout.

As in the first portlet, we override the doView method.

Here we try to obtain the value of the render parameter names yourname . If defined we want to redirect to the hello.jsp JSP page, otherwise to the welcome.jsp JSP page.

Very similar to the Servlet way, we get a request dispatcher on a file located within the web archive.

The last step is to perform the inclusion of the markup obtained from the JSP.

processAction is the method from GernericPorlet to override for the action phase.

Here we retrieve the parameter obtained through an action URL .

Here we need to keep the value of yourname to make it available in the rendering phase. With the previous line, we are simply copying an action parameter to a render parameter for the sake of this example.

Since we will use the portlet taglib, we first need to declare it.

The first method showed here is the simplest one, portlet:renderURL will create a URL that will call the render phase of the current portlet and append the result at the place of the markup (Here within a tag...). We also added a parameter directly on the URL.

In this method instead of having a tag within another tag, which is not XML valid, we use the var attribute. Instead of printing the url the portlet:renderURL tag will store the result in the referenced variable ( myRenderURL in our case).

The variable myRenderURL is used like any other JSP variable.

The third method mixes form submission and action request. Like in the second method, we used a temporary variable to put the created URL into.

The action URL is used in the HTML form.

All JSF portlets define javax.portlet.faces.GenericFacesPortlet as portlet class. This class is part of the JBoss Portlet Bridge

This is a mandatory parameter to define what's the default page to display.

This parameter defines which page to display on the 'edit' mode.

This parameter defines which page to display on the 'help' mode.