Custom Liferay Framework - Part 1

Understand the possibilities to write your own Liferay framework for any complex custom developed solution which could evolve with time like any other Liferay Out Of The Box Feature. The content is split between two blogs.

Part-1 | What & Why & When Custom Liferay Framework

Create your own Liferay Framework, Understand the possibilities to write your own Liferay framework for any complex custom developed solution which could evolve with time like any other Liferay Out Of The Box Feature.


Custom Liferay Framework - What?

Alright! This is where we set the context.

What is a Framework?
- an essential supporting conceptual structure to create something. The structure forms the base reference for the object which will be created.

We have come across a lot of Liferay out of the box frameworks such as Liferay Search, Liferay Permission Framework, Liferay's customization framework etc. They abide to the contract of what frameworks are, they utilize the technology stack present with Liferay Ecosystem and few design patterns extensively. They are categorized as Liferay OOTB Frameworks/Features.

Similar to the OOTB frameworks, it is absolutely possible to create our own Liferay Framework. The Liferay Ecosystem supports this already and since it is custom built, we can very well categorize them as Custom Liferay Frameworks

​​​​​​​Every Custom Liferay Framework will be specific to the functionality it is developed​​​​​​ as it is the case with Liferay OOTB Frameworks/Features. The actual question we should be asking ourselves is, how exactly writing a Custom Liferay Framework going to help us.

 

Custom Liferay Framework - Why & When?

In general, frameworks are created to addresses few identified problems. We do have a lot of such frameworks utilized in Liferay's Technology Stack already. So why do we need a custom framework in Liferay?

Liferay has evolved a lot during the last decade and it continues to march forward. But there is always a challenge associated with Custom Developed Modules in Liferay as opposed to Liferay Out of the Box Features/Modules. Challenges in performance, design, customization capabilities, scope to expand and in maintaining them. The effort spent is always going to be higher comparatively.

These are common software problems which are found frequently in the software world. But during custom development in Liferay we tend to reinvent the whole wheel instead of looking at what capabilities the product already has to help us out. This eventually results in a what we can possibly call as a product abuse.

Product abuse could result in poor performance of the Liferay Portal in itself which eventually result in Customer dissatisfaction and a broken portal implementation in hand.

This is where creating our own Custom Liferay Framework can enable us. A framework using the existing technology stack of Liferay and hence the name :). The perks of a custom framework could be:

  • Good application/widget design.
  • Reduced complexity.
  • Easy and defined way for future customization and expansion.
  • Unified implementation.
  • Scope to expand & evolve.
  • Increased performance owing to reduced complexity and junk implementations​
Note: Unified Implementation helps us avoid inconsistent junk implementations, since we will define a way to implement, customize and extend the functionalities like how Liferay does. For Example: To implement Liferay Search, we create few classes, implement few interfaces and extend few classes. This is exactly why they are called as framework (defines the frame to work). No matter who implements, it's going to look and work the same. This contributes to performance indirectly as well.

We can be sure on why it a Custom Framework is required. 

​​​​​​​But, when should we opt to create a Custom Liferay Framework? Can we ideate a Custom Liferay Framework for any kind of implementation?

​​It might not be a wiser decision to create a framework for every implementation. Ideally it will be more efficient for requirements with complex functionalities or requirements which are simple at the time of conception and can expand and evolve in the future. These could be the ideal scenarios where we can implement or build a Custom Liferay Framework.

For a simple custom functionality, the effort to implement a Custom Liferay Framework will be on the higher end always.

Best Practice: Its always wise to use out of the box features and tweak them to requirement.
Custom development to be chosen only when the customization of Liferay Out of the Box feature prove to be complex and ambiguous.

Liferay DXP - Under the hood

For the final section of this blog let us re-iterate on whats under the hood of our Liferay Technology Stack or Liferay Ecosystem. This could very well help us understand how the Liferay way of implementation could help us write our own framework.

Under the hood the core engine that drives everything in the DXP era is our OSGI Framework. The remaining credits pertaining to all the out of the box features/frameworks such as Liferay Permission Framework, Liferay Search Framework,Service Builder, Liferay Customization Framework, Liferay Forms etc; belong to none other than few Java Design Patterns.

OSGI Framework in combination with few design patterns has enabled Liferay with the possibility to build modules, frameworks with less complexity and increased customization capabilities.

Below are the list of few design patterns/concepts (Java/OSGI) which are utilized in Liferay Ecosystem under the hood: (Apologies!!! If your favorite pattern is missed below)

  1. The OSGI Module Framework.
  2. White Board Pattern (Service Registry - https://en.wikipedia.org/wiki/Whiteboard_Pattern).
  3. Abstraction.
  4. Factory Pattern.
  5. Proxy Pattern and many more...

Of-course these design patterns are utilized to address few identified programmatic problems. Hence an appropriate software design pattern can be chosen with respect to the requirement/problem in hand. The intention behind the blog is not to provide a ready made solution. But, to enable the perspective of how a framework could be built for any custom developed module/custom functionality in Liferay, preferably complex ones.

The important couple of concepts/patterns in OSGI Module that will help us majorly are the Whiteboard pattern, Abstraction and Factory design patterns. Every service which is created in OSGI by default adheres to Factory design pattern and the Whiteboard pattern. Whiteboard pattern is the core concept based on which the Service Registry in OSGI works.

These simple patterns are enough to help us in creating our own Custom Liferay Framework and with this idea let us try to implement our own Custom Liferay Framework over a simple feature.

​​​​​​​​​​​​​​Implementation continued in Part-2 of this blog series.

Blogs

How to custom any class in portal-impl and portal-kernel (example com.liferay.portal.util.PortalImpl or com.liferay.portal.kernel.portlet.FriendlyURLResolverRegistryUtil)

Hello Mo Nguyen Tan,

Customizing Liferay Portal Impl falls under extensive customization (ext). Which ideally is not the best practice. It might end up breaking the portal implementation and it might be as well a non-compliance.

Strongly suggest you to implement customizations on the application/feature level. It is good to leave the portal-impl as it is. ​​​​​​More over this blog tries to enable you to create your own Liferay framework and doesn't hint about performing extensive customizations.

Thanks to Maharajan Paramasivan for the response, About using ext to customize portal-impl's classes is not a good idea but in some cases it is imperative to use examples to meet actual customer needs. In previous versions of Liferay (for example, 6.2) I also used ext to customize, so when upgrading to Liferay 7 I also need to keep the previous customizations to meet the application upgrade. Regardless of the good or bad problem when customizing portal-impl using ext, I want Maharajan Paramasivan to give feedback on how to do it, thanks!