Difference between revisions of "ClientContextLibrary"

From Gcube Wiki
Jump to: navigation, search
Line 7: Line 7:
  
 
== Getting the Client Context in Javascript ==
 
== Getting the Client Context in Javascript ==
 
+
<source lang="xml">
 +
<script>
 
var groupId = Liferay.ThemeDisplay.getScopeGroupId();
 
var groupId = Liferay.ThemeDisplay.getScopeGroupId();
 
+
</script>
 +
<source lang="xml">
 
== Getting the Client Context in GWT (Widget) ==
 
== Getting the Client Context in GWT (Widget) ==
  
Line 38: Line 40:
 
</source>
 
</source>
  
 +
Either if you pass this identifier explicitly as parameter, or embed it in the header of your cal, in the server you can use the following snippet to get the infrastructure scope:
  
 +
<source lang="java">
 +
//groupIdNo is the String in the server passed from the client
 +
 +
if (groupIdNo != null) {
 +
long groupId = -1;
 +
try {
 +
groupId = Long.parseLong(groupIdNo);
 +
LiferayGroupManager gm = new LiferayGroupManager();
 +
if (gm.isRootVO(groupId)) {
 +
return SCOPE_SEPARATOR + getInfrastructureName();
 +
} else
 +
return new LiferayGroupManager().getInfrastructureScope(groupId);
 +
} catch (NumberFormatException e) {
 +
_log.error("The groupId is not a number -> " + groupId);
 +
} catch (Exception e) {
 +
_log.error("This groupId does not belong to any group in this portal -> " + groupId);
 +
}
 +
}
 +
</source>
  
  

Revision as of 16:56, 14 November 2016

Client Context library for gCube Portlets

Starting from gCube 4.2, the current Context identifier resides client side. If your Portlet does use AJAX calls (i.e. XMLHttpRequest to exchange data with a server behind the scenes) you don't need this component. Everything is already set up for you by the gCube Portal/Gateway in which your application is running.

If you use standard http GET or POST to exchange data with the server instead, and you need to pass to the server the current Infrastructure scope identifier (the Liferay groupId).

Getting the Client Context in Javascript

<script>
var groupId = Liferay.ThemeDisplay.getScopeGroupId();
</script>
<source lang="xml">
== Getting the Client Context in GWT (Widget) ==
 
The Client Context has been wrapped as a GWT Widget. Its source code is available in the gCube SVN repository, at this [http://svn.research-infrastructures.eu/public/d4science/gcube/trunk/portal/client-context-library url]. 
 
To use the widget, you need to declare the following maven dependency in your project's pom.xml
 
<source lang="xml">
<dependency>
        <groupId>org.gcube.portal</groupId>
	<artifactId>client-context-library</artifactId>
	<version>[1.0.0-SNAPSHOT,)</version>
	<scope>compile</scope>
</dependency>

as well as the following line in the gwt.xml file of your gwt-portlet:

<!--Inherit the GCubeClientContext widget code -->
<inherits name='org.gcube.portal.clientcontext.GCubeClientContext' />

then you just use the GCubeClientContext.getCurrentContextId() method:

public static native String getCurrentContextId();

Either if you pass this identifier explicitly as parameter, or embed it in the header of your cal, in the server you can use the following snippet to get the infrastructure scope:

//groupIdNo is the String in the server passed from the client
 
		if (groupIdNo != null) {
			long groupId = -1;
			try {
				groupId = Long.parseLong(groupIdNo);
				LiferayGroupManager gm = new LiferayGroupManager();
				if (gm.isRootVO(groupId)) {
					return SCOPE_SEPARATOR + getInfrastructureName();
				} else 
					return new LiferayGroupManager().getInfrastructureScope(groupId);
			} catch (NumberFormatException e) {
				_log.error("The groupId is not a number -> " + groupId);
			} catch (Exception e) {
				_log.error("This groupId does not belong to any group in this portal -> " + groupId);
			}
		}


Tips for Development Environment

The client context relies on Liferay.ThemeDisplay javascript object, which obviously is not available if you run your application outside the real D4Science's portals. Moreover, the Portal Manager allows to retrieve the current context, the current user (plus some other information, such as his/her current security token) at server side. To overcome such limitation and allow developers to test their applications in Eclipse, a file like this one can be used:

# ONLY FOR LOCAL (IDE) DEVELOPMENT - NOT FOR PRODUCTION USE!
# change the properties with your user data and desired scope / token
# Author: Massimiliano Assante, CNR-ISTI
 
# a development user 
user.username=test.user
user.name=aTestName
user.lastname=aTestLastName
user.email=testing.user@gcube-system.org
 
# a development scope (the scope must be bound to the token below)
development.scope=/gcube/devsec/devVRE
 
# a valid user token on the (above) development scope.
# you can obtain it by registering on one development VRE and using Token Generator portlet
user.token= ....


The name of the file must be gcube-dev-context.properties, and must be placed under the CATALINA_HOME system variable. The PortalManager will recognize if the application is running on a real or fake portal and, in the latter case, will retrieve and use the information written in this file.

NOTE : depending on the current implementation, the PortalManager set/doesn't set in the ThreadLocal variables the retrieved user's security Token and current Context, once it is queried for this information. Be sure to always set them in your own code, if you need them.