GitHub user xuang7 created a discussion: Unify Project Landing/About Pages via
Block Composition
### Motivation
Today, there are multiple Texera-based deployments, each maintained in a
separate repository with its own customized landing/about page. The goal is to
move toward a single unified repository in which each project's page is
generated from:
- Shared application code
- Project-specific configuration and content
The main challenge is that these pages do not all have the same requirements.
Some are primarily static and contain project descriptions and branding, while
others dynamically load resources such as datasets and workflows. We therefore
need a model that can support both static and dynamic content.
### Proposal: Compose Pages from Blocks
Instead of storing an entire page as project-specific code or as one large HTML
document, define each project page as an ordered list of 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
```
The page definitions could be stored as configuration files in the shared
repository or as records managed through the application. The storage and
editing model still needs to be determined.
The shared 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 assumes that datasets and
workflows can be tagged. A project would surface its own resources by assigning
the corresponding project tag to them.
The block model primarily provides flexibility in page content and composition.
We should also discuss whether layout should be configurable, or whether the
application should provide a small set of shared page templates that projects
can choose from.
#### Security Considerations
The primary security concern is cross-site scripting. If a project can store
arbitrary HTML, including scripts or event handlers, and that content is
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 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, combined
with tag-driven resource lists, is the right foundation for retiring the
current per-project repositories, as well as on the appropriate level of
content and layout flexibility and any related security or maintenance
considerations.
Please feel free to share any suggestions. 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]
