Once upon a time, there was a wonderful project implemented by a customer that ended up in a failed website impossible to visit due to its poor performance. The End.

Although it may sound like a fake horror story, this is something that could happen if we don't implement our projects with the necessary knowledge. As many already know, Liferay offers different features and capabilities for implementing and extending the product. While Liferay is designed for non-technical users, it is also extensible and configurable for technical users. Therefore, during the analysis, design and implementation phases, we must understand Liferay’s approach and develop our extensions or integrations when necessary, for example avoiding implementing something predefined that the product already offers.

To avoid bad practices and help with your projects, we wanted to show you some bad decisions found on Liferay implementations and how they were solved mainly through out-of-the-box Liferay capabilities. Be aware that this would have been avoided with the knowledge provided by the Learning Paths and Courses in https://learn.liferay.com/education and all the solutions provided are part of this Courses.

We have called these “problems” items of our horror museum but don’t worry if you ever use something like this, life takes many twists and turns and sometimes it is the only option we have, but there are no more excuses since Learning Paths and Courses exists!  

Having said that, the items we have collected so far are as follows:
 

1 - Complex Information Architecture Based on Web Contents
 

The Problem

In this case, the main solution to manage complex relationships of data was built through Web Contents. Each type of asset or entity was implemented using web content structures. 

An example of this would be the following:

Let's suppose the customer had the following entities related to some classroom courses they wanted to offer and promote:

• Location: City or place where the Academy is located.

• Academy: Academy where the Courses will be given.

• Course: Courses given at the Academy.

• Offers: Offers provided related to the Academy or the specific Course.

The architecture was based on Web Content Structures like this:

• Location was a Category that will be added to the Academies. 

• Academy was a Web Content Structure that will have related Content as Courses

• Course was a Web Content Structure related to its Academy.

• Offers were repeatable fields explaining the offer that will be part of the structure of Academies or Courses. 

You might be wondering where the problem is because Web Content Structures have been a solution for these use cases since Liferay exists, right? Ok, let me explain. It is very common to start creating a simple solution that will get more complicated when customers extend their requirements. All of this will become a complex process for users whether create, update or maintain contents. For example, to create a new course will require to create the content, add the Academies as related Web Contents and finally add offers for the course by adding a repeatable field on the Course content or the Academy content depending on whether the offer is for the course or just in a specific Academy. 

As you can see, it is very easy to make a mistake and the UX of the content administrator is not helping to make it more intuitive. Additionally, it is difficult to search for offers, courses or academies and have a clear structure of all of these entities and their relationships using the default Liferay UI. Finally, it will be challenging to show all of this information in a page by using out-of-the-box display capabilities or even code/Headless APIs due to these relationships.

But we're not here to point out just problems but also to help you to know how to solve it and save cost and time.

The Solution

The solution recommended for this type of data structure is Objects. 

Through Objects, the model of data could be achieved for the different entities, having the equivalent of a relational database, manageable with Low Code capabilities using the User Interface (UI), without the need to implement code that requires deployments. 

Additionally, with Objects, the necessary Headless APIs for data management and integrations will be automatically exposed through a set of REST Services.

Following the same example above, Data Model would be as follows:

The Benefits

After using Objects, the customer obtained a high amount of benefits:

• It became much easier for non-technical users to contribute and to maintain content.

• Data could be shown using out-of-the-box features.

• No need to create difficult and static ADTs or Web Content Templates on Freemarker to show relationships between contents. Allowing to use other OOTB Liferay features like personalization.

• Data Model, Business Logic and Relationships between Objects were created without any lines of code, saving time and resources to create and support these capabilities.

• Administration will be managed using OOTB capabilities also, saving time and resources to create internal interfaces for administrators.

• Objects will generate APIs needed to manage all the entities. Again saving time and resources.

• Security and Support for all of these OOTB tools.

• Liferay would manage the tools to display data entries on pages avoiding ADTs.

• Actions, validations and flexibility on integrations extending Objects behavior using Client Extensions and APIs.

Additionally, visitors are now able to access the necessary data and enjoy much better  performance because of the simplified data model.
 

2 - Service Builder For All
 

The Problem

As you probably know, Service Builder is an object-relational mapping tool that can generate your code for the model, persistence, and service layers from a single xml file. Once generated, the code is completely customizable: you can write your own persistence code along with custom SQL if necessary.  While Service Builder provides a lot of value to our development, there is also potential for problems and we will look at several of those here.

The first problem is when we use this tool to add logic that is not related to the primary purpose of the service. For example, keeping code "just in case" like samples or old implementations. This will create code that is difficult to maintain and not useful for deployments in an environment.

Another problem we found at a customer was the incorrect use of Service Builder to handle integrations between external systems directly into the persistent layers. When we add logic into the persistent layers, we risk performance problems or even lose the persistence between data or synchronization between different systems. Logic should be included into the Service layer.

Finally, the last behavior detected with Service Builder is to use this tool to create all services using fake entities, just to create the scaffolding to create modules, even when the service or persistence layer is not going to be used.  

The Solution

For these cases, the solution should be to remove the useless code, use Service layers to add the business logic and avoid using the tool only because it is easy, there are more options to create different types of modules, liferay-sample-workspace can help with this. Additionally, it is a recommendation to use a dedicated service to manage a 3rd party integration in order to increase reusability, maintainability, and scalability.

The Benefits

After cleaning up these Service Builder modules, the customer gained the following benefits:

• Deployments are taking less time to complete.

• Maintenance of code is much easier as there is no useless code, and even more so in the case of Service Builder projects that were moved to Objects, because out-of-the-box capabilities are maintained by Liferay.

• Dedicated services to manage a 3rd party integration increased reusability, maintainability, and scalability.

Main improvements customers got here were related to maintenance and code updates; however, in those cases where the customer moved to Objects and used Liferay widgets to search and display data, the environment was prepared to leverage the improvements of each version update, such as new capabilities or even a better performance. 
 

3 - FreeMarker Abuse
 

The Problem

This is quite common because Freemarker is easy to use and very straightforward for developers to execute some code in a page without deploying modules, which makes this option very interesting. The problem is to use it when we shouldn't, as it will cause performance issues or even security risks.

Freemarker can be used directly on a page through Application Display Templates (ADTs), Web Content Templates, Fragments, etc. ADTs provide the ability to customize the way widgets appear on a page, removing limitations to the way your site’s content is displayed. With ADTs, you can define custom display templates used to render asset-centric widgets using Freemarker. Some widgets that can use ADTs are: Asset Publishers, Blogs, Breadcrumbs, Language Selector, Navigation Menu, etc. Another common use is through the Web Content Templates, showing content fields using your own code.

Freemarker shouldn’t be a bad practice at all, the problem is when we abuse the use of it in Liferay websites. Some of the examples found that are not a good practice are:

• Use of ADTs mainly for Asset Publishers with an abusive use of business logic. 

• Invocation of different services outside of Liferay using ADTs, making the logic and performance very low and with issues.

• Parsing XMLs - SAX. This was impacting the performance also.

• Use of ADTs or templates as common libraries of macros to load in every page. This was generating a heavy payload for each page, decreasing the performance or even creating a security breach.

As you can see, some consequences of an abusive use of Freemarker  are: a very low performance, issues and unexpected executions or failures messages on pages, OOTB capabilities like the personalization or responsive tools have to be resolved using JavaScript, decreasing performance, generating a bad experience and avoiding to use improvements on OOTB Liferay features in the future.

The Solution

The solution here is to use OOTB capabilities, APIs and Low Code/ No Code as much as possible. This means that the code will be supported by Liferay saving costs, time and avoiding dependencies on the custom code. 

Additionally, for those use cases where Liferay doesn’t provide a solution, the functionalities should be extended using Client Extensions or OSGi Module if necessary (only Client Extensions if you’re using Liferay SaaS). The recommendation (if possible) would be to use Client Extensions to avoid the dependency with Liferay Frameworks during an upgrade process.

Finally, to avoid decreasing the performance with ADTs and load pages with a lot of useless libraries, Objects are integrated with OOTB widgets to display data on pages as well as create forms and lists of contents and Fragments using custom styles and Look & Feel according to the customer. This would improve the performance and would reduce the amount of code to develop to display data. Following the example above we can talk about these features:

• Fragments: To show Links or Banners to Academies or Courses (be careful because we can also abuse freemarker too).
• Form Container: Forms to capture data. 
• Collections Display: List of data showing Academies, Courses, Cities or Offers.
• Search Blueprints: Helpful to filter searches or the data displayed on Collection Displays.

The Benefits

As you can imagine the main benefit the customer obtained here was a huge improvement in performance in the customer pages. The reason is because we will avoid all of these:

• Each time a template is rendered, the Freemarker engine must interpret, compile and execute it.

• If there are many custom or very complex templates, the rendering time grows exponentially.

• Adding logic to templates and/or using service calls (using serviceLocator) will increase the number of additional calls to the database.

• A large amount of code and data required will invalidate caches depending on the use case or even can provoke a memory overload.

In addition, the maintenance will be easier if we create our own modules to add all the logic on the backend, not in the template, or even there will be no maintenance if we can use Liferay out-of-the-box capabilities.
 

4 - Import/Export
 

The Problem

In this case, the solution to promote content between environments was to export/import LARS, which made the process difficult to achieve and risky (e.g., when importing into the PROD environment) due to the complexity of the relationships between contents.

The Solution

Recent versions of Liferay enhanced some features to make it easier to promote content between environments, e.g., using APIs for data, Batch Client Extensions or export/import Objects for data models, etc. The truth is that sometimes the recommendations involve changing the way to work with assets: testing widgets and design of contents on non-production environments but contributing the main content directly into the production environment. For this, there are some other tools that can help manage publishing or asset approval workflows, avoiding publishing something by mistake.

Additionally, Liferay’s Product Teams are working on an initiative to import/export between environments, leveraging the latest improvements to provide an UI tool for this. We will keep you updated on this tool when it is finally implemented but everything will be announced in the Release Notes where you can see the fully comprehensive list of everything new, changed, and indeed feature status changes like deprecated features, and breaking changes too. 

Lastly, we can talk about a beta tool called Data Migration Center. This tool is best suited to help with migrations from 3rd party systems to Liferay. We could, for example, export data on JSON on CSV from the 3rd party system and use that file to import data mapping columns and fields in Liferay though this tool. It is on beta but could be useful when the Liferay environment is not still on live.  

The Benefits

Working on the production environments to contribute content and data instead of moving content between environments save time and resources. If something should be tested, non-production environments will be helpful and the production environment can be used through its Publications or workflow tools to avoid mistakes. Of course, for those content that should be promoted, APIs resolve how to do it in a secure and reliable approach.

 

-----------------------------------------------------------------------
 

Conclusion

The first and most important recommendation is to acquire the necessary knowledge to implement a project on the latest versions of Liferay, taking advantage of all the new OOTB features, API, LowCode and client extension implementations provided for these versions. While you may have a lot of knowledge and experience with Liferay projects in previous versions, all of these bad practices were mainly related to applying an old or traditional way of implementing a Liferay project, instead of taking advantage of new features or approaches in the latest versions of Liferay. These practices ended up generating a lot of work, more API calls, duplicating framework calls or even creating applications that are provided out-of-the-box by Liferay.

That's why it's essential to get the necessary knowledge, but don't worry, you can find all these solutions along with everything you need for your projects by following the learning paths and courses at https://learn.liferay.com/education. By logging into this portal with your free account, you can track your progress and earn your own digital badges. 

In addition, you will find all the technical documentation on the same link to better understand a specific feature or capability. The course links will help but you can use the search bar to look up anything at any time.

Now you know where to find everything!
With the right knowledge, your projects will be a success!