Replies: 5 comments 3 replies
|
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? |
|
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. |
|
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. |
|
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. |
|
@xuang7 After we agree on a design in this discussion, you can create a PR. |
|
Sounds good! |
|
Following up with a proposed design and a working prototype. I validated the approach by rebuilding a landing page from configuration. Configuration FormatEach page is represented as a JSON document containing a schema version, an optional theme, and an ordered list of blocks. Each block contains:
{
"schemaVersion": 1,
"theme": {
"accentColor": "#0f766e",
"contentMaxWidth": "1200px"
},
"blocks": [
{
"type": "hero",
"config": {
"title": "Project A",
"subtitle": "...",
"backgroundImage": "assets/hero.png"
},
"layout": {
"width": "full",
"spaceBottom": "md"
}
},
{
"type": "stats",
"config": {
"template": "Browse {datasets} and {workflows} shared by our community.",
"counters": [
{
"key": "datasets",
"entity": "dataset",
"label": "public datasets"
},
{
"key": "workflows",
"entity": "workflow",
"label": "workflows"
}
]
}
},
{
"type": "dataset-list",
"config": {
"title": "Featured Datasets",
"description": "...",
"source": "ids",
"ids": [12, 34]
}
}
]
}ArchitectureThe page configuration is stored in site_settings, with a versioned default defined in default.conf. The frontend reads and validates the configuration, applies the page theme, and renders each block using application-owned components. Configuration updates go through the ADMIN-only settings endpoint. The backend validates the document against an allowlist of block types and per-type field schemas and enforces a maximum configuration size. Dynamic blocks use the existing search and hub APIs, so the current permission filtering remains unchanged. Invalid blocks are handled independently, allowing the rest of the page to continue rendering. If the full configuration is invalid, the page falls back to the built-in default. Block Types for v1The initial block types may include:
List blocks may use sources such as:
Layout and StylingPages use an ordered, single-column block flow. Each block supports predefined layout options, such as width, top spacing, and bottom spacing. Page-level theme options may include colors, content width, and page padding. The configuration does not allow custom CSS, JavaScript, or uploaded frontend code. Prototype Demolanding-page.mov |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
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:
For example:
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!
All reactions