search

SAP / abap-file-formats

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

filenames, when to use subobjects? #115

Open larshp opened 3 years ago

larshp commented 3 years ago

https://github.com/SAP/abap-file-formats/blob/main/doc/specification.md#file-names

ABAP should go into ABAP files, one file, like its presented to the developer in Eclipse

Metadata for a object(R3TR) should go into a single metadata file per object, having eg. one metadata file per dynpro, per CUA etc. makes it more complex IMHO, more schemas, more things to check on serialization/deserialization time

Translations: something, I've not thought much about these yet, deferred to #106

schneidermic0 commented 3 years ago

Thanks, for the proposal. I am struggling whether we really should go this way for the following reasons:

  1. This one file might become huge, doesn't it? This is most probably a matter of taste.
  2. gCTS also supports the transport of LIMU objects. This means, we will end up having multiple open transport objects containing LIMU objects for the same R3TR object. If one transport request is released only the changed parts in the particular transport request may be serialized to this one file. Changes related to the open transport request must remain unchanged in the repository. Technically, there are possibilities to implement this. We gained some experience in the area of classes. But, if we can, I would like to avoid this additional complexity whenever we can
larshp commented 3 years ago

scoping & conventions over exceptions

larshp commented 3 years ago

Lets take an example PROG ZFOOBAR, serializing each LIMU could give the following files(?)

Serializing all JSON into single file would give

xtough commented 3 years ago

Putting all the ABAP code into one *.abap file is trivial for reports but already cumbersome for classes for the reasons @schneidermic0 mentioned (like mapping LIMU METH changes to the one implementations include...) What I did not get was if @larshp is advocating one or many json files per PROG above. I understood the initial comment more in the latter sense (json files per rept, cuad, docu, dynp, etc.), which I would also be in favor of.