Blogs
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
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.
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)
- The OSGI Module Framework.
- White Board Pattern (Service Registry - https://en.wikipedia.org/wiki/Whiteboard_Pattern).
- Abstraction.
- Factory Pattern.
- 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.