GitHub user xuang7 edited a discussion: Support Customizable Landing/About
Pages via Block Composition
### 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
```
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!
GitHub link: https://github.com/apache/texera/discussions/6726
----
This is an automatically sent email for [email protected].
To unsubscribe, please send an email to: [email protected]
