-
Notifications
You must be signed in to change notification settings - Fork 61
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[SITO] File format for situation objects - New #380
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, @micotto. I had a first look at your pull request. I think there are a lot of improvements compared to #364. 👍
I went through the proposal (I put focus on the example in the first step) and added a bunch of questions, comments and suggestions.
I guess there will be more in further iterations. This file format definition is one of the largest so far. ;)
], | ||
"structureSemanticKey": [ | ||
{ | ||
"fieldOrder": "02", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does the field fieldOrder
represent the order of semantic keys? This seems to be similar to the discussion of order of db table fields for indexes. There we take the approach to not specify an order field. The order is specified by the order of entries in the array.
Relates to #176
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Field Order is used to set the order for the concatenation of keys for the semantic key. It is a critical information. If the explicit definition of the field order is removed and the order is just defined by the implicit order of the fields in the array, a user could miss the necessity/importance of that order. Without the explizit field order definition it just looks like an array of keys where the order does not matter!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We suggest to write titles/shorttexts in title case and descriptions in ABAPdoc comments in standard sentence case.
"! <p class="shorttext">In Memory</p> | ||
"! In Memory |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Usually, the tile stays in title case. The descriptions below are in standard sentence case.
"! <p class="shorttext">In Memory</p> | |
"! In Memory | |
"! <p class="shorttext">In Memory</p> | |
"! In memory |
This seems to be the case for almost all descriptions
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Adapted for all descriptions
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Adapted for all descriptions
It seems not to be fixed, yet.
|
We went through all review comments. For some, files/code were adapted. Others we would like to clarify. Please see our comments above. |
Shall we already review your changes? Or shall we wait until you clarified the other points? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You didn't change this file by intension, did you?
@schneidermic0 |
"! $required | ||
type TYPE ty_sit2_do_vh_type, | ||
"! <p class="shorttext">Scope</p> | ||
"! Source |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Field is named "scope", while description says "Source". Is this correct?
I wonder since "scope" might mean "source" as well, but also has other meanings.
for me both are fine, just wanted to point you to.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will be changed to "SCOPE" entirely!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Puh, a very long type. I have to admit that I have lost track a bit... However, my review is focused on the titles and descriptions. These are only suggestions. It's up to you if you want to implement them
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@micotto and @tobiasmuench: Thanks. Good progress!
We added a lot of feedback (most of them are minor changes due to inconsistencies in titles and descriptions).
Maybe it make sense to talk about following general remarks/ideas in a call/meeting:
- Order of fields in structures (especially for required and boolean fields)
- Reuse of types
- Field
field_order
in semantic keys
"! <p class="shorttext">In Memory</p> | ||
"! In Memory |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Adapted for all descriptions
It seems not to be fixed, yet.
"! <p class="shorttext">SIT2_DO_SCOPE</p> | ||
"! SIT2_DO_SCOPE |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minor: Do you need the DDIC types, here? At leaset for the title (shorttext) I would remove them.
There are several places
@SAP/abap-file-formats-team Can we handle @links
in the description of ABAP doc? If yes, they could add a link to the ddic type by adding {@link SIT2_DO_SCOPE}
. This would be helpful in ADT's element info. What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
not sure what is meant here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess @schneidermic0 suggests to remove at least the titles which only consist of the DDIC types. Do you need these DDIC types here?
About the @link
: I tried to add a link to SIT2_DO_SCOPE in the description. It does not work.
So for you @micotto:
If you need the DDIC type information here, you can think about having it only in the description, i.e. remove the "shorttext"`s (here and for the types and constants below).
If you don't need the information, I would remove it.
|
||
"! <p class="shorttext">Semantic Keys</p> | ||
"! Semantic keys of an object structure | ||
ty_sit2_obj_str_sk_list TYPE STANDARD TABLE OF ty_sit2_obj_str_sk WITH DEFAULT KEY, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you want to keep the field field_order
, should the entries be sorted by the field_order?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
for the moment, we are fine with keeping field field_order, based on standard table
(we tried to use sorted table, but we obtain a syntax error in if_aff_sito_v1)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you want to have a sorted table, it should be possible to have it like
ty_sit2_obj_str_sk_list TYPE STANDARD TABLE OF ty_sit2_obj_str_sk WITH DEFAULT KEY, | |
ty_sit2_obj_str_sk_list TYPE SORTED TABLE OF ty_sit2_obj_str_sk WITH UNIQUE KEY field_order, |
Draft of user story: |
Order of fields is definitely important and will be fixed! Order proposal:
|
Hi colleagues, |
Thanks for your update @micotto. I am taking over for @schneidermic0. |
Hi @wurzka. I went through the review comments once more and adapted everything which was missing. With a few exceptions (where I put comments), all suggestions are resolved now. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for your update. I added two comments. Please give a short feedback whether you want to do any of the changes.
"! <p class="shorttext">SIT2_DO_SCOPE</p> | ||
"! SIT2_DO_SCOPE |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess @schneidermic0 suggests to remove at least the titles which only consist of the DDIC types. Do you need these DDIC types here?
About the @link
: I tried to add a link to SIT2_DO_SCOPE in the description. It does not work.
So for you @micotto:
If you need the DDIC type information here, you can think about having it only in the description, i.e. remove the "shorttext"`s (here and for the types and constants below).
If you don't need the information, I would remove it.
|
||
"! <p class="shorttext">Semantic Keys</p> | ||
"! Semantic keys of an object structure | ||
ty_sit2_obj_str_sk_list TYPE STANDARD TABLE OF ty_sit2_obj_str_sk WITH DEFAULT KEY, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you want to have a sorted table, it should be possible to have it like
ty_sit2_obj_str_sk_list TYPE STANDARD TABLE OF ty_sit2_obj_str_sk WITH DEFAULT KEY, | |
ty_sit2_obj_str_sk_list TYPE SORTED TABLE OF ty_sit2_obj_str_sk WITH UNIQUE KEY field_order, |
We'll do both suggested changes. |
I suggest deleting the complete line s.t. there is only line "! SIT2_DO_SCOPE I would remove these titles also for the constants. |
Both suggested changes were carried out. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks. Looks good to me, now. I think we can merge the pull request.
Not available to review again. Review was taken over by myself.
No description provided.