Context aware Data Set
During the recent Devcon, I've shared with the audience a workaround I've found in order to be able to use Liferay Data Sets for more use cases than the one it supports out of the box.
https://github.com/fabian-bouche-liferay/fetch-context-contributor-cx
It consists of a global JS client extension + a fragment to include on the pages where you need to use the hack.
About Data Sets
You'll learn more about Data Sets in the Liferay Documentation about Data Sets. But in a nut shell, Data Sets allow you to build interactive tables against a Liferay API.
The concept of table is straightforward: in the Data Set configuration, you get to select which fields of the API you'd like to display as columns.
Regarding interactivity, you can filter, search and sort records + you can associate creation and item contextual actions which translate either to dynamic links, modals / side bars or API calls.
Adding Context to Data Sets
The 2025.Q4 Liferay release brought a new capability which allows you to assign a state to the Data Set through the URL: https://learn.liferay.com/w/dxp/low-code/data-sets/managing-data-sets#preserving-and-sharing-how-you-view-a-data-set
Selected filters, sorting, search, pagination is preserved.
However, this does not allow you to add static (non changeable context) to the Data Set.
Let me give you a few examples.
Related Data Set in a Display Page Template
This is the use case which made me start the investigation / research which led to this blog post.
Imagine you have created two related Liferay Objects.
During Devcon, I considered Airports and Routes.
You're displaying the Display Page Template of a given Airport and you'd like to display a Data Set of the related outbound Routes.
Out of the box, Liferay does not let you configure a Data Set which is going to display only those related to the displayed entry.
The Data Set Hack I've built makes it possible to implement such configuration as seen below.
Out of the box, Data Set configuration does not let you include a dynamic query parameter like this {displayedEntryId}. This parameter is computed before sending the request if the liferaydds=true parameter is present.
This liferaydds parameter is here to prevent this variable replacing logic from happening in places where it shouldn't. If I've shown this hack to you earlier this year, then this was not there from the begining. :)
Static date filters
Now there's a second very common use case: let's assume you want to display only todays or last weeks tickets in a Data Set?
Data Set configuration lets you configure date filters, indeed, but the notion of "today", "last week" is dynamic. So unless you login as an admin every day to update the filters, you won't be able to implement this.
Well, technically, you could have some CRON task regularly hit the Data Set Admin APIs in order to update the dates in the filters. But I wanted something easier to use.
So, in addition to the {displayedEntryId} from above, I've added support for a bulk of date variables:
{now}is now{today}is today (midnight), in your local timezone{today +gmtoffsethours}is today, GMT{now -1d}is 24 hours ago{now -1h}is 1 hour ago{now -30m}is 30 minutes ago{now +1d}is in 24 hours from now{now +2h}is in 2 hours from now{now +20m}is in 20 minutes from now{today +1d}means tomorrow{today -1d}means yesterday
And while we here
And I thought, what else could we include?
So I added a bunch of additional context variables:
{userId}the current userId (I'd like to see only my records){userName}the name of the current user{languageId}the current user's session's locale{companyId}the id of the virtual instance{siteId}/{scopeKey}the id of the site current site{portalURL}the portal URL{layoutURL}the URL of the current page{accountId}the currently selected account entry ID (only if you are on a commerce channel)
Watch out for evolutions in Liferay. You might not need my hack in the future anymore if this gets added to the roadmap.
Nevertheless, if you are currently using Liferay DXP 2025.Q1 or beyond, then you can try this out right away.
In a next blog post, I'll tell you how I thought I could abuse this hack in order to share the data set context with neighbor client extensions displayed on the same page.
