1

I am trying to realize a UI5 app, where visibility and editability of each control in my view is controllable through a customizing table in our SAP ERP.

At this time my idea is a entity type which contains these information for each property. Therefore my entity does have two additional properties for controlling visibility and editability. E.g.:

  1. Persnr
  2. PersnrVis
  3. PersnrEdit
  4. Lastname
  5. LastnameVis
  6. LastnameEdit
  7. ... (and so on) ...

This concept works, but it will bloat my entities. For me it looks more like a workaround, than a elaborate strategy.

Does someone have experiences which such a situation?

チーズパン
  • 2,752
  • 8
  • 42
  • 63
srz
  • 129
  • 1
  • 1
  • 11
  • We are storing the configuration in a separate entity which has a relationship to the actual entity. You can `$expand` the config if needed, and you can also load the `ConfigSet` in a separate request (and only once, since it wont change). – Marc Feb 29 '16 at 10:56
  • That makes sense to me. But how do realize the association? If I have a property 'Pernr' with a value '00000001' and a entityset 'ConfigSet' with the properties 'Visible' and 'Enable'. Do you use the Pernr '00000001' as a key for the association? Therefore I would have a ConfigSet for each personell number. But I only need the config per property. – srz Mar 01 '16 at 07:18
  • The key should be `Pernr`, not THE Pernr – Marc Mar 01 '16 at 07:44
  • 1
    Can you make an example of your service design, please? I don't know how to bind a property `Pernr` of entity `Employee` to a value e.g. `Key` of entity `Config`. – srz Mar 01 '16 at 11:53
  • 1
    I am sorry for the confusion. Our entities (e.g. `Employee`) consist of several *complex types*. Each complex type (e.g. `Status`) has a value (e.g. `5`) and sometimes a descr (e.g. `declined`) (and sometimes multiple values + descr). The name of the complex type (e.g. `Status`) can then be the key to get the corresponding config set. The config set stores the editability, visibility and a translated label of all properties from a single complex type. – Marc Mar 01 '16 at 13:12
  • All right, thanks for your patience. Due to the number of properties in my service, this method will end in a numerous complex types. But your idea looks smarter then additional fields like `PernrVis` and `PernrEdit`. – srz Mar 01 '16 at 14:09
  • We have almost 60 of these complex types. And each complex type has its own fragment in the UI5 application. Those numbers may sound huge, but once you've set that up you have a very flexible, expandable, etc etc solution. – Marc Mar 01 '16 at 14:19

1 Answers1

0

Over the past two years, it turns out that complex types are the most flexible way to solve this problem.

As Marc already wrote, this is exactly how we do it today.

I am sorry for the confusion. Our entities (e.g. Employee) consist of several complex types. Each complex type (e.g. Status) has a value (e.g. 5) and sometimes a descr (e.g. declined) (and sometimes multiple values + descr). The name of the complex type (e.g. Status) can then be the key to get the corresponding config set. The config set stores the editability, visibility and a translated label of all properties from a single complex type.

srz
  • 129
  • 1
  • 1
  • 11