PoC - FDS folder support #4771

juanjofgliferay · 2025-02-28T09:12:36Z

Scope

In this PoC we want to test how to implement a way to navigate within folders inside a FDS, showing its contents. To achieve this, we may want to update the apiURL prop that it is used to retrieve the data for a given FDS.
Also, we need to identify which content is a folder

Concerns

We have a weak way to identify what it is a folder. Currently checking the entryClassName of an item to check if it contains *Folder. While this is valid for some Liferay content (Web Content : com.liferay.journal.model.JournalFolder, KnowledgeBase: com.liferay.knowledge.base.model.KBFolder ) it does not work with Objects out of the box.
Folder navigation is able to update the apiURL and retrieve new data, but we cannot ensure that the actual table schema matches the upcoming data.
Related to the previous one, creation menu could differ from the current to upcoming data.

UI

folder.mp4

juanjofgliferay · 2025-02-28T09:14:51Z

...tend-data-set/frontend-data-set-web/src/main/resources/META-INF/resources/FrontendDataSet.js

+			: apiURL;
+
+		const newApiURL = new URL(fullUrl);
+		newApiURL.searchParams.set('entryClassNames', item.entryClassName);


Updating only the entryClassName but can be anything, in the same way we are doing in loadData helper

yep, this function could even be a callback delegated to the FDS caller. FDS should not assume much about how data is structured.

For a PoC this is more than fine though.

In terms of the type of change for apiURL, it's very likely we'll need to modify the filter odata expression. This is an spetialization of the more general function that does an arbitrary modification on the URL, which allows us to make some assumptions:

Data about folders is consistently encoded in item field(s). Ideally, but not strictly needed:

in one single field,

always the same field. This simplifies computation of the relevant odata expression

Backend is able to consistently filter out data by such field(s), meaning

when such field is used to filter, backend will return elements that are immediate children of the provided "folder"

The above happens regardless the type of elements involved, and is compatible with the rest of parameters in the REST request (such as pagination, sort or other odata expressions connected with and operator)

Endpoint to read data won't change during component usage because only odata is allowed to change when browsing folders. This is in line with how filters and other parameterization work now.

Relevant odata expression can be provided on FDS invocation as part of additionalAPIURLParameters. This is a known requirement

We can consider other ways to "delegate" this function to the caller, yet control the way apiURL is mutated. For instance

Caller might just return an odata string that FDS appends via and operator

Caller could give the parameter that has to be added to the expression, very much like a filter, then FDS would handle the rest

I provide above items just for thought and discussion. We don't need to shape final solution yet, but instead we can prepare FDS to support this feature under such assumptions, fine tuning what we finally surface into component API later on.

juanjofgliferay · 2025-02-28T09:16:47Z

...nd-data-set-web/src/main/resources/META-INF/resources/cell_renderers/InternalCellRenderer.ts

@@ -85,6 +86,12 @@ export const INTERNAL_CELL_RENDERERS: Array<IInternalRenderer> = [
 		name: 'link',
 		type: 'internal',
 	},
+	{


Define renderer as internal for convenience. It could be a customCellRenderer in the CMS project

juanjofgliferay · 2025-02-28T09:17:27Z

...data-set-web/src/main/resources/META-INF/resources/cell_renderers/NavigationLinkRenderer.tsx

+	options: any;
+	value: string;
+}) => {
+	const isFolder = itemData?.entryClassName.includes('Folder');


This is another key aspect of the proposal. I see 3 points of discussion here

First, the isFolder implementation. Similarly to the apiURL mutation function, knowlege to distinguish between a container and a "leaf" item can be delegated to the caller. Of course, for PoC purposes we can provide a default implementation of this function. I don't see a clear way to implement a sensible default, perhaps what you propose is a great best effort way. Still I see the need to open component API to allow alternate implementations to be provided from the outside.

Second, make all this opt in. We need to preserve existing behavior, therefore, enabling container browsing is something that has to be explicitly configured. We need to determine the right way to do this from the perspective of the FDS react component, then translate that to custom//system data sets. We can deal with this later on.

Last, and more important, whether we need a dedicated renderer or not. Using a renderer means allowing folder navigation only in tables, which is fine for now but can be perceived as a bug shortly after we release this.

Opposed to FDS providing isFolder and openFolder functions (let's not consider how configurable can they be) is a clear need, I don't see NavigationLinkRenderer as a must here. Instead, such functions are just helpers for the view to do its job, being a view's responsibility to handle navigation appropriately. This is clearly seen in case we want to provide a custom view renderer.

This does not remove the obligation of FDS to provide folder support for its ootb views, but allows to do it in specific ways.

For the case of tables, we can still have this renderer (isFolder shall be hoisted to the top level though). But we might instead enhance ActionLinkRenderer to implement the navigation, and/or wrap the rest of ootb renderers with an onclick function to trigger it. Specific behavior will depend on product management, but also, we need to consider the fact that CMS may want to add their own custom cell renderer

Cards can provide an href/onclick handler that would implement navigation

Similar for List view, by adding some click handler on the title

juanjofgliferay · 2025-02-28T09:23:23Z

...data-set-web/src/main/resources/META-INF/resources/cell_renderers/NavigationLinkRenderer.tsx

+					onClick={(event) => {
+						event.preventDefault();
+
+						openFolder({item: itemData});


We can use the same renderer to navigate to a content (document, media, ...) using navigate utility once they provide an URI for it.

juanjofgliferay · 2025-02-28T09:23:57Z

...d-data-set/frontend-data-set-web/src/main/resources/META-INF/resources/views/cards/Cards.tsx

 					return (
 						<div
 							className="col-md-3"
-							key={
+							key={index}


Not related. Just removing ugly console warnings.

juanjofgliferay · 2025-02-28T09:31:51Z

...tend-data-set/frontend-data-set-web/src/main/resources/META-INF/resources/FrontendDataSet.js

@@ -566,7 +567,10 @@ const FrontendDataSet = ({
 				}
 				setDataLoading(false);
 			}
+			Liferay.on(EVENTS.OPEN_FOLDER, openFolder);


Open an ear just in case we need to listen for external change requests (breadcrumb)

How event emitter knows which item shall be provided to openFolder() function?

Also, we shall emit this event from openFolder() function so that external parties can know (e.g. update the breadcrumb). A consequence of this is that we must ignore events emitted by ourselves, or emit a different one.

Well, I would expect a dumb Breadcrumb component that only displays stuff and provides a callback.

({ active, href, label, onClick, ...otherProps }: IItem)

Whoever configures the breadcrumb (CMS Team) should know which ...otherProps will need when they click on an item so they can update breadcrumbs back and fire the event to FDS with the correct data (folderId x.e.)

…breadcrum)

dsanz · 2025-03-05T10:11:13Z

...d-data-set/frontend-data-set-web/src/main/resources/META-INF/resources/views/table/Table.tsx

@@ -667,6 +668,7 @@ function CellRenderer({
 						itemId={itemId}
 						loadData={loadData}
 						onItemsChange={onItemsChange}
+						openFolder={openFolder}


Couple of nits here:

This function shall be available throughout all visualization modes, probably we can expose it in the context

Naming might be a bit more general, folders is just a particular form of containers. I'm thinking about browsing organizations and users, portal instances and sites, or any other containment relationship we might want to support

openFolder is already available through context, just wanted to keep renderer lean 😃

About naming, we could change to a more generic openContainer or simply browse.

dsanz · 2025-03-05T10:37:47Z

...data-set-web/src/main/resources/META-INF/resources/cell_renderers/NavigationLinkRenderer.tsx

+	options: any;
+	value: string;
+}) => {
+	const isFolder = itemData?.entryClassName.includes('Folder');


This is another key aspect of the proposal. I see 3 points of discussion here

First, the isFolder implementation. Similarly to the apiURL mutation function, knowlege to distinguish between a container and a "leaf" item can be delegated to the caller. Of course, for PoC purposes we can provide a default implementation of this function. I don't see a clear way to implement a sensible default, perhaps what you propose is a great best effort way. Still I see the need to open component API to allow alternate implementations to be provided from the outside.

Second, make all this opt in. We need to preserve existing behavior, therefore, enabling container browsing is something that has to be explicitly configured. We need to determine the right way to do this from the perspective of the FDS react component, then translate that to custom//system data sets. We can deal with this later on.

Last, and more important, whether we need a dedicated renderer or not. Using a renderer means allowing folder navigation only in tables, which is fine for now but can be perceived as a bug shortly after we release this.

Opposed to FDS providing isFolder and openFolder functions (let's not consider how configurable can they be) is a clear need, I don't see NavigationLinkRenderer as a must here. Instead, such functions are just helpers for the view to do its job, being a view's responsibility to handle navigation appropriately. This is clearly seen in case we want to provide a custom view renderer.

This does not remove the obligation of FDS to provide folder support for its ootb views, but allows to do it in specific ways.

For the case of tables, we can still have this renderer (isFolder shall be hoisted to the top level though). But we might instead enhance ActionLinkRenderer to implement the navigation, and/or wrap the rest of ootb renderers with an onclick function to trigger it. Specific behavior will depend on product management, but also, we need to consider the fact that CMS may want to add their own custom cell renderer

Cards can provide an href/onclick handler that would implement navigation

Similar for List view, by adding some click handler on the title

dsanz · 2025-03-05T10:40:40Z

...data-set-web/src/main/resources/META-INF/resources/cell_renderers/NavigationLinkRenderer.tsx

+						<span className="c-pr-2">
+							<ClayIcon symbol="folder" />
+						</span>
+					)}


This bit signals an interesting requirement: we need to alter the way things are rendered when they are folders.

For table views we have more chances thanks to the renderers. For cards/lists, I don't have anything specific in mind.

Cards & List have the symbol property mapped to the schema.
ClayCardWithHorizontal icon defaults to "folder", but there is no design combining cards with folders and documents.

juanjofgliferay · 2025-03-06T07:21:20Z

@dsanz @markocikos Added a last bonus commit with a first attempt to move FrontendDataSet.js to .tsx .

juanjofgliferay commented Feb 28, 2025

View reviewed changes

juanjofgliferay added 6 commits March 5, 2025 08:33

Add custom folder/content renderer

009a518

Add callback to update apiURL

ab6167e

Add custom event listener to trigger folder navigation from outside (…

bee0714

…breadcrum)

Add custom renderer to All FDS view

e397a2d

Add fallback renderer

ae29156

Add custom translation key to the new renderer

10eef2f

dsanz reviewed Mar 5, 2025

View reviewed changes

juanjofgliferay added 3 commits March 6, 2025 08:11

Refactor. Wrap openFolder in a useCallback an declare before using it

db57c32

SF

20a72da

Move FrontendDataSet from JS to TS. First round

2a3ffad

juanjofgliferay force-pushed the cms/folder-support branch from 6d66046 to 2a3ffad Compare March 6, 2025 07:17

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

PoC - FDS folder support #4771

PoC - FDS folder support #4771

juanjofgliferay commented Feb 28, 2025

juanjofgliferay Feb 28, 2025

dsanz Mar 5, 2025

juanjofgliferay Feb 28, 2025

juanjofgliferay Feb 28, 2025

dsanz Mar 5, 2025

juanjofgliferay Feb 28, 2025

juanjofgliferay Feb 28, 2025

juanjofgliferay Feb 28, 2025

dsanz Mar 5, 2025 •

edited

Loading

juanjofgliferay Mar 5, 2025

dsanz Mar 5, 2025

juanjofgliferay Mar 5, 2025

dsanz Mar 5, 2025

dsanz Mar 5, 2025 •

edited

Loading

juanjofgliferay Mar 5, 2025

juanjofgliferay commented Mar 6, 2025

PoC - FDS folder support #4771

Are you sure you want to change the base?

PoC - FDS folder support #4771

Conversation

juanjofgliferay commented Feb 28, 2025

Scope

Concerns

UI

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dsanz Mar 5, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dsanz Mar 5, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

juanjofgliferay commented Mar 6, 2025

dsanz Mar 5, 2025 •

edited

Loading

dsanz Mar 5, 2025 •

edited

Loading