Introduce UI.RenderingHint #411
Conversation
HeikoTheissen
left a comment
HeikoTheissen
left a comment
There was a problem hiding this comment.
The description is contradictory:
- A human-readable text should be read by humans, not interpreted by the frontend logic.
- If the frontend shall render the element in a special way, I would expect one annotation term for each such way, not one term with many possible meanings. Or at least a pre-defined list of allowed values for the term.
Good point :)
The definition might come from consumers themselves, so they would be responsible for establishing the key-function pair between client and backend, as such we don't really have a way to know or maintain that list. Nor do we want to. |
Can you give an example how a consumer would achieve a particular rendering? For example, a decimal property |
|
Sure, I'll make some adjustments |
| <Term Name="RenderingHint" Type="Edm.String" Nullable="false" AppliesTo="Property Parameter"> | ||
| <Annotation Term="Common.Experimental" /> | ||
| <Annotation Term="Core.Description" String="A short text, that gives a hint that the frontend logic can use to render specific UI elements." /> | ||
| <Annotation Term="Core.LongDescription"> |
There was a problem hiding this comment.
How would the UI interpret these values given that they do not come from a fixed list of allowed values but are arbitrary? Is there a BAdI-like mechanism in the UI code?
There was a problem hiding this comment.
I don't know how BAdi works :)
But the idea is that a reusable element of sort would register itself itself on the UI with the same name that should be then used for the RenderingHint.
UICode.registerHint("Thermometer", MyThermometer)
|
Is this the same as the CSS property |
|
It's related in purpose but it's not the same, so setting this here would be potentially misleading |
|
Discussion in Albatross: How about using custom vocabularies for that purpose? |
With this change we would introduce a new experimental annotation UI.RenderingHint, that can be applied to a property or a parameter.
The goal is to be able to tag some specific properties in the backend with a 'hint' to allow the frontend code to react to it in a specific manner.
For instance, consider a property containing rich text, we need to display that in a specific way on the frontend in different contexts (and yes, i'm aware of Common.TextFormat for this one, it's more to illustrate the concept).
In the end we might want to allow application to tag their specific repeating data structure in the backend and have dedicated controls / flow on the UI that should always be applied, thus why a generic term would be beneficial.