Request for use cases: Layouts

[danielbeeke]

This issue is a follow-up to the discussion started in the #14

While discussing #14 we saw that it pieces together layouts and the ability to use CSS. We wanted to split that issue into sub issues.

Do you have use cases with layouts? Please add them here.

[danielbeeke]

Server driven UI Layouts

One that I have is the 'view' use case inside webapps. I want to be able to create a 'view' for something like this:

All the separate widgets I want them to be dash:Viewers or shui:Viewers. I have been working on server driven UI which I would like to see in the future being done with SHACL.

This could be made with the following components:

• A SHACL Editor, so that administrative user can create a SHACL shape with the purpose of viewing a graph
• A SHACL (View) renderer, the JavaScript library that renders the SHACL shape that has the purpose for viewing
• Layouts as a concept should be added to this spec so that we do not have to group things in groups and that into other groups, simulating HTML.

For my layout purpose CSS grid regions would work fine. Being able to define the region where a sh:PropertyGroup should be rendered. I imagine that my frontend app defines one or multiple layouts accompanied with a template that has all the HTML to achieve the wanted results with slots where the sh:PropertyGroup then would be placed.

The SHACL Editor can request those layouts at a specific URL and also which shui:Viewers are available. This makes a SHACL view shape, app specific from my perspective. We might also need a predicate which defines the intended app where the SHACL view shape should be used.

A little sidetrack here is that not every widget displays a predicate / object of the graph. Some just do something with the document IRI, such as the share feature. And others simply are, such as the back button, there is no data needed to render it.

I wonder if it would be possible to use the same rendering mechanism for forms and views. @tpluscode you have shared you think the mechanisms are different. In this issue I would like to find out what the differences are.

[bergos]

Editor vs. view is not that important for the first step, from my point of view. We should focus on the layout of the widgets. That would raise the following questions:

• How much of the layout needs to be defined in the shape to be reusable, and how much in the CSS of the page?
• What kind of information/properties do we need in the shape?
• How do we store the information? Can we use groups? If so, how? Do we use specific properties or generic ones for CSS?

[tpluscode]

@tpluscode you have shared you think the mechanisms are different.

I'd phrase it that the requirements are different. Forms are more rigid and repleacable. Pages are more base on specific use case

Given the screen above, I would create a web component for the layout itself. It would provide slots for containers where a SHACL-UI engine places specific components. I assign these slots by using sh:group. It's a little much for a comment, so let me share a gist instead: https://gist.github.com/tpluscode/a3c3772cc4f0088d0bfb6c53fb8ba467. This is by far not exhaustive but kinda shows what I have been doing so far

[bergos]

We should distinguish between the page layout and the layout of a single block. In most cases, the page layout is given by the application. Single blocks could be defined in an ontology - for example, address or full name.

For the latter case, it would be helpful to have properties or classes to add that layout information to the shape. Inline multiple properties is the use case I have in mind. Maybe there are more.

Mechanisms like slots can be used to place blocks in a page layout in specific areas. The IRI of the group must be used for linking. It's up to the component to use the IRI directly or via other abstraction layers. Other abstraction layers should not be part of the spec. Linking groups to slots in the shape makes the shapes less reusable.

@tpluscode Why should we distinguish between viewers and editors? Some applications may have the same requirements for editors. Also, it would just add unnecessary complexity to the spec. Let's keep it generic as long as we don't have problems.

[bergos]

If you support the proposal from my last comment, please vote :+1: till 2023-10-31, and we will continue with this approach.