🖼️ Add persistent per-view layout modes (table / tiles / gallery)

[Rello]

Motivation

• Implement optional gallery and tile views, as available in SharePoint
• Both views are using the first column to get the picture url for the preview
• Tile is only showing the picture plus its title from the 2nd column. Use case: Index pages
• Gallery view is showing all additional columns from the current view. Use case: Product catalogue or inventory
• Provide persistent, per-view layout modes so users can choose between table, tiles and gallery and have that preference stored with the view.
• Expose layout selection in the View settings modal and apply the persisted layout automatically when a view is opened, while keeping backward compatibility (missing/old values => table).

Implementation

Source data

Tile View

Gallery View

Settings modal

Sharepoint reference

[Rello]

@jancborchardt as new layouts will be relevant for your opinion

[jancborchardt]

@marcoambrosini one for you, check it out. :)

@Rello do you have reference screenshots from Sharepoint as you mention?
List and Gallery view currently also look very similar (with Gallery in need of some design improvement).

[Rello]

@marcoambrosini can you please have a look now? the PR was now implemented and tested on the branch and I added the actual screenshots from the working app

[AIlkiv]

@Rello
I’m planning to introduce a Kanban layout, which will also require additional columns. This led me to consider an alternative approach: instead of continuously adding new dedicated columns for each feature, we could introduce a single settings column (stored as JSON text).

This settings field would encapsulate various configuration attributes, allowing us to store extensible metadata without inflating the schema.

I see this as a more scalable and maintainable solution, as it avoids excessive schema growth and simplifies future migrations.

Example:

settings =
{
layout: ...,
card_background_source: ...,
card_title_source: ...,
}

[Rello]

Hi,

thats a good idea. But I would keep the dedicated layout column for performance. there, your kanban would then also go in. but to derive the pure layout of a view (where table might be the standard) it would be overhead to parse the settings json every time

[AIlkiv]

Hi.
Are you planning to replace the card_background_source and card_title_source columns with a single settings (JSON) column, or should I try to push that change into your PR?

[enjeck]

Just confirming that the state when there's no image is designer-approved? Here, for a tile view, I don't see why say "No image" instead of just text-based tiling like in https://media.geeksforgeeks.org/wp-content/uploads/20231218102144/Screenshot-2023-12-18-102058.png, for example.

cc @marcoambrosini

[enjeck]

What happens if this column is deleted after being set as the background source?

[enjeck]

If a column isn't selected to be accessible in the view, it shouldn't be shown as the background or title source:

[enjeck]

both in the frontend and validated in the backend too.