Liferay

Liferay blog available as android app now

2013-09-13T22:25:00.002-07:00

http://www.appsgeyser.com/594928
Try this out.And suggestions invited

All the posts here are for sharing knowledge.

For more info:-http://www.liferay.com/

© 2013 LIFERAY INC. ALL RIGHTS RESERVED

Liferay Portal 6.1 - Development Guide

2012-02-27T20:58:00.000-08:00

Resources for Liferay Developers

The following are useful reference resources for developers working with the Liferay Platform:

Liferay specific resources:
- What is a portal? http://www.liferay.com/products/what-is-a-portal
- Platform Javadocs: http://docs.liferay.com/portal/6.1/javadocs/
- Reference documentation for Liferay's XML files: http://docs.liferay.com/portal/6.1/definitions/
- Reference documentation for Liferay's taglibs: http://docs.liferay.com/portal/6.1/taglibs/
- Sources for version 6.1:
  - https://github.com/liferay/liferay-portal/tags
  - https://github.com/liferay/liferay-plugins/tags
- Sources of the development version:
  - https://github.com/liferay/liferay-portal
  - https://github.com/liferay/liferay-plugins
Related specifications and standards:
- Java 5 Javadocs: http://download.oracle.com/javase/1.5.0/docs/api/
- JavaEE 5 Javadocs: http://download.oracle.com/javaee/5/api/
- JavaEE Overview: http://www.oracle.com/technetwork/java/javaee/tech/index.html
- Portlet Specification 2.0 (JSR-286): http://jcp.org/en/jsr/detail?id=286
- Web Services for Remote Portlets (WSRP): http://www.oasis-open.org/committees/wsrp/
- Java Content Repository (JSR-170): http://jcp.org/en/jsr/detail?id=170
- Java Server Faces 1.2 (JSR-252): http://www.jcp.org/en/jsr/detail?id=252
- Java Server Faces 2.0 (JSR-314): http://www.jcp.org/en/jsr/detail?id=314
- OpenSocial: http://www.opensocial.org/
- Sitemap protocol: http://sitemaps.org/
- WebDAV: http://webdav.org/
- SOAP: http://www.w3.org/TR/2007/REC-soap12-part0-20070427/
- HTML 5: http://html5.org/
- WCAG 2.0: http://www.w3.org/WAI/intro/wcag20.php
Related and commonly used technologies:
- Spring Framework: http://www.springsource.org/
- Hibernate: http://www.hibernate.org/
- Struts 1: http://struts.apache.org/1.x/
- Lucene: http://lucene.apache.org/
- Alloy UI: http://alloy.liferay.com/
- YUI 3: http://developer.yahoo.com/yui/3/
- jQuery: http://jquery.com/
- IceFaces: http://www.icefaces.org/main/home/
- PortletFaces: http://www.portletfaces.org/
- Vaadin: http://vaadin.com/home
- OpenXava: http://www.openxava.org/web/guest/liferay
- Apache ant: http://ant.apache.org/
- Maven: http://maven.apache.org/
- Selenium: http://seleniumhq.org/
- Tomcat: http://tomcat.apache.org/
- JBoss Application Server: http://www.jboss.org/

Liferay India developers group on Facebook

2012-02-06T03:57:00.000-08:00

This group is running successfully from past few months.It helps me out to learn many new things in Liferay.I just take the initiate but all the members Satish,Mazhar,Vamc (i just remeber these names only ) even everyone who are here contribute alot. Hope this will continue and get a large number of members this year. "http://www.facebook.com/groups/180811265343833/" Thanks alot for being a part of this community

Liferay 6.1 and SASS

2012-01-18T01:20:00.000-08:00

Lieray 6.1 CE is released and many of you have started using it. There are lots of features in Liferay 6.1 and one among them is the facility to use SASS in Liferay.

SASS:

SASS( http://sass-lang.com ) stands for Syntactically Awesome StyleSheets. It is a tool that allows you to write CSS more easily . It is an extension of CSS3 which means whatever CSS file is a valid SassyCSS (SCSS). It allows you to use variables, nested rules, mixins, inline imports, interpolation, arguments, manipulating colors and more with a fully CSS-compatible syntax. Sass generates well formatted CSS and it is much easier to organize and maintain your stylesheets.

Compass :

Compass( http://compass-style.org ) is an open-source CSS authoring framework which makes easier to build and maintain your markup and stylesheets. By using compass, you can write your own stylesheet in Sass instead of CSS.

How does Compass Work?

It can be imported using @import "compass" in CSS. SCSS is built based on the CSS3 specification which means that it is highly compatible with CSS3. SCSS also has all the power of Sass.

We’ll see here as how to use the variables, nested rules, mixins, inline imports, interpolation and arguments through CSS files.

Variables:

We’ll see how to use variables and a custom mixin to show how Compass makes it easy to reuse colors, sizes, and other values without repeating.

/* Variable Declaration */

/*These variables can be used globally throughout your stylesheets */

Example:

Liferay6.1 Liferay 6.0.x

Mixins:

By using the mixin, you can re-use the styles, properties & selectors without copying to other selectors. To achieve this , you need to package the properties with @mixin and to include it in other element with @include.

Example:

Liferay 6.1 Liferay 6.0.x

Nested Rules:

Nesting avoids repeating CSS selectors and also keeps the style compact for a certain area of the User Interface.

Let us have a look at an example of custom.css code for navigation part in themes. After using the nesting rule, the code should look like this :

Liferay 6.1 Liferay 6.0.x

Parent Reference:

Parent reference allows you to reference a parent selector in the case of pseudo-classes like :hover, :link, :visited and :active states.

Liferay 6.1 Liferay 6.0.x

Interpolation:

We can also use SassScript variables in selectors and property names using #{} interpolation. Here’s the example:

Liferay 6.1 Liferay 6.0.x

Liferay6.1 allows you to use Sass which helps the code be simpler for mobile site design. (Thanks to BradleyWood’s solution in this forum post ).

As said in Sass , it makes CSS fun again and with Liferay 6.1, you can easily create manageable style sheets and start updating to Liferay 6.1 and use Sass to manage your style sheets .

Upgrading Liferay Portal 6.0 to Liferay Portal 6.1

2012-01-13T04:15:00.000-08:00

Upgrading Liferay

Liferay upgrades are fairly straightforward. A consistent set of steps is all you need to follow to upgrade a standard Liferay installation. Things do get more complicated if your organization has used Ext plugins to customize Liferay. It's possible that API changes in the new version will break your existing code. This, however, is usually pretty easy for your developers to fix. Portlet plugins which use Liferay APIs should be reviewed and their services rebuilt against the new release. Theme plugins may require some modifications in order to take advantage of new features, and if they're using Liferay APIs, they should be reviewed. Much effort has been made to make upgrades as painless as possible; however, this is not a guarantee that everything will work without modification. Ext plugins are the most complicating factor in an upgrade, so it is important to test as much as possible.

As a general rule, you can upgrade from one major release to the next major release. For example, you can upgrade directly from Liferay 5.2.x to 6.0.x, but not from 5.2.x to 6.1.x. If you need to upgrade over several major releases, you'll need to run the upgrade procedure for each major release until you reach the release you want. This doesn't mean you need to run the procedure for every point release or service pack; you only need to run the procedure for the major releases. A good practice is to use the latest version of each major release to upgrade your system.

Now that we've gotten the general philosophy of upgrading out of the way, let's outline the procedure you'll undergo for upgrading a Liferay 6.0 installation to a 6.1 installation. If you're running a previous version of Liferay and need to upgrade to 6.0 first, please see the instructions in the previous version of this document.

Upgrading Liferay Portal 6.0 to Liferay Portal 6.1

There are a few things you'll want to prepare before you actually perform the upgrade. Specifically, you'll need to review your image gallery usage, review new Liferay 6.1 defaults, and catalog all the plugins you have installed. After you've performed these three tasks, you'll be ready to upgrade.

Liferay 6.1 introduces a major change to how Liferay handles files. No longer do we have a separate Document Library and Image Gallery; instead, these have been combined into Documents and Media. If you were using Liferay's Image Gallery to store images, these can be migrated over during an upgrade, but you'll have to take some extra steps first.

In Liferay 6.0, you had three ways you could store images in the Image Gallery. You could use the DatabaseHook and store them as BLOBs in the database; you could use the DLHook to store them in the Document Library, or you could use the FileSystemHook to store them in a folder on your server's file system. Before you upgrade, you'll need to set whichever property you were using in your 6.0 portal-ext.properties file, because by default, none of them are enabled in 6.1. Setting one of the properties triggers the migration during the upgrade process. Below are the three properties; you'll need to set only one of them (the one you were using).

image.hook.impl=com.liferay.portal.image.DatabaseHook image.hook.impl=com.liferay.portal.image.DLHook 
image.hook.impl=com.liferay.portal.image.FileSystemHook

The next thing you'll need to look at are the defaults that have changed from 6.0 to 6.1. These are preserved in portal-legacy-6.0.properties in the source. The 6.0 values are:

users.last.name.required=true layout.types=portlet,panel,embedded,article,url,link_to_layout editor.wysiwyg.portal-web.
docroot.html.portlet.message_boards.edit_message.bb_code.jsp=bbcode 
setup.wizard.enabled=false discussion.subscribe.by.default=false
 message.boards.subscribe.by.default=false

The 6.1 values have changed to:

users.last.name.required=false layout.types=portlet,panel,embedded,url,link_to_layout editor.wysiwyg.portal-web.
docroot.html.portlet.message_boards.edit_message.bb_code.jsp=ckeditor_bbcode
 setup.wizard.enabled=true discussion.subscribe.by.default=true message.boards.subscribe.by.default=true

If you don't like the defaults, you can change them back in one shot by adding a system property to your JVM's startup. This differs by application servers. In Tomcat, you'd modify setenv.sh / setenv.bat and append the option -Dexternal-properties=portal-legacy-6.0.properties to the environment variable JAVA_OPTS. The scripts setenv.sh or setenv.bat are not delivered with default Tomcat, but do exist in the bundles. If they're there, Tomcat uses them in the startup process, so it's a nice way to separate your own settings from Tomcat's default shell scripts. Alternatively, of course, you can override some or all of them in your portal-ext.properties along with your other overrides.

Finally, you need to take note of any plugins you have installed. Liferay's plugins are usually version-specific, so you'll need to obtain new versions of them for the new release of Liferay. If you have custom plugins created by your development team, they'll need to build, test, and optionally modify them to work with the new release of Liferay. Don't attempt an upgrade without collecting all the plugins you'll need first.

Once you've reviewed your properties and collected all the plugins you'll need, you're ready to follow the upgrade procedure. Remember to back up your system before you begin.

There are two different procedures to upgrade Liferay. The first one, upgrading a Liferay bundle, is the most common. The second procedure is for upgrading a Liferay installation on an application server. We'll go over both.

In both cases, Liferay auto-detects whether the database requires an upgrade the first time the new version is started. When Liferay does this, it upgrades the database to the format required by the new version. In order to perform this task, Liferay must be accessing the database with an ID that can create, drop, and modify tables. Make sure that you have granted these permissions to the ID before you attempt to upgrade Liferay. And, of course, we'll run the risk of overly repeating ourselves: back up your database.

Let's look at upgrading a bundle, which is the easiest upgrade path.

Upgrading a bundle

If you're running a Liferay bundle, the best way to do the upgrade is to follow the steps below. The new Liferay is installed in a newer version of your bundle runtime. For example, the Liferay/Tomcat bundle for 6.0 used Tomcat 6 by default; the 6.1 bundle uses Tomcat 7. Though there is a Tomcat 6 bundle of Liferay 6.1, that bundle also uses a newer release of Tomcat than the one from 6.0. This is the case for all runtimes that Liferay supports. We generally recommend that you use the latest version of your runtime bundle, as it will be supported the longest.

Obtain the new bundle. Unzip the bundle to an appropriate location on your system.
Copy your portal-ext.properties file and your data folder to the new bundle.
Review your portal-ext.properties file as described above. If you were using the Image Gallery, make the necessary modifications so that your files are migrated to Documents and Media. Review the new defaults and decide whether you want to use them. Review any other modifications you've made.
Start your application server. Watch the console as Liferay starts: it should upgrade the database automatically.
When the upgrade completes, install any plugins you were using in your old version of Liferay. Make sure you use the versions of those plugins that are designed for Liferay 6.1. If you have your own plugins, your development team will need to migrate the code in these ahead of time and provide .war files to you.
Browse around in your new installation and verify that everything is working. Have your QA team test everything. If all looks good, you can delete the old application server with the old release of Liferay in it from the bundle directory. You have a backup of it anyway, right?

As you can see, upgrading a bundle is generally pretty simple. But not everybody can use bundles: sometimes, specific application servers or application server versions are mandated by the environment you're in or by management. For this reason, Liferay also ships as an installable .war file that can be used on any supported application server.

Upgrading using a .war file

Running a manual upgrade is almost as easy as upgrading a bundle:

Obtain the Liferay Portal .war file and the dependency .jars archive.
Copy your customized portal-ext.properties file to a safe place and review it as described above, making all the appropriate changes.
Undeploy the old version of Liferay and shut down your application server.
Copy the new versions of Liferay's dependency .jars to a location on your server's class path, overwriting the ones you already have for the old version of Liferay. This location is documented for your application server in chapter 11.
Deploy the new Liferay .war file to your application server. Follow the deployment instructions in chapter 11.
Start (or, if your app server has a console from which you've installed the .war, restart) your application server. Watch the console as Liferay starts: it should upgrade the database automatically. Verify that your portal is operating normally, and then install any plugins you were using in your old version of Liferay. Make sure you use the versions of theose plugins that are designed for Liferay 6.1. If you have your own plugins, your development team will need to migrate the code in these ahead of time and provide .war files to you.
Browse around in your new installation and verify that everything is working. Have your QA team test everything. If all looks good, you're finished.

That's all there is to it. Most everything is handled by Liferay's upgrade procedure. Note that as stated above, if you have to upgrade over several Liferay versions, you will need to repeat these steps for each major release.

New Liferay 6.1 Feature - Remote Development from Liferay IDE

2012-01-12T23:24:00.000-08:00

I'd like to mention one of the new features in the upcoming release of Liferay 6.1, which is the remote development and deployment support from Liferay IDE. The idea is that with this feature you can build Liferay projects in Liferay IDE like normal but instead of the Liferay server running locally it is running on a remote host. This is accomplished through two things, 1) new remote server adapter in Liferay IDE and 2) Server manager plugin (new in 6.1) deployed to the remote Liferay server

This feature will be officially available with the Liferay 6.1 CE release, but since it is only in beta, now is a good time to try it out and give feedback.

For those who wish to try this out here are the steps to setting it up.

1. Download the Liferay Portal 6.1 Beta4 Tomcat bundle (Only tomcat is supported in beta4, both JBoss and Glassfish will be supported by 6.1 GA release)

2. Start Tomcat bundle on remote host (or even localhost)

3. Download the Server Manager plugin for 6.1 Beta4 (This plugin provides the API needed by Liferay IDE to administer remote plugins)

4. Deploy Server Manager plugin into remote Tomcat server

5. Install the latest stable or nightly version of Liferay IDE (links are updatesite URLs to use in Eclipse install manager)

6. Create a new server in Liferay IDE, File > New > Server > Liferay > Remote Liferay Server

7. Specify a local tomcat bundle for the runtime stub (this is needed for libraries to compile project)

8. Specify the IP address of remote tomcat server along with Omni admin username/password

Once you have done this you should see the server console log messages printed in the normal Eclipse console view.

9. Create and deploy Liferay projects as usual then publish (deploy) them to the server, see Liferay IDE getting started guide for a walkthrough of this.

Now when you modify files in your project, every 15 seconds it will publish the delta of any changes to remote server. However, you can publish changes immediately using the "publish" action in the servers view. If you want to change the automatic publish rate you can do that in the server configuration editor (double click server in Servers view).

For anyone who decides to try this out and want to give feedback with suggestions or problems please either open a JIRA ticket for the IDE project or enter a new topic on the IDE forums .

Writing Liferay Apps with Web Content Templates

2012-01-12T04:20:00.000-08:00

One of the often overlooked features of Liferay's WCM system is the ability to write non-trivial apps using it. There have been a few blog posts about this, notably Ray Augé's Advanced Web Content Example With AJAX . In the community, it's great for me because I can quickly create interesting visualizations of community data and share it with you immediately. There are some pros and cons to this approach:

Benefits:

No compilation needed - WCM relies on the use of Templates , written in interpreted (i.e. scripted) languages such as Velocity Templates . This means you can quickly make a change and see your results quickly.
No deployment needed - since Web Content isn't a java portlet, you don't need to re-deploy. More importantly it means you don't have to wait for a website administrator to deploy it if you cannot deploy yourself!
You can combine presentation (e.g. HTML/JS/CSS) and logic (e.g. Velocity) into the same template, keeping related code together.

Drawbacks:

Velocity is first and foremost a templating/presentation language. It is not a general purpose computing language, so die hard MVC types will probably dismiss the use of Velocity in this way and call me a heretic/lunatic. It's great for prototyping though!
Currently, Structures and Templates aren't versioned, and they do not participate in Liferay's Workflow system. So you can't revert to older (working) versions of templates if you make a mistake.
No compilation needed - so it's not as fast as the native bytecode that would result from the equivalent java source code. But it's still quite fast.
Velocity and other scripting languages have weird quirks that often cannot be caught except through trial and error, and limitations (e.g. no use of generics) that compiled/strongly typed languages have.
You can combine presentation (e.g. HTML) and logic (e.g. Velocity) into the same template :)

In my opinion, Liferay WCM is a very good solution for app prototyping or for non-trivial apps that don't have tons of logic or page flows in them. You have already seen an example of this in the Community Activity Map , and the example I use below forms the basis for the Hot Topics app that you can now see on liferay.org .

Basic Template Template

To get started creating an app of this nature, you need to start with simple Web Content Template that is itself a template:

#if ($request.lifecycle == "RENDER_PHASE")
 ## This phase will handle the presentation code (i.e. HTML/CSS/JS). Any calls ## to the ${request.resource-url} will retrieve the result of evaluating the below ## RESOURCE_PHASE below. 
#elseif ($request.lifecycle == "RESOURCE_PHASE")
 ## This phase will handle the AJAX request like a portlet's serveResource() method 
#end

So decide what needs to be executed on the server side, and put it in the RESOURCE_PHASE . This is typically where most if not all of the business (i.e. non-presentation) logic goes. Put the presentation logic in the RENDER_PHASE .

Hot Topics Example

For this app, I want to show which threads have the most posts in the last week. So, I needed to query Liferay's Message Boards. Since there is no getMostActiveThreadsInTheLastWeek() method (I know.. what's up with that??), I needed a custom query. This means using Liferay's DynamicQuery feature. But from Velocity? Turns out it's not that bad. Here's the full RESOURCE_PHASE code to create and execute a Dynamic Query, and generate a JSON object as a result which contains the most active threads in the last week:

#set ($portletNamespace = $request.portlet-namespace) #set ($scopeGroupId = $getterUtil.getLong($request.theme-display.scope-group-id)) #if ($request.lifecycle == "RENDER_PHASE") ## bunch of display logic to show the JSON result nicely #elseif ($request.lifecycle == "RESOURCE_PHASE") #set ($logFactory = $portal.getClass().forName('com.liferay.portal.kernel.log.LogFactoryUtil')) #set ($log = $logFactory.getLog('mylog')) #set ($portalBeanLocator = $portal.getClass().forName("com.liferay.portal.kernel.bean.PortalBeanLocatorUtil")) #set ($jsonFactory = $portalBeanLocator.locate("com.liferay.portal.kernel.json.JSONFactoryUtil")) #set ($mbMessageLocalService = $portalBeanLocator.locate("com.liferay.portlet.messageboards.service.MBMessageLocalService.velocity")) #set ($mbThreadLocalService = $portalBeanLocator.locate("com.liferay.portlet.messageboards.service.MBThreadLocalService.velocity")) #set ($calClass = $portal.getClass().forName("java.util.GregorianCalendar")) #set ($mbMessageClass = $portal.getClass().forName("com.liferay.portlet.messageboards.model.MBMessage")) #set ($mbThreadClass = $portal.getClass().forName("com.liferay.portlet.messageboards.model.MBThread")) #set ($dqfu = $portal.getClass().forName("com.liferay.portal.kernel.dao.orm.DynamicQueryFactoryUtil")) #set ($pfu = $portal.getClass().forName("com.liferay.portal.kernel.dao.orm.ProjectionFactoryUtil")) #set ($ofu = $portal.getClass().forName("com.liferay.portal.kernel.dao.orm.OrderFactoryUtil")) #set ($now = $calClass.getInstance()) #set ($weeksago = $calClass.getInstance()) #set ($prevweeks = 0 - $getterUtil.getInteger($period.data)) #set ($V = $weeksago.add(3, $prevweeks)) #set ($q = $dqfu.forClass($mbThreadClass)) #set ($rfu = $portal.getClass().forName("com.liferay.portal.kernel.dao.orm.RestrictionsFactoryUtil")) #set ($groupIdCriteria = $rfu.ne("categoryId", $getterUtil.getLong("-1"))) #set ($V = $q.add($groupIdCriteria)) #set ($groupIdCriteria = $rfu.eq("groupId", $getterUtil.getLong($scopeGroupId))) #set ($V = $q.add($groupIdCriteria)) #set ($companyIdCriteria = $rfu.eq("companyId", $getterUtil.getLong($companyId))) #set ($V = $q.add($companyIdCriteria)) #set ($statusCriteria = $rfu.eq("status", 0)) #set ($V = $q.add($statusCriteria)) #set ($lastPostDateCriteria = $rfu.between("lastPostDate", $weeksago.getTime(), $now.getTime())) #set ($V = $q.add($lastPostDateCriteria)) #set ($V = $q.setProjection($pfu.property("threadId"))) #set ($res1 = $mbMessageLocalService.dynamicQuery($q)) #set ($q2 = $dqfu.forClass($mbMessageClass)) #set ($inCriteria = $rfu.in("threadId", $res1)) #set ($V = $q2.add($inCriteria)) #set ($createDateCriteria = $rfu.between("createDate", $weeksago.getTime(), $now.getTime())) #set ($V = $q2.add($createDateCriteria)) #set ($V = $q2.setProjection($pfu.projectionList().add($pfu.groupProperty("rootMessageId")).add($pfu.alias($pfu.rowCount(), "msgCount")))) #set ($V = $q2.addOrder($ofu.desc("msgCount"))) #set ($V = $q2.setLimit(0, 7)) #set ($res2 = $mbMessageLocalService.dynamicQuery($q2)) #set ($jsonArray = $jsonFactory.createJSONArray()) #foreach ($msgSum in $res2) #set ($rootMsgId = $msgSum.get(0)) #set ($msgCount = $msgSum.get(1)) #set ($subject = $mbMessageLocalService.getMessage($rootMsgId).getSubject()) #set ($jsonObject = $jsonFactory.createJSONObject()) #set ($V = $jsonObject.put("subject", $stringUtil.shorten($htmlUtil.escape($subject), 55))) #set ($V = $jsonObject.put("msgid", $rootMsgId)) #set ($V = $jsonObject.put("msgCount", $msgCount)) #set ($V = $jsonArray.put($jsonObject)) #end { "jsonArray": $jsonArray } #end

Details

There are many things going on here:

Velocity Debugging/Logging

 #set ($logFactory = $portal.getClass().forName('com.liferay.portal.kernel.log.LogFactoryUtil')) #set ($log = $logFactory.getLog('mylog'))

This gives me a way to debug the code by looking at the server log (if you are using this kind of app so that you can bypass your website admin, chances are you won't have access to the server logs, so this won't help you). To emit debug info, I can do things like $log.error($msgCount) or $log.error("Hi There").

Creating references for arbitrary JVM classes

 #set ($calClass = $portal.getClass().forName("java.util.GregorianCalendar"))

This allows me to create references to any class known in the JVM for doing things like calling static methods, etc. Many of these are needed for constructing Dynamic Queries.

Calculating Now and a Week Ago

 #set ($now = $calClass.getInstance()) #set ($weeksago = $calClass.getInstance()) #set ($prevweeks = 0 - $getterUtil.getInteger($period.data)) #set ($V = $weeksago.add(3, $prevweeks))

This creates Calendar objects representing the current time, and a week ago. Note that the number of weeks is specified in a web content structure using the period structure element.

The rest of the code constructs two dynamic queries:

The first one ( $q ) queries for MBThread entities that have a categoryId of -1 (MBThreads that do not have a categoryId of -1 are not threads from the message boards portlet, instead they are threads for things like comments on document library entries, etc). The query also includes other criteria, like groupId/companyId must match the "current" groupId/companyId of the site in which the web content is placed, the status must be 0 (indicating it is an approved (i.e. not draft or deleted) entry), and most importantly the lastPostDate must be between my desired time period start and end. Finally, I am not interested in all of the MBThread entity - I just need the threadId . So my query includes a Projection that only returns the threadId .
The second query ( $q2 ) queries for all MBMessage entities that match my new critieria: they must have a threadId of one of the threads identified in the first query (hence the in criteria), and the message's createDate must also be between my start/end dates. This is to avoid counting messages in the thread that occured before the cutoff dates. Finally, this gem:

 #set ($V = $q2.setProjection($pfu.projectionList().add($pfu.groupProperty("rootMessageId")).add($pfu.alias($pfu.rowCount(), "msgCount")))) #set ($V = $q2.addOrder($ofu.desc("msgCount"))) #set ($V = $q2.setLimit(0, 7))

This creates a projection that is grouped by the rootMessageId , since each message in the same thread will have the same rootMessageId (which I eventually use to construct the URL to the message), and includes a count of the messages that match (with an alias defined so I can refer to the row count when specifying the order of the results via addOrder() ). I also limit the results to 7 because I don't want to show any more than that (this is a simple app). This second query returns a result table that looks like:

So after the Dynamic Queries executes, it's just a matter of constructing a JSONObject (and sanitizing/sizing the actual text of the subject of the thread) and returning it.

Liferay WCM and Velocity Gotchas

Velocity is first and foremost a templating/presentation language. It is not a general purpose computing language, so die hard MVC types will probably dismiss the use of Velocity in this way and call me a heretic/lunatic. But it also means that some things are hard (or impossible, for example did anyone catch that I hard-coded Calendar.MONTH to be 3 ? You can't reference static member variables of a class unless it is already part of the Velocity context in which a template is evaluated). There are many other perils awaiting the adventurous Velocity coder. I learned many things through trial and error (and the help of my IRC friends on the #liferay channel!). Here are some more:

Don't forget to use $var instead of var . If you forget the $, you won't get syntax errors, just silent errors and half of your code will next execute.
If you can use an intelligent IDE (like IntelliJ IDEA or Eclipse ) and its Velocity syntax checking, do it! I saved tons of time by using IntelliJ and declaring variable types, which allowed for autocompletion and type checking. For example, I had tons of these:

#* @vtlvariable name="request" type="java.util.Map" *# #* @vtlvariable name="httpUtil" type="com.liferay.portal.kernel.util.HttpUtil" *# #* @vtlvariable name="htmlUtil" type="com.liferay.portal.kernel.util.HtmlUtil" *# #* @vtlvariable name="obc" type="com.liferay.portal.util.comparator.UserLastNameComparator" *# #* @vtlvariable name="serviceLocator" type="com.liferay.portal.velocity.ServiceLocator" *# #* @vtlvariable name="teamLocalService" type="com.liferay.portal.service.TeamLocalServiceUtil" *# #* @vtlvariable name="mbMessageLocalService" type="com.liferay.portlet.messageboards.service.MBMessageLocalServiceUtil" *# #* @vtlvariable name="mbThreadLocalService" type="com.liferay.portlet.messageboards.service.MBThreadLocalServiceUtil" *#

Any time you access things from the ${request.theme-display} , or access one of your WCM structure fields that represent a number (but are of type "Text" in the template), they are probably not of the the type that you want. You need to use generous amounts of $getterUtil.getXXX calls to make sure. For example,

#set ($scopeGroupId = $getterUtil.getLong($request.theme-display.scope-group-id))

will work (and makes $scopeGroupId a Long), whereas

#set ($scopeGroupId = $request.theme-display.scope-group-id)

Will results in a $scopeGroupId that is not a Long, and so if you pass it in to a method that is expecting a Long, it won't work, and will probably silently fail and you'll be befuddled.

If you want to create a new instance of a class (e.g. a HashMap) you can'y say new HashMap() . Velocity does not know what " new " is - after all, you're using a presentation/templating language, not Java! But we're using it for more than display. So as a workaround you can do things like $portal.getClass().forName("java.util.HashMap").newInstance() .
Accessing elements of an array cannot be done using $array[0] . You have to use $array.get(0) .

The Full Source to Hot Topics

Here's the full source, including my display code, and my IntelliJ variable declarations (which may have some unnecessary declarations, but I use this block for other stuff too). If you spot errors or poor coding technique or whatever else, please let me know so I can learn!

#* @vtlvariable name="portletNamespace" type="java.lang.String" *# #* @vtlvariable name="portal" type="com.liferay.portal.util.Portal" *# #* @vtlvariable name="getterUtil" type="com.liferay.portal.kernel.util.GetterUtil" *# #* @vtlvariable name="stringUtil" type="com.liferay.portal.kernel.util.StringUtil" *# #* @vtlvariable name="max-members" type="com.liferay.portlet.journal.util.TemplateNode" *# #* @vtlvariable name="team-name" type="com.liferay.portlet.journal.util.TemplateNode" *# #* @vtlvariable name="section-members" type="com.liferay.portlet.journal.util.TemplateNode" *# #* @vtlvariable name="groupId" type="java.lang.String" *# #* @vtlvariable name="sectionMembers" type="java.lang.String" *# #* @vtlvariable name="locale" type="java.util.Locale" *# #* @vtlvariable name="companyId" type="java.lang.String" *# #* @vtlvariable name="scopeGroupId" type="java.lang.String" *# #* @vtlvariable name="sectionName" type="java.lang.String" *# #* @vtlvariable name="section-name" type="com.liferay.portlet.journal.util.TemplateNode" *# #* @vtlvariable name="params" type="java.util.LinkedHashMap" *# #* @vtlvariable name="users" type="java.util.List" *# #* @vtlvariable name="user" type="com.liferay.portal.model.User" *# #* @vtlvariable name="themeDisplay" type="com.liferay.portal.theme.ThemeDisplay" *# #* @vtlvariable name="languageUtil" type="com.liferay.portal.kernel.language.LanguageUtil" *# #* @vtlvariable name="request" type="java.util.Map" *# #* @vtlvariable name="httpUtil" type="com.liferay.portal.kernel.util.HttpUtil" *# #* @vtlvariable name="htmlUtil" type="com.liferay.portal.kernel.util.HtmlUtil" *# #* @vtlvariable name="obc" type="com.liferay.portal.util.comparator.UserLastNameComparator" *# #* @vtlvariable name="serviceLocator" type="com.liferay.portal.velocity.ServiceLocator" *# #* @vtlvariable name="teamLocalService" type="com.liferay.portal.service.TeamLocalServiceUtil" *# #* @vtlvariable name="mbMessageLocalService" type="com.liferay.portlet.messageboards.service.MBMessageLocalServiceUtil" *# #* @vtlvariable name="mbThreadLocalService" type="com.liferay.portlet.messageboards.service.MBThreadLocalServiceUtil" *# #* @vtlvariable name="imageToken" type="com.liferay.portal.kernel.servlet.ImageServletToken" *# #* @vtlvariable name="userLocalService" type="com.liferay.portal.service.UserLocalServiceUtil" *# #* @vtlvariable name="groupIdCriteria" type="com.liferay.portal.kernel.dao.orm.Criterion" *# #* @vtlvariable name="groupIdProp" type="com.liferay.portal.kernel.dao.orm.Property" *# #* @vtlvariable name="threadMap" type="java.util.Map<java.lang.Long, java.lang.Integer>" *# #* @vtlvariable name="q" type="com.liferay.portal.kernel.dao.orm.DynamicQuery" *# #* @vtlvariable name="q2" type="com.liferay.portal.kernel.dao.orm.DynamicQuery" *# #* @vtlvariable name="rfu" type="com.liferay.portal.kernel.dao.orm.RestrictionsFactoryUtil" *# #* @vtlvariable name="pfu" type="com.liferay.portal.kernel.dao.orm.ProjectionFactoryUtil" *# #* @vtlvariable name="ofu" type="com.liferay.portal.kernel.dao.orm.OrderFactoryUtil" *# #* @vtlvariable name="msgs" type="java.util.List<com.liferay.portlet.messageboards.model.MBMessage>" *# #set ($portletNamespace = $request.portlet-namespace) #set ($scopeGroupId = $getterUtil.getLong($request.theme-display.scope-group-id)) #if ($request.lifecycle == "RENDER_PHASE") <body onload="${portletNamespace}getTable();"> <article> <h1 class="section-heading section-heading-b"> <div>$title.data</div> <div class="section-heading-hr"></div> </h1> <div id='${portletNamespace}tablediv' style='width: 85%;'><!-- --></div> </article> </body> <script type="text/javascript"> var ${portletNamespace}table = new Object(); var ${portletNamespace}ICON = '<img class="icon" \ src="http://my-liferay-site-cdn.com/osb-theme/images/spacer.png" \ alt="Message Boards" title="Message Boards" \ style=" background-image: url(\'/html/icons/_sprite.png\');\ background-position: 50% -736px; \ background-repeat: no-repeat; height: 16px; width: 16px;">'; function ${portletNamespace}drawChart() { var html = '<div> \ <table style="margin-bottom:0em;"> \ <tbody>'; for (i = 0; i < ${portletNamespace}table.length; i++) { html += '<tr> \ <td class="portlet-icon" style="padding-right:6px;"> \ <table style="margin-top:-4px; margin-bottom:0px;">\ <tr>\ <td>\ <span>' + ${portletNamespace}ICON + '</span> \ </td>\ </tr>\ <tr>\ <td>\ <span style="color:#908E91; font-size:9px;">'+ ${portletNamespace}table[i].msgCount + '</span>\ </td>\ </tr>\ </table>\ </td> \ <td>\ <div>\ <h3 class="txt-n fs-11 m-0 o-h">\ <span class="display-b m-tn3 m-b6">\ <a href="/community/forums/-/message_boards/message/' + ${portletNamespace}table[i].msgid +'">'+ ${portletNamespace}table[i].subject + '</a>\ </span>\ </h3>\ </div>\ </td>\ </tr>'; } html += '</tbody>\ </table>\ </div>'; document.getElementById('${portletNamespace}tablediv').innerHTML = html; } function ${portletNamespace}getTable() { AUI().use( "aui-base", "aui-io-plugin", "aui-io-request", function(A) { A.io.request( '${request.resource-url}', { data: { }, dataType: "json", on: { success: function(event, id, obj) { var responseData = this.get("responseData"); ${portletNamespace}table = responseData.jsonArray || []; ${portletNamespace}drawChart(); }, failure: function(event, id, obj) { } } } ); } ); } </script> #elseif ($request.lifecycle == "RESOURCE_PHASE") #set ($logFactory = $portal.getClass().forName('com.liferay.portal.kernel.log.LogFactoryUtil')) #set ($log = $logFactory.getLog('mylog')) #set ($portalBeanLocator = $portal.getClass().forName("com.liferay.portal.kernel.bean.PortalBeanLocatorUtil")) #set ($jsonFactory = $portalBeanLocator.locate("com.liferay.portal.kernel.json.JSONFactoryUtil")) #set ($mbMessageLocalService = $portalBeanLocator.locate("com.liferay.portlet.messageboards.service.MBMessageLocalService.velocity")) #set ($mbThreadLocalService = $portalBeanLocator.locate("com.liferay.portlet.messageboards.service.MBThreadLocalService.velocity")) #set ($calClass = $portal.getClass().forName("java.util.GregorianCalendar")) #set ($mbMessageClass = $portal.getClass().forName("com.liferay.portlet.messageboards.model.MBMessage")) #set ($mbThreadClass = $portal.getClass().forName("com.liferay.portlet.messageboards.model.MBThread")) #set ($dqfu = $portal.getClass().forName("com.liferay.portal.kernel.dao.orm.DynamicQueryFactoryUtil")) #set ($pfu = $portal.getClass().forName("com.liferay.portal.kernel.dao.orm.ProjectionFactoryUtil")) #set ($ofu = $portal.getClass().forName("com.liferay.portal.kernel.dao.orm.OrderFactoryUtil")) #set ($now = $calClass.getInstance()) #set ($weeksago = $calClass.getInstance()) #set ($prevweeks = 0 - $getterUtil.getInteger($period.data)) #set ($V = $weeksago.add(3, $prevweeks)) #set ($q = $dqfu.forClass($mbThreadClass)) #set ($rfu = $portal.getClass().forName("com.liferay.portal.kernel.dao.orm.RestrictionsFactoryUtil")) #set ($groupIdCriteria = $rfu.ne("categoryId", $getterUtil.getLong("-1"))) #set ($V = $q.add($groupIdCriteria)) #set ($groupIdCriteria = $rfu.eq("groupId", $getterUtil.getLong($scopeGroupId))) #set ($V = $q.add($groupIdCriteria)) #set ($companyIdCriteria = $rfu.eq("companyId", $getterUtil.getLong($companyId))) #set ($V = $q.add($companyIdCriteria)) #set ($statusCriteria = $rfu.eq("status", 0)) #set ($V = $q.add($statusCriteria)) #set ($lastPostDateCriteria = $rfu.between("lastPostDate", $weeksago.getTime(), $now.getTime())) #set ($V = $q.add($lastPostDateCriteria)) #set ($V = $q.setProjection($pfu.property("threadId"))) #set ($res1 = $mbMessageLocalService.dynamicQuery($q)) #set ($q2 = $dqfu.forClass($mbMessageClass)) #set ($inCriteria = $rfu.in("threadId", $res1)) #set ($V = $q2.add($inCriteria)) #set ($createDateCriteria = $rfu.between("createDate", $weeksago.getTime(), $now.getTime())) #set ($V = $q2.add($createDateCriteria)) #set ($V = $q2.setProjection($pfu.projectionList().add($pfu.groupProperty("rootMessageId")).add($pfu.alias($pfu.rowCount(), "msgCount")))) #set ($V = $q2.addOrder($ofu.desc("msgCount"))) #set ($V = $q2.setLimit(0, 7)) #set ($res2 = $mbMessageLocalService.dynamicQuery($q2)) #set ($jsonArray = $jsonFactory.createJSONArray()) #foreach ($msgSum in $res2) #set ($rootMsgId = $msgSum.get(0)) #set ($msgCount = $msgSum.get(1)) #set ($subject = $mbMessageLocalService.getMessage($rootMsgId).getSubject()) #set ($jsonObject = $jsonFactory.createJSONObject()) #set ($V = $jsonObject.put("subject", $stringUtil.shorten($htmlUtil.escape($subject), 55))) #set ($V = $jsonObject.put("msgid", $rootMsgId)) #set ($V = $jsonObject.put("msgCount", $msgCount)) #set ($V = $jsonArray.put($jsonObject)) #end { "jsonArray": $jsonArray } #end

source

Changes in Social Equity in Liferay 6.1

2012-01-12T04:13:00.000-08:00

There have been some pretty interesting and important changes regarding Social Equity for Liferay 6.1. While some of the changes are conceptual and others are additional features, there is one thing that is very important: there has been a change of API.

The new equity system is now part of the social activity framework. This is not just a naming concept. As part of the change, several functionalities were moved to different services and the original Social Equity services were removed. The whole framework got its own XML descriptor (formerly activities were configured in resource actions descriptors) that can be used to define activities and everything else related to them. This new descriptor can be used to extend already configured activities and can be used in plugins as well.

The Goal of the New System

While the main goal of being able to measure participation and contribution in a communty hasn't changed, there are some differences how these values are created and maintained. The new social equity system is now part of a broader scoped social activity framework that is designed to log certain activities as well as provide numerical instruments to monitor actvities or simply to provide the means for statistical analysis.

Activity Counters

This system provides the basis for an extendable metrics system for assets and users.

Statistical Periods

One of the biggest conceptual changes is the introduction of the counter period. Values no longer degrade, rather there is a configurable time interval where points are aggregated resulting in a "current" value for each of these periods. A total value is also maintained. This method suits the human thinking more than the former method of degrading values. We are more used to thinking in periods. We are used to having "employee of the month" or values projected to a certain year - such as balance sheets.

Equity Counters

The old social equity scores are mostly still there. Fundamentally these values are just counters. Of course there are always those more equals among equals, so equity counters have some special treatment. In addition to the limit system that has been implemented for normal counters these counters have some other checks that for example guard against an asset owner building up its own asset's popularity and a result his or her own contribution score by doing certain actions on his or her asset.

API changes

One of the most importart API changes is that the triggering of an equity action was moved to the social activity service. In fact, adding a social activity now triggers the new social equity service automatically, so you can simply call one of the addActviity() methods in SocualActivityLocalService and if things are configured and social equity is enabled for the group, everything will be fine. If the activity is configured to be logged, the social activity service will log it the same way it's been doing so far, so that it can appear in the activities portlet. Additionally it will call new SocialActivityCounterLocalService to trigger counter processing.

To get the value of a counter (including participation and contribution values as they are handled as counters) you can use the fetchLatestActivityCounter() method of the SocialActivityCounterLocalService. There are additional helper methods to retrieve a list of counters by other criteria, but probably this is the most important method of the service.

Liferay 6.1 GA1 in the cloud, step by step

2012-01-12T04:05:00.000-08:00

Do you want your new Liferay 6.1 GA1, with all these new functionalities: english and spanish , in the cloud?

Follow this simple steps to achieve it, even if you want to use the new Setup Wizard:

Go to Jelastic ( www.jelastic.com ), create an account depending of your location
Create an enviroment: Tomcat + MySQL
Upload portal libraries ( portal-client and dependencies ) to SERVER/lib.
Upload WAR file from sourceforge ( here ) (Jelastic make it easy that uploading, because directly links to that WAR file)

Create portal-ext.properties at SERVER, with this values:

resource.repositories.root=${user.home}/
ENVIROMENT_NAME

include-and-override=${liferay.home}/portal-setup-wizard.properties

liferay.home=${user.home}/
ENVIROMENT_NAME

jdbc.default.jndi.name=
jdbc/LiferayPool

Modify SERVER/context.xml file with this values (note that the "mysql-" is very important at db url):

<Resource name="
jdbc/LiferayPool
" auth="Container" type="javax.sql.DataSource" maxActive="100" maxIdle="30" maxWait="10000" username="
USER
" password="
PASSWORD
" driverClassName="com.mysql.jdbc.Driver" url="jdbc:mysql://
mysql-ENVIROMENT_NAME
.jelastic.com/
DATABASE_NAME
?useEncoding=true&amp;characterEncoding=UTF-8" />

Clean catalina.out log to be sure that your installation is successfull.
Restart server.
Check in catalina.out that Liferay starts reading your portal-ext
Browse to you portal: ENVIROMENT_NAME.jelastic.com
Setup Wizard is the first thing you'll see, but as JNDI is configured, we cannot modify database settings. We should go to SERVER/context.xml for database changes.
Set up for portal (name, language, admin credentials), and...
Here it is! Your portal up and running!

Then, you can tune your portal with portal-ext reminding not to modify properties set in this blog.

Importants (and new things):

As you can see, we are taking care of telling setup wizard where to read the new props file (the include-an-override property), and we are also configuring database with JNDI, but of course you can do it with JDBC, just with the usual way:

jdbc.default.driverClassName=com.mysql.jdbc.Driver

jdbc.default.url=jdbc:mysql://mysql-ENVIROMENT_NAME/database_name?useUnicode=true&characterEncoding=UTF-8&useFastDateParsing=false

```
jdbc.default.username=user
```
```
jdbc.default.password=password
```

Hope it helps!

Himanshu

Liferay 6.1 CE released - A first brief review!

2012-01-09T02:31:00.000-08:00

Liferay 6.1 CE released - A first brief review!

Its a new year for a new chance to get better in all that things we failed or where we couldn´t gettin better in the past time.
This belongs not only to us but also to our near business partners as well. As that said Liferay does worked out my new-year-call in a pretty short time with Liferay 6.1 CE which has been released recently.
Are you still on Liferay 6.X or lower? Lets migrate your solutions for your customers on sunday to Liferay 6.1 because there are many fancy things around there… i smell something good here and i guess this has something todo with Liferay.

Notice: the next week i will create a review about the CMIS-Interface of Liferay 6.1. I will test it against Alfresco! Stay tuned!

At a glance - all is gettin good - at least at the very end. Until then we see how we can make better our current situation.

In Advance: Many “small” killer changes!

Firstly, if you start Liferay at the very first time you have to talk with Liferay about your taste regarding initial portal-settings which will be stored in a separated file called wizard.properties. Some initial properties like portals-name can be passed on it here.
If you have reached the main page you see at a glance that the UI has been slightly enhanced and looks more clearly since 6.0. If you going through the dockbar-actions on the top you might imagine some new actions right there.
Especilly the control-panel (the action has been moved to the “Go To” actions) has been completely refined. Many “small eyes changes”(which were surely big in their development) have been done. For instance, the Social Equity feature says more clearly what settings we can change here and which consequenes collaboration-actions can have on user-listings (Top Users Dashlet, Ranking etc.).
A new nice feature is the ability to get a first imaginatine on how REST-Services can be called. Therfore Liferay introduces a developer-page where you can see and test REST-Services directly in the browser.

Do Document-Management, hurry up!

As im a longterm ECM-Specialist my personal passion belongs to document-mangement. I just loving to increase productivity, lower overhead on customersite. Now you are able to perform better document-management practices with Liferay. You are now able to create custom datatypes with custom metadata. Your metadata can have text, date, number, associations as attributes with multilanguage support - its just the Liferay-Way!

Look at the first picture. Ive created my own datatype called “Offer” with my own attributes. On applying this documenttype on a new document you can see in the image how it feels like:
As you can see - a webpreview will be created as well. Do you want any more for Liferay 6.1?

Liferay 6.1 CE released

2012-01-08T23:39:00.000-08:00

Introduction to Liferay

Liferay is a portal server. This means that it is designed to be a single environment where all of the applications a user needs can run, and these are integrated together in a consistent and systematic way. If an application lives outside the portal, the portal should be able to consume some resource of the application (such as an RSS feed or a subset of functionality in a "dashboard" application) so that the end user can see everything he or she interacts with at a glance.
To achieve this, all the application functionality within Liferay Portal resides in fragments of the page called portlets. Portlets are web applications that run in a portion of a web page. Liferay's core is a portlet container that aggregates portlets on particular pages and displays them to users. In this way, one or many applications can reside on a page, and users can (at the administrator's discretion) arrange them however they like.
Portlet applications, like servlet applications, are defined by a Java standard which various portal server vendors have implemented. The Java standard defines the portlet specification. A JSR-168 or JSR-286 standard portlet should be deployable on any portlet container which supports those standards. Portlets are placed on the page in a certain order by the end user and are served up dynamically by the portal server.
Portal applications generally come in two flavors: 1) multiple portlets which only provide small amounts of functionality individually, but are aggregated by the portal server into a larger application, or 2) whole applications which reside in only one application window. The choice is up to the application designers. Only developers have to worry about what happens inside the portlet itself. The portal server handles building out the page as it is presented to users.
Portlets are not difficult to build, and Java standard portlets can be written by any Java developer with experience in writing web applications. Liferay provides a Plugins Software Development Kit that makes it easy to design new portlet projects, as well as a development environment based on Eclipse. For further information about the Plugins SDK, please see Liferay Developer's Guide, which is the companion volume to this one, or Liferay in Action, published by Manning Publications, which is the official guide to Liferay development. For further information on Liferay's developer tools, see http://www.liferay.com/downloads/liferay-projects/liferay-ide.
Additionally, Liferay supports portlets written in other programming languages, such as PHP, Ruby, Groovy, or Python. Sample portlets written in these languages are available from Liferay's public plugin repository on Github at https://github.com/liferay/liferay-plugins.
We discuss the following topics in this chapter:

Liferay's User Interface: How to navigate around Liferay
Navigating the Control Panel: An overview of Liferay's control panel
Portal Architechture: How Liferay organizes your portal

Navigation within Liferay Portal is designed to be intuitive and easy. Let's get started.

Refer here for details :-liferay 6.1 CE GA

Liferay Logical Architecture

2012-01-08T23:32:00.000-08:00

Liferay Architecture

Enterprise Layer

The enterprise layer forms the top layer of services and components that are grouped into taxonomies which support and realize enterprise functions such as Portal Management, Content Management, Workflow Management, Document Management, User Management, Security Management. The Enterpise Layer is also comprised of inter related service components and features such as Personalization, Collaboration, Social Networking, Delivery Channels, Virtualization and Tunneling Servlets. These form the basic backbone or core enterprise features of Liferay.

Service Layer

Liferay follows a Model Driven Architecture approach. In the traditional sense it requires a Platform Independent Model (PIM) from which we derive and Platform Specific Model (PSM) and subsequently generate implementation logic. In Liferay however, we begin with a Domain Specific Model(DSM) since the root model is only specific to Liferay domain and it defines all the nouns of the system with their interactions and is translated to a Platform Specific Model(PSM) which constitutes the EJB’s, Spring Framework, Hibernate Layer, Web Services and then generates the implementation classes by extending the appropriate services. This is made possible due to the implementation of Service Builder which is the most integral tool provided by Liferay and enforces the same standards throughout. The services builder is the Model Driven Transformation (MDT) Tool in this context.

Extensions Framework

Liferay Provides extensions framework by use of an Extension Environment and Plugins Framework. The extension environment has the same directory structure of the Liferay and was implemented by overriding the existing source files by placing them in the same path. The design also incorporated multiple –ext.properties file to change default settings of the portal by overriding desired properties in the –ext.properties file. The best approach is the hot deployable plugin framework which provided a number of wizards to construct portlets, themes, layouts and hooks or interceptors, and now provides an ext-plugin which provides a similar offset by only replicating those flies that require modification without the entire portal content. The Plugins approach provides both an IDE and command line interface. The IDE takes a wizard approach to create portlets, themes, layouts and hooks. The hooks are basically interceptors can be categorized into model hooks, JSP hooks, properties hook, event hooks. Model hooks deal with interception of entity actions in services, JSP hooks are provided to dynamically modify Liferay JSP pages, the event hook is used to intercept portal events, property hook is used to update the Liferay properties. The ext-hook plugin is a new feature than provides changes to the Liferay structure and can be hot deployed at runtime.

Logical Architecture of Liferay

Liferay supports Windows, Mac and Linux OS. JRE is installed on the supported OS to host the JVM. An application server is required to contain the Liferay instance. The officially supported servers include, but not limited to Apache Tomcat, Glassfish, Geronimo, Jetty, JOnAS, JBoss, and Resin. Most of these servers are available as bundled versions for download and are deployed in the JVM container. The server provides connectivity and interoperability using an Enterprise Service Bus (ESB), and there are multiple services offered by the servers which are leveraged by Liferay. Some of the services, which are primarily used by Liferay on the Application server, include the following: JNDI, JDBC, JTS, JMS, JAAS, JDO, JWS, JSP/Servlets, JavaMail. Applications can be deployed on the server like SOLR Search engine, or DROOLS Rule Engine, or Tunneling Servlets which can further provide extension or integration of external applications with Liferay. Liferay uses a number of technologies at its core to offer the various services. These technologies include EJB, Hibernate, Spring and JBPM. Liferay implements Lucene Search Engine by default and can be configured to extend the SOLR Search Engine which is built on Lucene to extend capabilities to provide clustering, faceted search, filtering with additional enhancements and scalability. A Portlet Bridge is provided to deploy JSR 168/286 portlets and supports RIA applications. Liferay contains Language adaptors such as for Python, Ruby and PHP which allows easy integration.

The Administration Kernel provides the base framework for integration and support of all modules, with tooling support, wizards, service providers, listeners and runtime configuration parameters to tweak the application server in runtime mode. The services builder provides the basic framework to construct and deploy the services using a Model Driven Development (MDD) approach. The portlet plug-in leverages on the portlet bridge to provide dynamically generated portlets to the end users and enhanced RIA integration. The hooks plug-in provide convenient access to intercept and alter the services and functionality of the Liferay instance in a standardized approach.By leveraging on all the services and features extended by Liferay, a robust Enterprise Services layer resides on atop of this providing extended solutions ranging from Portal Management, Web Content Management, Enterprise Content Management, Document Management, User Management, Workflow Management, Security Management. These in turn provide features such as Personalization, Collaboration, Virtualization, Social Networking and integrates Dynamic Delivery Channels, and Tunneling Services.

Add search in theme in LIFERAY

2012-01-06T00:03:00.001-08:00

Steps to add search in theme:

1. Open file [LIFRAY_SDK]/themes/{theme-name}/docroot/_diffs/templates/portal_normal.vm

2. Add $theme.search() at your desired location.

3. Build and deploy the theme.

4. A search text box will appear where the code was placed
Steps to customize the search:

In case you need to customize the search functionality to search only specific content types, follow the steps below.

1. Open file [LIFERAY_HOME]/tomcat-6.0.26/webapps/ROOT/WEB-INF/classes/portal-ext.properties

2. Add following lines:

com.liferay.portlet.blogs.util.BlogsOpenSearchImpl=true

com.liferay.portlet.bookmarks.util.BookmarksOpenSearchImpl=true

com.liferay.portlet.calendar.util.CalendarOpenSearchImpl=true

com.liferay.portlet.directory.util.DirectoryOpenSearchImpl=true

com.liferay.portlet.documentlibrary.util.DLOpenSearchImpl=true

com.liferay.portlet.imagegallery.util.IGOpenSearchImpl=true

com.liferay.portlet.journal.util.JournalOpenSearchImpl=true

com.liferay.portlet.messageboards.util.MBOpenSearchImpl=true

com.liferay.portlet.wiki.util.WikiOpenSearchImpl=true

3. Change values to “false” for those you do not want to include in search result.

For example, to search only “Web Content”, leave “com.liferay.portlet.journal.util.JournalOpenSearchImpl” to “true” and make other values to false.

Enjoy the customized search in Liferay :)

orderable search container in liferay by example

2012-01-05T22:49:00.000-08:00

Liferay provide us with many good taglib out of them search container is one of them.It is widely used taglib. For simple understanding of search container please check Wiki here is the link Wiki Search Container. One thing that article is missing how to implement ordering using. For that we will follow few step and will do a simple example.
Step 1: Read the wiki article Search Container.
Step 2:Now write the below code in your jsp.

<%
PortalPreferences portalPrefs = PortletPreferencesFactoryUtil.getPortalPreferences(request);
String orderByCol = ParamUtil.getString(request, "orderByCol");

String orderByType = ParamUtil.getString(request, "orderByType");

if (Validator.isNotNull(orderByCol) && Validator.isNotNull(orderByType)) {
portalPrefs.setValue("KK_3", "kk-order-by-col", orderByCol);
portalPrefs.setValue("KK_3", "kk-order-by-type", orderByType);

} else {

orderByCol = portalPrefs.getValue("KK_3", "kk-order-by-col", "name");
orderByType = portalPrefs.getValue("KK_3", "kk-order-by-type", "asc");

}

OrderByComparator orderByComparator = AddressBookUtil.getAddressBookOrderByComparator(orderByCol, orderByType);
%>

Now I will explain what is happening we are getting the column on which we have to do ordering in orderByCol and order asc or desc in orderByType.
In line portalPrefs.setValue("KK_3", "kk-order-by-col", orderByCol);
here "KK_3" is namespace , "kk-order-by-col" is key and orderByCol is value.
In last line OrderByComparator orderByComparator = AddressBookUtil.getAddressBookOrderByComparator(orderByCol, orderByType);
For this you need to write a comparator , I have written it in com.ext.portlet.addressBook.util.AddressBookUtil and write this code

public class AddressBookUtil {

/**
*
* @param orderByCol
* @param orderByType
* @return
*/

public static OrderByComparator getAddressBookOrderByComparator(
String orderByCol, String orderByType) {

boolean orderByAsc = false;

if (orderByType.equals("asc")) {
orderByAsc = true;
}

OrderByComparator orderByComparator = null;

if (orderByCol.equals("name")) {
orderByComparator = new AddressBookNameComparator(orderByAsc);
} else if (orderByCol.equals("status")) {
orderByComparator = new AddressBookStatusComparator(orderByAsc);
}

return orderByComparator;
}

}

Now in same package write AddressBookNameComparator and AddressBookStatusComparator if you want you can write any where else and do the required imports. Below is the code for AddressBookNameComparator

public class AddressBookNameComparator extends OrderByComparator {

public static String ORDER_BY_ASC = "name ASC";

public static String ORDER_BY_DESC = "name DESC";

public AddressBookNameComparator() {
this(false);
}

public AddressBookNameComparator(boolean asc) {
_asc = asc;
}

public int compare(Object obj1, Object obj2) {
AddressBook project1 = (AddressBook) obj1;
AddressBook project2 = (AddressBook) obj2;

int value = project1.getName().toLowerCase().compareTo(
project2.getName().toLowerCase());

if (_asc) {
return value;
} else {
return -value;
}
}

public String getOrderBy() {
if (_asc) {
return ORDER_BY_ASC;
} else {
return ORDER_BY_DESC;
}
}

private boolean _asc;

}

Do the required imports .Same way you can do for other columns.
Step 3: Use the SearchContainer taglib.

<liferay-ui:search-container
emptyResultsMessage="No Result Found"
orderByCol="<%= orderByCol %>"
orderByType="<%= orderByType %>"
>
<liferay-ui:search-container-results results="<%= AddressBookLocalServiceUtil.getAddressBookList(searchContainer.getStart(), searchContainer.getEnd(),orderByComparator)%>">
total="<%= AddressBookLocalServiceUtil.getAddressBookCount() %>"
/>
<liferay-ui:search-container-row classname="com.ext.portlet.addressBook.model.AddressBook" escapedmodel="<%= true %>">
keyProperty="bookId"
modelVar="addressBook"
>

<liferay-ui:search-container-column-text name="name" orderable="<%= true %>" orderableproperty="name">
>

<%= addressBook.getName() %>

</liferay-ui:search-container-column-text>

<liferay-ui:search-container-column-text name="status" orderable="<%= true %>" orderableproperty="status" property="status">
/>

</liferay-ui:search-container-column-text>

<liferay-ui:search-iterator />
</liferay-ui:search-container-row></liferay-ui:search-container-results>
That is all about orderable search container.If you have read the wiki article then you will easily understand this.

I18N Liferay 6.x

2012-01-05T22:45:00.000-08:00

Hi today I will share how to use in built Liferay I18N functionality to your custom portlet in Liferay 6.x

It is very simple to add it , for that we need to modify just 2 files.

1.portlet.xml --- In this file add resource bundle entry.

e.g <resource-bundle>content.Language</resource-bundle>

2.build.xml --- In this file we need to call below target.

<target name="build-lang">

<antcall target="build-lang-cmd">

<param name="lang.dir" value="docroot/WEB-INF/src/content" />

<param name="lang.file" value="Language" />

</antcall>

</target>

Now we need to just add one file with name Language.properties under docroot/WEB-INF/src/content
from build.xml using ant call buil-lang. That it !!!

Liferay Search Container

2012-01-04T04:29:00.000-08:00

Creating Liferay Search Container GUIs

Time for some basic knowledge:

What does the liferay-ui tld say about the search container? How is it possible to create nice and functional search container GUIS? Read the following and you know more:

The search container is always rendering a set of rows that contain one or more columns to display search results. You may change the way the search container is rendering the rows but in the end it will always be a set of rows. So what we are going to do now will only affect the rows itself. We won't change the search container to display grids or something similar.

The liferay search container is structured as follows:

view plain print ?

<liferay-ui:search-container >
<liferay-ui:search-container-results>
</liferay-ui:search-container-results>
<liferay-ui:search-container-row>
</liferay-ui:search-container-row>
</liferay-ui:search-container >

Because we will only care for the rows, we will jump right in and take a look at some of the tags you can use:

search-container-column-text

view plain print ?

<liferay-ui:search-container-column-text name="userName" property="userName" />

The column text tag creates a label filled with a header text (name) and a populated value of the search container entity (property). In our case, the property userName would be taken from our entity and displayed.

search-container-column-jsp

view plain print ?

<liferay-ui:search-container-column-jsp path="/your.jsp" align="right" />

Very powerful! Allows to create a complete JSP that will be displayed in every row. By using this tag you can create your own forms with AlloyUI or standard HTML / Javascript and let the search container do all the magic.

search-container-column-button

view plain print ?

<liferay-ui:search-container-column-button align="right" href="<%= yourUrl %>" name='clickMe' />

Allows to create a button pretty easy and connect it to a URL.

search-container-column-score

view plain print ?

<liferay-ui:ratings classPK="<%=user.getUserId()%>" className="<%=User.class.getName() %>" />

Shows the score for the retrieved object.

These tags allow you to create very fast very powerful search container GUIs. I´ve only touched the surface here and there is a lot more of liferay magic that you can discover. Just take a look at the TLD which you can find here:

http://code.google.com/p/liferay-book/source/browse/trunk/portlets/library-portlet/docroot/WEB-INF/tld/liferay-ui.tld?spec=svn3&r=3

If you like this tutorial it would be very nice, if you could click on some of the google ads you see on the right side. It helps me run this block and motivates me ;)

If you have any questions, feel free to leave a comment.

Hide the Control Panel

2012-01-04T01:45:00.001-08:00

Hiding the Liferay Control Panel

Whenever you set up Liferay for a customer, there will be a requirement to prevent the "normal" user from accessing the control panel. Some administrators fear, the user might do things he´s not supposed to do, others fear, the the user might be confused.

But how do you hide the control panel?

Well, there are several possibilities, and none of them is really nice. There is no portal.properties entry and there is no permission you could set. Either you do it programmatically or by CSS and then you also have the loophole of users entering the control panel URL into the browser:

You, and all of your users can always access the control panel by entering "http://localhost:8080/group/control_panel" into the Browser, no matter what you do. To prevent this, I suspect you have to take a look at ServletFilters and prevent every access to this URL if the User is no administrator.

I will now point out two possibilities how to hide the control panel and I would be very glad if you could describe your own approaches in the comments section.

Hiding the Control Panel programmatically

if you want to hide the control panel for all users, who are no administrators you can overwrite the ServicePreAction class in your ext environment. If you take a look at the servicePre method you will find this:

view plain print ?

themeDisplay.setShowControlPanelIcon(signedIn);

So, what ever you do in the .vm files your theme provides: All logged in users will always see the link to the control panel. To remove it, just call the RoleLocalServiceUtil, check whether your user has administrative rights, and change the code above.

Hide the Control Panel using CSS

You could hide the control panel using CSS: You need to apply display:none styles to all elements of the class(es) "control-panel last aui-menu-item".

But how do you make sure, the control panel is hidden from normal users ? To do this, you need to have your own theme. In your theme you need to change the portal_normal.vm and add the following:

view plain print ?

#if ($permissionChecker.isCompanyAdmin($company_id))
<style type="text/css">
.control-panel{
display:none;
}
</style>
#end

That´s it .. control panel should be hidden!

Connecting Liferay to LinkedIn

2012-01-04T01:42:00.001-08:00

Connecting Liferay to LinkedIn

Whenever you think about using liferay in your business you will surely think of it as an "integration platform": One platform to integrate all the information sources that matter to your customers.

In this blog post we will look at how to integrate LinkedIn into your portal. In one of the next posts we will do the same with facebook, but today we will care about the world´s leading business network.

When we talk about integration we mean: "Getting the Data". Liferay always expects to have the users data in its user table and it doesn´t make any sense to rip that core functionality out of liferay. Our goal is to get you connected to linkedIn, so that you have the following possibilities

Authenticate with linkedIn
Import data from linkedIn

Preparation

Our first step will be to allow your liferay instance to connect to linkedIn.

To do so, you need to create an application for linkedIn. If you already did that, you can skip this step and continue with step 2.

To be able to connect to linkedIn (no matter what you do) you need to create a linkedIn application.

First, visit this page: https://www.linkedin.com/secure/developer

Enter all necessary data and create your linkedIn application. If you do so, you should now have an API - Key and a secret password. You need those to create the OAuth authentication flow that is needed to authorize your application to access the data of the users.

What business case ?

Something that you should know before even registering your app at linkedIn is what you want to do with the data you get on linkedIn. Your use cases define the way you need to change or configure the liferay implementation. You might

Show job offerings in an own portlet
Send linkedIn messages from liferay
authenticate the User with linkedIn

etc etc etc

There is a lot you can do. So think about it, and when you are ready, go on to step 3

Accessing LinkedIn

There are many ways to connect to LinkedIn, but I am only going to show one here. There is a pretty good java API available under http://code.google.com/p/linkedin-j/. It seems to be pretty up to date, still under development and (as far as I could see) offers access to all the data LinkedIn provides.

Download the latest version and put all the jars either into the lib dir of your application server or into WEB-INF\lib of the portlet you are developing. Now you should think about how to implement the OAuth flow for linkedIn (facebook is the same ...). The OAuth authentication mechanism basically consists of two steps:

Get the user-specific access token for every user by letting them autorize your app.

Use the access token to get their data from linkedIn.

The first step is something that can be done pretty good in a servlet because it requires some back - and forth communication between the linkedIn and your server. But if you have all the parameters from your portlet at hand, I am sure you can also embed it into a portlet. The code to let the User authenticate your app at linkedIn is the following:

view plain print ?

// Create the oauthService
final LinkedInOAuthService oauthService = LinkedInOAuthServiceFactory.getInstance().createLinkedInOAuthService(your-consumerKey, your-consumerSecret);
//Create the request token to get the autorization URL. You need to specify
//a Callback URL. That´s the URL where the auth token is forwarded to
LinkedInRequestToken requestToken = oauthService.getOAuthRequestToken(CALLBACK_URL);
String authUrl = requestToken.getAuthorizationUrl();
//forward to authorization page
resp.sendRedirect(authUrl);

By implementing this, the user should be transported to the LinkedIn page where he has to authorize your app. If he accepts, he will be transported back to the CALLBACK_URL you specified and you will then have access to his access token. To get his access token, implement the following:

view plain print ?

// Get the OAuth Verifier from the request
String oauthVerifier = req.getParameter("oauth_verifier");
//create the oauth service
final LinkedInOAuthService oauthService = LinkedInOAuthServiceFactory.getInstance().createLinkedInOAuthService(your-consumerKey, your-consumerSecret);
//Create the request token
LinkedInRequestToken requestToken = oauthService.getOAuthRequestToken(CALLBACK_URL);
String authUrl = requestToken.getAuthorizationUrl();
//finally: The access token !!!
LinkedInAccessToken accessToken = oauthService.getOAuthAccessToken(requestToken, oauthVerifier);

If you have this access token, you´re done. You don´t need more to access all fields of the user. Persist this access token somewhere in your database and retrieve it every time you need to update your data. Here is an example of how to get the Users first name:

view plain print ?

LinkedInConnector connector = new LinkedInConnector();
LinkedInApiClient client = connector.connect(accessToken);
Person profile = client.getProfileForCurrentUser();
System.out.println("First name: "+profile.getFirstName());

That´s all! All you need to do now is to define your business use case and get all the fields you need. Contact me if you need any assistance.

Liferay portlet as Facebook App

2012-01-03T23:20:00.000-08:00

How to integrate Liferay portlet as an Facebook tab on facebook page

1.Go to facebook developers create an App.

2.After creating an App you get the AppId and App Secret

Now goto your liferay portlet which you want to deploy as an APP on your facebook page

Go to confugiration of portlet you find a facebook tab there.Click it.

Now you need to fill your FB AppId .And you also need to give the url of the page where u want ur App to be displayed on facebook.

After filling both fiels you get a callback URL.Just copy that URL .

Now comeback to Facebook Developer.Open your app settings.And now u want ur portlet to be displayed as an page tab so just open Page tab option.You will See 3 tabs there

Page tab URL:- Put that call back url there

Secure Page tab URL:- Here you need to give the Https (secured one).Facebook provide option of secure browsing .If you dont provide the secure URL than the users who are using Facebook on HTTPS will unable to see your App.

Page Edit Tab URL:- Put the same call back URL there

SAVE IT.

Now Add this app to your desired page and u will see your portlet as an page tab App.

Note:-For making your liferay portlet working on HTTPS for displaying ur porlet to secure browsing users u need to enable the Https.

Inter Portlet Communication

2012-01-03T03:48:00.001-08:00

Portlet to Portlet Communication

Introduction

The first version of the portlet specification, JSR-168/portlet1.0, did not include any support for Inter Portlet Communication. The second version, JSR-286/ portlet2.0, which is supported for IPC Mechanism.

IPC is made easy with JSR-286 to share the data between two portlets. Using IPC mechanisms, we can share the data from ACTION to VIEW phase and VIEW-VIEW Phase.

There are 3 ways to share the data between 2 portlets.

1. Portlet session

2. IPC Mechanisms

2.1 Public Render Parameters

2.2 Event

2.3 Client-Side IPC

3. Cookies

1. 1. Portlet Session

By default , Each war has its own session and will not be shared with other wars. Liferay provides a mechanism by which Portlets can share session attributes across WARs.

A PortletSession is created for each user per portlet application. This makes the PortletSession useful for communicating all user related information among different portlets in the same portal application.

Step 1: set below attributes in Portlet1

liferay-portlet.xml :

<private-session-attributes>false</private-session-attributes>

</portlet>

Step 2: To set the Session:

PortletSession session = renderRequest.getPortletSession();

session.setAttribute("sessionValue",some-value , PortletSession.APPLICATION_SCOPE);

Step 3 : Get the Session Value in Portlet2

PortletSession ps = renderRequest.getPortletSession();

String tabNames = (String)ps.getAttribute("sessionValue ",ps.APPLICATION_SCOPE);

2. IPC Mechanism

2.1 Public Render Parameter : IPC ( Inter Portlet Communication) :

In JSR 168, the render parameters set in processAction is only available in the render of the same portlet. With the Public Render Parameters feature, the render parameters set in the processAction of one portlet will be available in render of other portlets also.

By adding the following property in portlet-ext, we can enable portlets to share render states with other portlets that are on different pages:

portlet.public.render.parameter.distribution=ALL_PORTLETS

Step 1: Add below attribute in “Sender-Portlet”

<portlet-app>

<portlet>

<supported-public-render-parameter>

id1

</supported-public-render-parameter>
</portlet>

<public-render-parameter>

<qname xmlns:x="http://abc.com/userId">x:param1</qname>

</public-render-parameter>

</portlet-app>

Note: We can declare a list of public paramters for a portlet application.

Step 2:

We can set render parameter in the processAction() method by using the defined public render parameter identifier as the key.

response.setRenderParameter("id1", “someIdValue”);

e.g.

public void processAction(ActionRequest request, ActionResponse response)

throws IOException, PortletException { ........

response.setRenderParameter("id1", “someIdValue”); ........

}

Step 3 : Receiver Portlet Portlet “portlet.xml”

Specify the render parameter the portlet would like to share in the portlet section.

<portlet-app>
< portlet >

< portlet-name >PortletB< /portlet-name >

< supported-public-render-parameter >id1< /supported-public-render-parameter >

< /portlet >

<public-render-parameter>

<qname xmlns:x="http://abc.com/userId">x:param1</qname>

</public-render-parameter>

</portlet-app>

Step 4 :

A portlet can read public render parameter using following method

request.getPublicParameterMap()

Note: Public render parameters are merged with regular parameters so can also be read using

request.getParameter(“id1”);

Step 5:

A portlet can remove a public render parameter by invoking following methods.

response.removePublicRenderParameter(“id1”)

3 Event : IPC ( Inter Portlet Communication) :

Portlet events that a portlet can receive and send.

In JSR-168 :
The only way to achive eventing was through portlet session.
Limitation : Portlet has to be in the same web application.

In JSR-286 :
JSR 286 (Portlet 2.0) defines a lifecycle for events, so that eventing is possible between portlets that are in different web applications.

By adding the following property in portal-ext, we can enable portlets to send and receive events from other portlets that are on different pages

portlet.event.distribution=ALL_PORTLETS

Step 1: Sender Portlet

portlet.xml

-----------

The portlet standard defines a way of telling the portlet container which portlet is responsible for sending an event.

Add this inside <portlet> tag:

<portlet-app>

<supported-publishing-event xmlns:x='http://liferay.com'>

<qname>x:empinfo</qname>

</supported-publishing-event>

</portlet>

<event-definition xmlns:x='http://liferay.com'>

<qname>x:empinfo</qname>

<value-type>java.lang.String</value-type>

</event-definition>

</portlet-app>

Step 3 : Set the event in process action:

javax.xml.namespace.QName qName =

new QName("http://liferay.com", "empinfo", "x");

response.setEvent(

qName,

"Hai You have received Event Data sent from Sender Portlet");

Step 4: Listner Portlet

portlet.xml:

-----------

<portlet-app>

<supported-processing-event xmlns:x='http://liferay.com'>

<qname>x:empinfo</qname>

</supported-processing-event>

</portlet>

<event-definition xmlns:x='http://liferay.com'>

<qname>x:empinfo</qname>

<value-type>java.lang.String</value-type>

</event-definition>

</portlet-app>

Step 5: get the EVENT:

This Even will be called after processAction as shown in the picture:

Lifecycle for IPC Event:

@javax.portlet.ProcessEvent(qname = "{http://liferay.com}empinfo")

public void handleProcessempinfoEvent(

javax.portlet.EventRequest request, javax.portlet.EventResponse response)

throws javax.portlet.PortletException, java.io.IOException {

javax.portlet.Event event = request.getEvent();

String value = (String) event.getValue();

System.out.print("value in process event>>>>>>>>>" + value);

response.setRenderParameter("empInfo", value);

}

2.3 Client-Side IPC :

There are 2 APIs for client side IPC.

Event generation (call from portlet A):

Liferay.fire('<eventName>', {
            name : value
});

e.g.
Liferay.fire('planTravel', {
            origin : 'pune',
            destination : 'mumbai'
        });

Event Listener ((call from portlet B):

Liferay.on('<eventName>', function(event) {

    });

e.g.
Liferay.on('planTravel', function(event) {
        showNews('', event.origin);
        showNews('', event.destination);
    });

3. Cookies

Other than the IPC mechanism, There is an easiest way to get the data between portlets on different pages called COOKIES.

But there are some limitations for cookies that it will not accept more than 4KB size datas and the biggest limitation is, the 20 cookies per server limit, and so it is not a good idea to use a different cookie for each variable that has to be saved

Portlet 1 :

To Set the Cookies through jQuery :

function setCookie(docURL) {

jQuery.cookie("cookieParam",docURL);

}

To Set the Cookies through java / jsp:

HttpServletResponse response = PortalUtil.getHttpServletResponse(

actionResponse);

Cookie cookieParam = new Cookie("cookieParam ", password);

response.addCookie(cookieParam);

Portlet 2:

To get the Cookies through jQuery :

jQuery.cookie("cookieParam ");

To get the Cookie through java/ jsp :

String sessionid = "";

Cookie[] cookies = request.getCookies();

if (cookies != null) {

for (int i = 0; i < cookies.length; i++) {

if (cookies[i].getName().equals("cookieParam ")) {

sessionid = cookies[i].getValue();

break;

}

Velocity Variables

2012-01-03T03:30:00.001-08:00

Macros
Variables/Methods

Theme specific variables

$theme_display
The theme display object

$portlet_display
The portlet display object

$css_class
The css class specified for the "color scheme" in the liferay-look-and-feel.xml

$css_folder
The absolute path to the css directory

$images_folder
The absolute path to the images directory

$javascript_folder
The absolute path to the javascript directory

$templates_folder
The absolute path to the templates directory

$full_css_path
The absolute path to the css directory

$full_templates_path
The absolute path to the templates directory

$css_main_file
The absolute path to the css/main.css file

$js_main_file
The absolute path to the javascript/javascript.js file

Company specific variables

$company_id
The company id (specified in Admin Portlet > Settings)

$company_name
The name of the company (specified in Admin Portlet > Settings)

$company_logo
The absolute path to the image of the company logo (specified in Admin Portlet > Settings)

$company_url
The URL of the company (specified in the Admin Portlet > Settings)

User specific variables

$user_greeting
The greeting that the user get's upon page visit (specfied in My Account or Admin > Users)

$user_email_address
The user's email address (specfied in My Account or Admin > Users)

$user_id
The user's id (set in My Account)

$language_id
The ID of the user's language (specfied in My Account or Admin > Users)

$time_zone
The users's time zone (specfied in My Account)

$user_comments
The comments related to the user (specfied in My Account or Admin > Users)

$user_login_ip
The IP address that the user is currently logged on from

$user_last_login_ip
The last IP address the user logged on from

$is_default_user
A boolean that specifies if the current user is the default one

$user_location
The user's location

$user_organization
The user's organization

$user_group
The group that the user belongs to

$user_birthday
The user's birthday

$is_male
A boolean that specifies if the user is male

$is_female
A boolean that specifies if the user is female

$user_name
The user's full name

$user_first_name
The user's first name

$user_middle_name
The user's middle name (if any)

$user_last_name
The user's last name

Dock specific variables

$show_add_content
Boolean set to specify that the add content link can be displayed

$add_content_text
The text that gets displayed if the add content link is enabled

$add_content_url
The url where the add content link points to

$layout_text
The text to be displayed for the "Change Layout" link

$layout_url
The url where the "Change Layout" link points to

$show_home
Boolean set to specify that the "Home" link can be displayed

$home_text
The text to be displayed for the "Home" link

$home_url
The url where the "Home" link points to

$show_my_account
Boolean set to specify that the "My Account" link can be displayed

$my_account_text
The text to be displayed for the "My Account" link

$my_account_url
The url where the "My Account" link points to

$show_page_settings
Boolean set to specify that the "Page Settings" link can be displayed

$page_settings_text
The text to be displayed for the "Page Settings" link

$page_settings_url
The url where the "Page Settings" link points to

$show_sign_in
Boolean set to specify that the "Sign In" link can be displayed

$sign_in_text
The text to be displayed for the "Sign In" link

$sign_in_url
The url where the "Sign In" link points to

$show_sign_out
Boolean set to specify that the "Sign Out" link can be displayed

$sign_out_text
The text to be displayed for the "Sign Out" link

$sign_out_url
The url where the "Sign Out" link points to

Page specific variables

$selectable
A boolean set that specifies whether a page is "selectable", meaning is it part of the navigation

$page
The current page/layout object

$the_title
The current title of the page

Navigation specific variables

$nav_items
An object that contains all of the pages that are part of the navigation. To set the styling for each navigation item, you must loop through the $nav_items object with a #foreach.

$has_navigation
A boolean set to whether or not there are any pages in the $nav_items object

These methods exist on each sub-object eg. when you're looping through the $nav_items object, you would do $foreach ($nav_item in $nav_items) and you would call $nav_item.METHOD_NAME()

isSelected()
This returns a boolean that indicates whether a navigation item is currently selected.

getURL()
This returns a string that contains the navigation item's URL.

getTarget()
This returns a string that contains the navigation item's target (as defined in the Page Settings).

getName()
This returns a string that contains the navigation item's page name.

hasChildren()
This returns a boolean that indicates whether a navigation item has children.

getChildren()
This returns an object that is has the same methods and variables as the $nav_items object, but contains the current navigation item's children pages.

Misc variables

$update_available_url
The url where the "Update Available" link points to

Utility macros

What's a macro?
A macro is a function that does text manipulation inside of Velocity. You can feed it parameters, and it will print out a string for you. Macros are not like traditional methods or functions, in that they don't return data, and while they can manipulate text based upon the parameters you pass in, it can only print.

#css(FILE_NAME)
Creates a link element like so: <link href="FILE_NAME" rel="stylesheet" type="text/stylesheet" />

#js(FILE_NAME)
Creates a script element like so: <script src="FILE_NAME" type="text/javascript"></script>

#language(LANGUAGE_KEY) Prints out the language string related to the LANGUAGE_KEY.
This replaces the following functionality: $languageUtil.get($company.getCompanyId(), $locale, LANGUAGE_KEY)

Liferay Portlet Configuration Files

2012-01-03T02:04:00.001-08:00

Configuration file:

liferay-display.xml: This file describes for Liferay what category the portlet should appear under in the Add Application window.

liferay-portlet.xml: This file describes some optional Liferay-specific enhancements
     portlet-name     The portlet-name element contains the canonical name of the portlet. This needs to be
                               the same as the portlet-name given in portlet.xml.
     icon                     Path to icon image for this portlet.
     instanceable    Indicates if multiple instances of this portlet can appear on the same page.
     struts-path       Tells the portal that all requests with the path ext/library/* are considered part of
                                this portlet's scope. For example, a struts-path of ext/library will give us access to
                                /ext/library/view in struts-config.xml, but not /ext/reports/view.

portlet.xml: This files has the below configuration options.
      portlet-name     The portlet-name element contains the canonical name of the portlet.   Each portlet
                                  name is unique within the portlet application. (This is also referred within Liferay Portal
                                  as the portlet id).
      display-name    The display-name type contains a short name that is intended to be displayed by tools.
                                 It is used by display-name elements. The display name need not be unique.
      portlet-class    The portlet-class element contains the fully qualified class name of the portlet.
    init-param:    The init-param element contains a name/value pair as an initialization param of the
                                portlet.
      expiration-cache: Expiration-cache defines expiration-based caching for this portlet. The parameter
                                 indicates the time in seconds after which the portlet output expires. -1 indicates that the
                                 output never expires.
      supports:    The supports element contains the supported mime-type. Supports also indicates the portlet
                          modes a portlet supports for a specific content type. All portlets must support the view
                          mode.
       portlet-info:    Portlet-info defines portlet information.

       security-role-ref : The securit-role-ref element contains the declaration of a security role reference in
                                      the code of the web application.


    Specifically in Liferay, the role-name references which role’s can access the portlet.(A Power User can personalize the portal, whereas a User cannot.)

Solr Integration with Liferay

2012-01-03T01:49:00.001-08:00

Solr Integration with Liferay

Solr is the popular, blazing fast open source enterprise search platform from the Apache Lucene project. Its major features include powerful full-text search, hit highlighting, faceted search, dynamic clustering, database integration, and rich document (e.g., Word, PDF) handling. Solr is highly scalable, providing distributed search and index replication, and it powers the search and navigation features of many of the world's largest internet sites. Refer to Apache Solr

This document shows how to integrate Solr within Liferay Portal. Note that Liferay portal version must be 6 or above.

Integration steps :

1 . Download the latest Solr from this link. Extract somewhere this zip file, and I will call this extracted folder as SOLR_HOME.

Download the solr-web-6.0.1.1 war file and deploy the war file in liferay tomcat server.
Copy the schema.xml file from the solr-web/WEB-INF/conf folder which is deployed and paste/replace in SOLR_HOME/example/solr/conf folder.
Change the solr url as follows in solr-spring.xml which is located in solr-web/WEB-INF/classes/META-INF/ folder.

Change from this content :

<bean id="solrServer"
class="com.liferay.portal.search.solr.server.BasicAuthSolrServer">

<constructor-arg type="java.lang.String" value="http://localhost:8080/solr" />

</bean>

to this :

<bean id="solrServer"
class="com.liferay.portal.search.solr.server.BasicAuthSolrServer">

<constructor-arg type="java.lang.String" value="http://localhost:8983/solr" />

</bean>

Note : 8983 is the default port for Solr.

Now shutdown the tomcat server.
Start the Solr server using the following command from SOLR_HOME/examle folder in command prompt/terminal.

Java -jar start.jar

Start the liferay tomcat server now.
Now add the search portlet in your home page and test your searches. When ever you search anything you can see some log info in solr server.

Note : By defaut Solr searches for the new webcontent, wiki, blogs... etc from the time Solr is integrated. To search the complete portal reindex all search indexs from the server administration which is in control panel.

A story of "Portlet" and "Servlet"

2012-01-03T01:35:00.001-08:00

A story of "Portlet" and "Servlet"

There are so many things which are very clear and understood but if someone ask, it become difficult to explain them in deep. The topic I am going to write today, is something like that. Hope, you'll enjoy reading it, as I am going to write this time full on text, no practical implementation.

The contents of servlets provide generally takes up the whole page in a browser (if you are not framing them), and portlets content are wrapped in a window and we can place multiple portlets on same page with one another and each can provide different content and functionality. A portlet behaves like a full fledged application. The portal can provide some house keeping functionality and secured single point of entries to all of the portlets on a page.

lets see first some differences among portlets and servlets

Servlets can provide complete web pages, whereas portlets only provide fragments. These fragments are then aggregated to form a complete web page by the portal.
Portlets aren't allowed to generated HTML code that contains tags such as base, body, frame, frameset, head, html, or title. The iframe tag can be used with caution.
The user cannot access a portlet directly using a URL in the way that a servlet is accessed. Instead, the URL points to the page containing all of the portlets on one page.
Communication between the web client and the portlets is performed through the portal.
Portlets can be provided with buttons or controls to manipulate the portlet's window states or portlet modes.
Multiple instances of a single portlet can be placed onto the same page.
Portlets support persistent configuration and customization.
Portlets also support user profile information.
Portlets support two scopes within the session; application scope and portlet scope .

Here are some similarities:

Servlets and portlets are web based components that utilize Java for their implementation.
Portlets are managed by a portlet container similar to a servlet container.
Both of these components generate content, which can be static or dynamic.
Both portlets and servlets have a lifecycle that is controlled by the container.
The client/server model is used for both servlets and portlets.
The packaging and deployment are essentially the same.
The manner in which the classes are loaded and the class loaders that perform the work are also the same.
Lifecycle management is similar.
The Request and Response semantics are also similar.

Advantage of Servlets over portlets-

Portlet aren't allowed to set the character set encoding of the response.
Portlet also aren't allowed to set the HTTP headers on the response.
Portlet cannot manipulate the URL of the client request to the portal.