Among all previous releases, Liferay 7 is the most powerful in terms of feature richness, modularity, rapid and ease of development and lot more.
Over a period of time, Liferay became more powerful with every new release. Currently, Liferay 7 is the latest version with lots of new features. At the time of writing this article, 7.1 is the current version of Liferay.
As an open-source product, Liferay had maintained two flavors just like all previous releases. The only difference is, the EE (Enterprise Edition) is now called Digital Experience Portal – DXP, in short.
Liferay (DXP) is fully functional and loaded with features and other well known and industry-standard frameworks to build web and mobile apps along with web services quickly with good performance and ease of use. Below are the new and exciting features of Liferay (DXP).
Rich user interface
The first noticeable difference with Liferay 7 is the brand new user interface. The eye-catching difference you will see is – single page application (or SPA in short). Nowadays, more applications are moving towards a single page application for better user experience and, of course, to improve performance. (For example, a recent version of LinkedIn is revamped to single page application).
Liferay 7 supports SAAS-based UI development, which provides re-usability while building a presentation layer (with a theme). This eventually makes the creation of UI faster.
Till 6.2, Liferay was using Bootstrap 2.x. Liferay 7 is using Bootstrap 3.0 to build the UI and theme. This means all the latest features of bootstrap can be availed in Liferay 7.
Additionally, starting with version 7, Liferay brings Lexicon and Clay language to design UI with ease. Clay is building on top of Lexicon, a design language, and provides a common framework to build a UI interface.
Modular development with OSGi Platform
OSGi stands for Open Services Gateway Initiative. It is a set of standards that are used to develop a modular system in Java. Liferay 7 is re-designed to provide portal features on top of OSGi architecture.
You can develop Liferay plugins as OSGi modules and deploy them on an OSGI container. One more level down, the modules are consist of one or more components. Even the modules (applications) would be working independently. OSGi container will manage the life-cycle and dependency between the modules.
Not only that, till 6.2, Liferay was deployed on the server as a whole single web application. Due to this architecture, it was not possible to make the features ON and OFF. You have to either deploy the entire portal with all functionality or no functionality at all.
Starting with version 7, Liferay is re-designed to make many OOTB (out of the box) portlets and features in the form of OSGi modules. Apparently, you will get fine-tuned control to keep only desired (OOTB) modules or features ON while making others OFF.
This means it is possible to have the same modules with a different version available to the portal. This makes a perfect modular application (portal).
One of the best benefits of using OSGI in the Liferay 7 platform is to avoid classloader issues. In all previous releases, Liferay was managing the class loader among the plugins. Starting with Liferay 7, the plugins are replaced with modules.
Each module has components that work together as a bundle with a separate class loader. It’s the OSGi container’s job to manage each bundle’s bundle’s classloader, so there is almost no chance of getting ClassNotFoundException or NoClassDefFoundError.
Defining your custom classes for specific functionality (for example, portlet) is straightforward now with Liferay 7. Unlike the previous version, Liferay 7 allows registering the classes with @Component annotation declared within the same class. No more XML configuration required.
However, there are a few places where the old mechanism is still persisted. Also, at certain points, Liferay has made some API changes, which is not backward compatible. You can find those from here.
Liferay 7 is development environment agnostic. Due to the build tool chosen by Liferay 7, you can choose any appropriate development environment. Though Gradle, along with bnd tools, is the default way of building the application (modules) in Liferay 7, you can build tools like Maven or Ant/Ivy.
Searching in Liferay 7
For searching and indexing, Liferay 7 is using Elastic Search rather than Solr because it has various benefits like
- It is emerged to overcome a few of the limitations in Solr.
- Elastic search is more appropriate for cloud and distributed environments.
- It provides better performance for dynamic data.
- And you can count a few more.
This doesn’t mean Solr is less powerful. Also, this article is not for making a comparison between the two. The point is, Liferay has chosen it considering the future requirement.
Java 8 support
The major difference with version 7 is, you need Java 8. Liferay 7 will not run with the previous version of java other than 8. Also, Oracle has announced no further support for Java 7. So this is a good move to work with the latest java version.
Liferay provides a nice WYSIWYG editor called CKEditor to add content at different places. Starting with Liferay 7, a new editor called Alloy Editor developed on top of CKEditor. The beauty of this is, it provides an inline editing facility.
It means when you click on the element, you will see components like text, image, headers, links, alignments, etc. It is used at various places like web content, wiki blog, message board, etc.
Application Display Template – ADT
Previous versions of Liferay had minimal usage of ADT. Liferay 7 makes the use of ADT in many places. The clear advantage of this mechanism is that it can be changed by updating configuration instead of updating its code and deployment. In Liferay 7, you can use ADT on the following portlets.
- Asset Publisher
Service builder with declarative service
Declarative service is the mechanism to provide dependency run-time by OSGI container. With the help of a declarative service, we can define the dependency between the components/modules. OSGi container will make sure to set the dependencies before making the module active.
Service builder in Liferay 7 is now using declarative service to provide service builder specific dependencies. So Instead of using XXXLocalServiceUtil class, you can inject the object of XXXLocalService directly into other components. OSGi container will provide the dependency at run-time.
With the modular nature of the OSGi platform, Integration with other systems is much simpler with Liferay 7 than ever before. All previous releases have certain limitations while integrating with traditional plugins. Modules in the OSGI paradigm are more powerful than plugins in this regard.
You can connect Liferay 7 with other systems with various mechanisms like LDAP (Directory Server), OAuth, SAML, Social sign up, CAS, REST implementation, etc.., with ease.
You can refer to the official Liferay site to explore more about the new platform – Liferay (DXP) to develop a robust application.