Support customizable landing/about pages via block composition

[xuang7]

Motivation

To support customizable landing and About pages, one possible approach is to define each page through shared application components and page-specific configuration.

These pages may have different requirements. Some are primarily static and contain descriptive content or branding, while others dynamically display resources such as datasets and workflows. We therefore need a model that can support both static and dynamic content while keeping the implementation reusable and maintainable.

Proposal: Compose Pages from Blocks

Instead of implementing each page as custom code or storing it as one large HTML document, each page could be defined as an ordered list of reusable blocks stored as data.

Possible block types include:

• content: static text or branding, using Markdown or another constrained content format
• dataset-list: dynamically displays datasets matching a configured tag
• workflow-list: dynamically displays workflows matching a configured tag
• image
• hero
• Other reusable block types added as needed

For example:

project: Project A
blocks:
  - type: content
    content: |
      # Welcome to Project A
      Project description and other information.

  - type: dataset-list
    tag: project-A

  - type: workflow-list
    tag: project-A

Example of the current landing page represented as blocks:

Example block-selection:

Page definitions could be stored as configuration files in the codebase or as records managed through the application. The storage and editing model still needs to be determined.

The application would render the blocks in order. Static blocks would display their stored content, while dynamic blocks would fetch and display live resources based on their configuration. This approach assumes that datasets and workflows can be tagged. A page could surface relevant resources by referencing the corresponding tags in its block configuration.

The block model primarily provides flexibility in page content and composition. We should also discuss whether the layout itself should be configurable or whether the application should provide a small set of reusable page templates.

Security Considerations

The primary security concern is cross-site scripting. If arbitrary HTML, including scripts or event handlers, can be stored and rendered on the shared authenticated domain, malicious code could execute within the application’s context. This could potentially expose session information, steal tokens, or perform actions on behalf of another user.

The block-based approach reduces this risk by limiting page authors to predefined content types and application-owned components rather than allowing arbitrary HTML or JavaScript.

Dynamic resource lists should also be permission-aware. They should only display resources that the current viewer is authorized to access, so private datasets or workflows are not exposed through a shared page.

Feedback would be especially helpful on whether block composition with tag-driven resource lists is an appropriate foundation for customizable pages. Thoughts on content and layout flexibility, security, and maintenance are also welcome. Thank you!

[chenlica]

@xuang7 Please add 1-2 screenshots.

[sshiv012]

Is this intended partly for domain-specific or “flavored” Texera deployments? It seems complementary to #6727: a flavor could provide its own landing-page block configuration alongside its patches, services, and deployment configuration. For that use case, codebase configuration seems useful for versioning and reproducible deployment, while application-managed records could support later admin customization. Would a configuration-first model with optional admin overrides fit the intended direction?

[aglinxinyuan]

I think what you're describing is a common pattern in a CMS (Content Management System) like WordPress. When someone deploys a new website, the admin typically starts by selecting a template or theme that matches the intended use case—such as e-commerce, a blog, or a portfolio. That template provides a default site structure, page layouts, color scheme, and placeholder content.

From there, the admin customizes the individual pages and content to fit their specific needs.

[xuang7]

Supporting domain-specific deployments is indeed a shared motivation with #6727, but the two mechanisms would remain independent. This proposal focuses only on configuring pages composed of predefined application components.

Regarding where the configuration should live, I agree that configuration files in the codebase are the right starting point, mainly because they provide version control and support reproducible deployments. The CMS-style in-app editing that @aglinxinyuan described could be added later as an override layer on top of the default configuration.

[chenlica]

The feature discussed in #6727 is more about some "application module" that can be added to a deployment (similar to PostGIS for Postgres). The feature in the current discussion is about how to let each deployment configure some components (e.g., a parameter "configuration_parameter" for Postgres). We can decide whether the component should be part of the codebase.

[chenlica]

@xuang7 After we agree on a design in this discussion, you can create a PR.

[xuang7]

Sounds good!