1/05/2015

Liferay DEVCON 2014 - Introducing Portlet 3.0 - Neil Griffin




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

Liferay DEVCON 2014 - DevOps Best Practices with Liferay - Brett Swaim




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

11/12/2014

Liferay 7 : Elasticsearch vs. SOLR

Liferay 7 will switch from lucene to elasticsearch as the standard search provider. But what is elasticsearch and why is it a good idea to have it in your liferay installation ? And where´s the difference to SOLR, which is already a good alternative and can be integrated into Liferay pretty easily ?
Let´s take a look at the google search queries from the last years to see how many people care for which search technology.



As you can see, elasticsearch surpassed SOLR in the last year. Question is: why ? Let´s talk a little about both technologies to see if there is an actual technological explanation for what we see here. Note: There are so many ways to compare both technologies that there is an own site just for that. If you want to dig down really deep I would suggest taking a look here: http://solr-vs-elasticsearch.com/

This video is a nice introduction to SOLR:




And this one is a good one about elasticsearch:





Consider having more requirements to your liferay search then just providing a search field. Consider specifying how your search behaves, which data types will be indexed and consider a clustered, fail-save environment with a lot of data.

If you have a lot of data, that you could also group into several indexes then you need "shards". A shard is an index of its own that can be accessed by your search provider. SOLR and elasticsearch allow you to define shards and also allow you to define schemas for each shard. Using shards you can define a shard for the users, another one for documents and a third one for car information. All shards can have different attributes that you can search for. Those attributes will be defined either out of the box (SOLR and elasticsearch support this) or you can write your own finegrained schema file. This approach is my choice for huge liferay projects.

You can even distribute your shards over several machines. Elasticsearch does this ootb, SOLR has the so called SOLRCloud, that supports distribution.

Elasticsearch also allows you to define replicated shards and thus supports securing your applications search data a little better then SOLR does. Both search providers allow you to process JSON documents, SOLR also allows you to work with XML or CSV.

Elasticsearch is made for the cloud, and it supports big data integration with the "ELK stack" - Elasticsearch, Logstash, Kibana, as a Big Data analysis solution. Visit the following sites to learn:

Logstash: http://www.elasticsearch.com/products/logstash/
Kibana: http://www.elasticsearch.com/products/kibana/

While going through all the features that both search providers have, one could get the impression that there is no killer argument for one side of the "search battle". Both SOLR and elasticsearch can be used to perform the same things. While it is a very good idea from the liferay crew to integrate elasticsearch instead of a simple lucene index, there is no technological reason not to use SOLR. Elasticsearch seems to be a little easier to use out of the box and it is definetely a trending topic. Those might be two key points that lead to liferay´s decision to integrate it instead of SOLR.

So the bottom line is: Take the technology you prefer, there is no need to migrate to elasticsearch as long as you don´t need one of the central features they´re offering that SOLR doesn´t have. For all those of you who never thought about the search technology used by liferay under the hood: You will be able to distribute your indexes and have a much faster search then before.

Since elasticsearch is based on lucene it will be interesting to see how and if a migration will be possible.


Do you need expertise in SOLR, elasticsearch and / or liferay ? 
Just Contact me !

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

11/11/2014

Liferay 7 : Web Content Diffs

One very nice new feature of the upcoming Liferay 7 will be Web Content Diffs. Like a SVN history comparison tool it will allow you to compare two web content versions, thus making approving new web content versions much easier. This new feature can be used in the workflow portlet and in the web content admin section. If you want to read more, then you can read here:

Web Content Diffs should look something like this:



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.

11/10/2014

Liferay 7 ... first look at M2

Just started to take a look at Liferay 7 M2. So far the only issue I had was that I had to upgrade to Java 7. I will write some more blog entries in the next days about Liferay 7 and all its new features like
  • Bootstrap 3
  • ElasticSearch 
  • Web Content Diffs
  • Develop complete portlet as OSGi modules
  • ... stay tuned !

You can find all my posts about Liferay 7 here.












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

11/05/2014

Embedding a Liferay Portlet in a Theme

If you want to include a portlet in a liferay theme you can just use the following snippet:
$theme.runtime("your-portlet-id")
Your-portlet-id can be a static id or an instance id.

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

Geocoding with Primefaces

Primefaces offers an official primefaces google maps implementation. With the new primefaces 5.1.2 it also allows you to use geocode with the following two new methods:
  • geocode(address)
  • reverseGeocode(lat, lng)

This is an example from the official primefaces showcase:
 <p:gmap id="geoGmap" widgetVar="geoMap" center="#{geocodeView.centerGeoMap}"type="ROADMAP" model="#{geocodeView.geoModel}">
    <p:ajax event="geocode" listener="#{geocodeView.onGeocode}" update="@this" />
 </p:gmap>

The java code for the normal geocode request looks like this:
public void onGeocode(GeocodeEvent event) {
List<GeocodeResult> results = event.getResults();


if (results != null && !results.isEmpty()) {

 LatLng center = results.get(0).getLatLng();
 centerGeoMap = center.getLat() + "," + center.getLng();

 for (int i = 0; i < results.size(); i++) {

  GeocodeResult result = results.get(i);
  geoModel.addOverlay(new Marker(result.getLatLng(), result.getAddress()));

  }

 }

}
Continue reading here: http://blog.primefaces.org/?p=3339 

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

Liferay IDE 2.2 has been released

Those of you who work with liferay every day will like the news that the Liferay IDE has been updated to 2.2.  Features include:


  • Complete AlloyUI integration including type inference for AlloyUI, YUI and jQuery (called tern.java). So for the first time ever you can press SPACE+STRG to get code completion for alloyUI script. You´ll get code assist for all methods and objects, including those for static liferay methods.
  • The same goes for jquery: You will get code assist for jQuery, too.
  • Better CSS Support
  • A lot more of those improvements, including action method completion !
  • Eclipse Assistance to navigate between generated Service classes, Wrappers and JSPs.
  • Faster and rewritten Eclipse Editors
  • Feature to import liferay preferences from workspace to another
  • ... and many many more.

Try it out and visit the official blog post here:





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

11/04/2014

How to show the liferay search portlet in a liferay theme

To Include the liferay serach portlet in a liferay theme, you can just add the following :
<div id="portal-search" style="float:right">             
  $theme.search()
</div>

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

JSF 2.3

JSF 2.3 has been approved (https://weblogs.java.net/blog/mriem/archive/2014/09/23/jsf-23-has-been-approved) and the work on the new iteration has begun.

The specification summary reads as follows:
This JSR aims to improve the clarity of the existing JavaServer Faces
(JSF) specification and introduce a small, targeted set of new features
as directed by community contribution. To summarize, JSF 2.3 will target small scale new features, community driven improvements, and platform integration.

These are the new features we can expect:
- Ajax method invocation: Ability to make direct CDI method invocations from Ajax
- Multi-field validation
- Ability to @Inject FacesContext
- EL Performance Optimizations
- Cross-form Ajax Clarifications


The final release should be in Q3, 2016, so we might stick a while with JSF 2.2 ...

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