SAP / abap-file-formats

File formats that define and specify the file representation for ABAP development objects
MIT License
58 stars 56 forks source link

ENHO callbackClass #409

Open larshp opened 2 years ago

larshp commented 2 years ago

as the only type, ENHO contains "! $callbackClass {@link cl_seef_aff_enho_filter_st}, this is something outside this repository, so I cannot really tell what it is

is it required?

https://github.com/SAP/abap-file-formats/blob/main/file-formats/enho/type/zif_aff_enho_v1.intf.abap#L261

huber-nicolas commented 2 years ago

It is required, because the subschema of the filter_values is complicated (it has "oneOf", "anyOf", "maxItems"...) and can not be generated by the infos provided by if_aff_enho_v1 alone. Also the serialization and deserialization is complicated and therefore we decided to do them in abap coding instead of using a ST for filter_values (technically we call abap class cl_seef_aff_enho_filter_st inside the ENHO Aff ST to de/serialize the filter_values).

larshp commented 2 years ago

or in other words, the JSON type cannot be mapped to a static ABAP type

eg. just like conditional subschemas cannot be mapped to ABAP types

larshp commented 2 years ago

for reference, abapGit serializes structure ENH_BADI_IMPL_DATA

larshp commented 1 year ago

my suggestion: string

schneidermic0 commented 1 year ago

One proposal to change it by @larshp to string ^^

The string can contain IF-condition like foo = 'A' OR ( bar = 1 AND moo = 5 )

schneidermic0 commented 1 year ago

Options I see so far:

  1. Change the type of filterValues to type string. The field content is an IF-condition like foo = 'A' OR ( bar = 1 AND moo = 5 )
  2. Provide the callback class as open source so that it can be called by abap-file-formats-tools. It basically just returns the sub schema. See https://github.com/SAP/abap-file-formats/blob/7ae54e0cd5f67a346fb9797fab31bd7c0505c496/file-formats/enho/enho-v1.json#L136-L200
  3. Change the ABAP type so that it can be represented as static structure. Basically, this means, we have a structure with various options on the first level (e.g., simple filter value, an or- or and-combination. It could look like this (or similar)

    "! <p class="shorttext">Filter Condition</p>
    "! Filter condition
    TYPES ty_value TYPE string.
    
    TYPES:
    "! <p class="shorttext">OR Filter Conditions</p>
    "! OR filter conditions
    BEGIN OF ty_or,
      "! <p class="shorttext">Filter Condition</p>
      "! Simple filter condition
      value TYPE ty_value,
    END OF ty_or.
    
    TYPES:
    "! <p class="shorttext">AND Filter Conditions</p>
    "! AND filter conditions
    BEGIN OF ty_and,
      "! <p class="shorttext">Filter Condition</p>
      "! Simple filter condition
      value TYPE ty_value,
      "! <p class="shorttext">OR Filter Conditions</p>
      "! OR filter conditions
      or     TYPE standard table of ty_or with default key,
    END OF ty_and.
    
    TYPES:
    "! <p class="shorttext">OR Filter Conditions</p>
    "! OR filter conditions on top level
    BEGIN OF ty_or_top,
      "! <p class="shorttext">Filter Condition</p>
      "! Simple filter condition
      value TYPE ty_value,
      "! <p class="shorttext">AND Filter Conditions</p>
      "! AND filter conditions
      and    TYPE standard table of ty_and with default key,
    END OF ty_or_top.
    
    TYPES:
    "! <p class="shorttext">Filter Values</p>
    "! Filter values
    BEGIN OF ty_filter_values,
      "! <p class="shorttext">Filter Value</p>
      "! Filter value
      value TYPE ty_value,
      "! <p class="shorttext">OR Filter Conditions</p>
      "! OR filter conditions
      or    TYPE standard table of ty_or_top with default key,
      "! <p class="shorttext">AND Filter Conditions</p>
      "! AND filter conditions
      and   TYPE standard table of ty_and with default key,
    END OF ty_filter_values.