Skip navigation
2013

Everything comes with a public API nowadays, and now so does GateIn Portal. This post introduces the Java API, there's also a REST API which there will be a separate post about.

 

For this release the main focus was on navigation, specifically manging portal navigations and creating custom navigation portlets.

Managing Portal Navigations

Portal navigations are menus that contain hyperlinks to other parts of a portal. In the past these could only be created through the web interface, but can now also be created through the Java or REST API's. Most operations that are required to manage portal navigations are supported. For example adding nodes to a portal navigation, moving nodes around, controlling permissions and managing internationalized labels for nodes.

 

For the full details on what can be done look at the Developer Guide: https://docs.jboss.org/author/display/GTNPORTAL36/Portal+API.

Custom Navigation Portlets

If the standard navigation portlets doesn't do the job for you, now it's very easy to create your own custom navigation portlet to build a menu exactly the way you want it. You can easily control what nodes are displayed in the menu with the filtering mechanism and how many levels of nodes to display with the node visitors mechanism.

 

There's a number of resources available to get you started:

With the release of GateIn 3.6.0.Final we introduced some new CDI scopes to ease its use within a portlet.  This second blog on CDI scopes for GateIn, will cover @PortletRedisplayScoped. This scope can be used with GenericPortlets, Portlet Filters, or JSF Portlets.

 

This scope is retained beyond a single Portlet Request lifecycle to be retrieved for all subsequent Render Requests that don't involve an Action or Event. The Beans in this scope are destroyed subsequent Action or Event requests, enabling continual refreshing of the portlet by a user to repeatedly display the same exact content as the Bean data will not be re generated for each Render. The following table illustrates when the context for the scope is activated (A), destroyed (X), or when its already present (P):

 

 

Portlet TriggerAction StartAction CompleteEvent StartEvent CompleteRender StartRender CompleteResource StartResource Complete
Portlet ActionX then APPPPP

Portlet Event

X then APPP

Portlet Render



A (if not present)P

Portlet Resource





AX

 

An important distinction is that any Beans created within the scope context as part of a Portlet Action, Portlet Event or Portlet Render are not visible within a Portlet Resource call, and vice versa. Each ResourceRequest will receive a completely empty set of Beans that have been constructed, including calls to any @PostConstruct, but that have had no code executed against them.

 

There is one difference with how Resource Request Beans are handled as compared to @PortletLifecycleScoped, in that any Beans that are used during a Resource Request will be merged into the context of the main portlet lifecycle. What this means is that the values on a @PortletRedisplayScoped bean that was used during a Resource Request will replace the contents of the same Bean type for the next Render Request that is executed. In most cases that wouldn't be a problem, but it's a potential gotcha if you make lots of Ajax calls and suddenly wonder why the values in your Beans are all wrong the next time you Render the portlet.

 

To begin using the new scope, simply add the following dependency into your portlet project pom.xml:

 

        <dependency>
            <groupId>org.gatein.api</groupId>
            <artifactId>gatein-api</artifactId>
            <version>1.0.0.Final</version>
            <scope>provided</scope>
        </dependency>

 

We mark the dependency as provided since GateIn will automatically link our deployment to the latest API dependency at runtime.

 

With the above dependency we can then create a bean such as:

 

@PortletRedisplayScoped
public class LifecycleBean implements java.io.Serializable {
  ...
}

 

Note that we implement Serializable for our Bean, as the context is stored within the User Session, which can potentially be passivated by the container.

 

As far as CDI is concerned, @PortletRedisplayScoped is a bean scope like all those that it provides. This enables us to inject @RequestScoped, @ConversationScoped, @SessionScoped or @ApplicationScoped beans into a @PortletRedisplayScoped bean, or vice versa.

 

Hope this and the scope we covered in the previous blog will make developing CDI portlets with GateIn that much easier!

With the release of GateIn 3.6.0.Final we introduced some new CDI scopes to ease its use within a portlet.  In this first blog on CDI scopes for GateIn, we will cover @PortletLifecycleScoped. This scope can be used with GenericPortlets, Portlet Filters, or JSF Portlets.

 

This scope lives for a single Portlet Request lifecycle and is destroyed on completion, meaning that there is no way to guarantee a subsequent Render will generate the same portlet content. The following table illustrates when the context for the scope is activated (A), destroyed (X), or when its already present (P):

 

 

Portlet TriggerAction StartAction CompleteEvent StartEvent CompleteRender StartRender CompleteResource StartResource Complete
Portlet ActionAPPPPX

Portlet Event

APPX

Portlet Render



AX

Portlet Resource





AX

 

An important distinction is that any Beans created within the scope context as part of a Portlet Action, Portlet Event or Portlet Render are not visible within a Portlet Resource call, and vice versa. Each ResourceRequest will receive a completely empty set of Beans that have been constructed, including calls to any @PostConstruct, but that have had no code executed against them. Any changes to Beans within a ResourceRequest is not retained in any way. This situation is perfect for making Ajax calls from a portlet, so long as the data you're relying on perform the work is accessible from non @PortletLifecycleScoped beans.

 

To begin using the new scope, simply add the following dependency into your portlet project pom.xml:

 

        <dependency>
            <groupId>org.gatein.api</groupId>
            <artifactId>gatein-api</artifactId>
            <version>1.0.0.Final</version>
            <scope>provided</scope>
        </dependency>

 

We mark the dependency as provided since GateIn will automatically link our deployment to the latest API dependency at runtime.

 

With the above dependency we can then create a bean such as:

 

@PortletLifecycleScoped
public class LifecycleBean {
  ...
}

 

As far as CDI is concerned, @PortletLifecycleScoped is a bean scope like all those that it provides. This enables us to inject @RequestScoped, @ConversationScoped, @SessionScoped or @ApplicationScoped beans into a @PortletLifecycleScoped bean, or vice versa.

 

Hope this and the scope we cover in the next blog will make developing CDI portlets with GateIn that much easier!

With the release of GateIn 3.6.0.Final we now have the ability to inject CDI beans directly into our portlet classes, whether they extend GenericPortlet or implement the Portlet interface, and any class that implements a Portlet Filter interface.

 

The injection works just the same as with any other CDI injection, with one small caveat. When deciding which Beans to inject into our portlet or filter, keep in mind that injecting a normal scoped bean, such as @SessionScoped, is fine even though there is no User Session present, because the container will simply inject a client proxy for us, but it's not possible to inject a Bean that is being produced by another Bean that doesn't have a valid context.

 

To explain this with an example, if we take the following portlet class:

 

public class BadPortlet extends GenericPortlet {
  @Inject
  private Greeting myGreeting;
}

 

and create a producer for it such as:

 

@SessionScoped
public class GreetingProducer implements Serializable {
  @Produces
  public Greeting produceGreeting(InjectionPoint point) {
    ...
  }
}

 

We receive a ContextNotActiveException because we're trying to produce one Bean from another Bean that is not yet, as there is no User Session during Portlet Container initialization.

 

When wanting to inject a produced Bean into a portlet class or filter, they need to be produced by @ApplicationScoped or @Dependent scoped Beans.

 

Here's an example portlet showing how we can use CDI injection:

 

public class MyPortlet extends GenericPortlet {
  @Inject
  MyBean bean;

  public void doView(RenderRequest request, RenderResponse response) throws PortletException, IOException {
    PortletRequestDispatcher dispatcher = getPortletContext().getRequestDispatcher("/myPage.jsp");
    request.setAttribute("myBean", bean);
    dispatcher.include(request, response);
  }
}

 

In our JSP we can then access the bean with ${myBean}.

 

I hope that this introduction into creating CDI enabled portlets and portlet filters will make your next portlet a bit easier to use with CDI!

A couple of screencasts have been created which cover the awesome new mobile (and responsive!) site which is included in GateIn 3.6.

 

The first one covers a brief overview of the mobile site that shows some of its cool new features and how it acts on a mobile phone.

 

 

 

 

The second screencast covers some of the configuration details when dealing with a mobile or responsive site. Including how to configure the viewport for the portal, restrict the shared layout to non-administrators and how to setup the responsive header portlet.

 

It also covers how to create a new mobile or responsive portal.

 

 

Check them out!

Gate In Device Detection and Site Redirection for performing redirection based on Use Agent has been available since version 3.5.0.Final but configuration was only possible through manual editing of a XML file, it’s modification would not affect the portal at runtime and even after restarting the server it would only be reloaded after deleting some data generated at startup. But that’s history, Gate In 3.6.0.Final introduces the “Site Redirects and Import/Export Portlet” to solve all these details for Site Redirection while also integrating the previous “Import/Export Site” portlet behavior in a more modern way, thanks to the fabulous work on the UI/UXP by Gabriel Cardoso and making use of the cool Richfaces Bootstrap Components!

 

You can find this portlet when logged as an Administrator under Group > Administration > Site Redirects and Import/Export on the top menu.

 

Configuring Site Redirects

Once on the portlet the list of available Sites is presented on the left side menu. Spaces are also present but they are not available for Redirects, only for Exporting.

Selecting a site will present the available Redirect conditions, which can be ordered by using drag and drop. These should be ordered in a way that most specific Redirects are on top (e.g.: “iOS”, “Touch”, “Mobile”).

 

redirects-list.png

 

A Redirect can be configured by clicking the “Configure” wrench icon, which shall present the following screen for its configuration:

 

redirect-config-main.png

 

In the top section, it is possible to toggle the redirect on or off, change it’s name and select to which site it should redirect to.

 

The “Conditions” section is where it is possible to define the conditions to evaluate in order to know if this redirect should be activated. These conditions are composed by valid Java regular expressions, can be checked for its presence or absence and are evaluated against the User Agent String. It is also possible to evaluate against custom defined properties (such as width, height, number of colors, etc), which should be configured at detection.jsp. See more detailed information on this at GateIn Developer Guide - Site Redirection.

 

redirect-edit-condition.png

 

At the “Node Mappings” section there’s the possibility to define where to redirect when the use is heading for a particular portal node, by either using node name matching where he’s redirected to the node with the same name or to define a custom node mapping, such as “classic/flash” redirecting to “ios/flash-not-available”. In case no mapping is defined and a node with the same name is not available (when node name mapping is enabled), the default action to perform should be defined in the unresolved nodes select.

More detailed information about how to configure redirects can be found at the User Guide.

 

Export a Site or Space

This same portlet allows exporting a site or space to be used in a different portal instalation or for backup purposes.

To do so, click the small arrow that shows on the right side of each site or space and click on the export option from the dropdown menu and a download of a zip containing the relevant files will start.

 

Import a Site

Importing a site is as easy, simply select the option to import from the left side menu and from the popup window, select the files to import (up to 5 at a time), select the desired import mode and voilá.

 

import-sites-spaces.png

In GateIn 3.6.0.Final we have added possibility to integrate the GateIn portal with Social networks Facebook, Google Plus and Twitter. Portal users will be able to register and login into the GateIn Portal using their 3rd party accounts from these social networks. In addition we have provided a set of quickstart portlets, which allow users to use the data from their social networks. For example we have a portlet for displaying all Facebook friends of a particular user.

 

This integration is leveraging the OAuth 2.0 protocol (in case of Facebook and Google+), and the OAuth 1.0A protocol (in case of Twitter). The GateIn Portal serves as an OAuth Client while particular social network serves as an OAuth Authorization and Resource server.

 

More information about the GateIn Portal integration is available in the documentation here and more inforomation about quickstart portlets is here

 

Before you dive into details in the documentation, you can check our video screencasts and see it in action first!

 

The first screencast is showing how to register and login into the GateIn Portal using social network accounts:

 

 

The second screencast is showing how to import Social portlet quickstarts into Eclipse IDE using JBoss Tools plugin, deploy into the GateIn Portal and then use the portlets to show information from Social network:

 

 

Enjoy the screencasts and the music in the background composed by Viliam Rockai.

I am are proud to announce GateIn Portal 3.6.0.Final release.

 

This is the outcome of several months of hard work of all developers involved in this project. Here I would like to thank everyone who helped make this release a reality.

 

For the past month and after Beta02 we have been mainly focused on fixing bugs. You can see the effect in Release Notes with 79 solved issues.

 

All key features have already been covered when announcing Beta01 and Beta02. Therefore I would like to just mention them briefly:

 

 

It is not possible to share enough details regarding all of new features in just one blog post. Therefore instead we decided to provide you with better coverage of all exciting improvements coming in GateIn Portal 3.6.0.Final. During next few weeks you can expect developers involved in the project to regularly post new articles or screencasts here. Stay tuned!

 

So what is comming next? We are switching focus to work on 3.7 release to follow. Let us know if there are any particular features you are interested in or you would be willing to contribute to. In parallel Julien is working on next gen architecture for GateIn 4.0.

 

Enjoy new GateIn 3.6.0.Final. Download and try it out while it is hot