Skip to content
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

#2 [SDL-0234] Proxy Library RPC Generation #105

Merged
merged 20 commits into from Jan 31, 2020
Merged

#2 [SDL-0234] Proxy Library RPC Generation #105

merged 20 commits into from Jan 31, 2020

Conversation

vladmu
Copy link
Contributor

@vladmu vladmu commented Jan 14, 2020

Fixes #2

This PR is [ready] for review.

Risk

This PR makes [no] API changes.

Testing Plan

Covered by unit tests and PyLint

Summary

According to [SDL-0234] Proxy Library RPC Generation proposal, this PR adds the Python generator script based on XML Parser from smartdevicelink/rpc_spec linked to the repository as Git submodule

Changelog

Enhancements
  • Added lib/rpc_spec submodule pointed to master branch of smartdevicelink/rpc_spec repository
  • Created Proxy RPC Generator based on Python 3.5 and linked with parser from the lib/rpc_spec submodule
  • Added README.md with usage description and transformation rules for Proxy RPC Generator

CLA

  * Added `lib/rpc_spec` submodule pointed to `master` branch of `smartdevicelink/rpc_spec` repository
  * Created `Proxy RPC Generator` based on Python 3.5 and linked with parser from the `lib/rpc_spec` submodule
  * Added `README.md` with usage description and transformation rules for Proxy RPC Generator
@TinaKleczka
Copy link

@theresalech please review

@theresalech theresalech requested review from crokita and nickschwab and removed request for Jack-Byrne January 16, 2020 16:37
.gitmodules Outdated
@@ -0,0 +1,4 @@
[submodule "lib/rpc_spec"]
path = lib/rpc_spec
url = git@github.com:vladmu/rpc_spec.git
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As a reminder, this was agreed upon and is only temporary. The PR should not be merged until this is updated to reflect the correct remote. The rest of this PR can be reviewed as normal.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

changed to:

[submodule "lib/rpc_spec"]
	path = lib/rpc_spec
	url = https://github.com/smartdevicelink/rpc_spec.git
	branch = develop

@crokita
Copy link
Contributor

crokita commented Jan 17, 2020

We would appreciate if developers did not force push to a PR that is in review. Force pushing makes it difficult to review a PR because we cannot tell what was changed since the last commit. In general, please do not rebase and do not force push against the SDL repositories. Instead, you can merge the current develop branch into your PR branch. Thank you.

@vladmu
Copy link
Contributor Author

vladmu commented Jan 17, 2020

you can merge the current develop branch into your PR branch

@crokita got it, thank you for advice. We will do merge instead of rebase for refreshing the branch next time.

Copy link
Contributor

@crokita crokita left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ESLint overrides should be added to parts of the files specifically for camelcase naming violations from RPC spec data. See here: https://eslint.org/docs/user-guide/configuring.html#disabling-rules-with-inline-comments
All other lint checks should pass. Our linter rules are in the .eslintrc file.

The example apps break as a result of the generator's changes. Therefore, the affected parts of the library and the example apps will need to be fixed before merging this PR. We can make those fixes ourselves.

@nickschwab can also answer questions regarding the feedback.

The class should have the next JSDoc comment:
```javascript
/**
* [decription]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

change to "description"

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

The getter should have the next JSDoc comment:
```javascript
/**
* [decription]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

change to "description"

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

The class should have the next JSDoc comment:
```javascript
/**
* [decription]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

change to "description"

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

The setter should have the next JSDoc comment:
```javascript
/**
* @param {[param_type]} [value_name] [decription]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

change to "description"

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

The class should have the next JSDoc comment:
```javascript
/**
* [decription]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

change to "description"

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

The setter should have the next JSDoc comment:
```javascript
/**
* @param {[param_type]} [value_name] [decription]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

change to "description"

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

{
"enums": {
"DisplayType": {
"params_additional": [
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The TESTING enum was mistakenly added to the DisplayType enums. This can be removed.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

@@ -0,0 +1,140 @@
{
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There isn't documentation for the effect of each key-value pair that appears in this file, ex. params_additional and the array value it has. This would be useful information to add to the README of how each override rule works, as we may need to make changes to this file in future releases.

There should be a clearer distinction as to whether properties under a struct/enum/message are attributes of that class, or whether they are doing some modification to that class. Ex. under RegisterAppInterfaceRequest there is appID and fullAppID which are properties of RegisterAppInterfaceRequest, but there is also the params_additional property on the same level which wouldn't actually be a property of RegisterAppInterfaceRequest. Another example is PutFileRequest, where syncFileName is a property of the class, but script is not and it performs another effect.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The documentation added into readme b30da93

},
"script": "templates/scripts/PutFileRequest.js"
},
"OnHMIStatus": {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This object can be removed. We will keep the naming convention from the spec as OnHMIStatus.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

@BorisTm
Copy link

BorisTm commented Jan 27, 2020

ESLint overrides should be added to parts of the files specifically for camelcase naming violations from RPC spec data. See here: https://eslint.org/docs/user-guide/configuring.html#disabling-rules-with-inline-comments
All other lint checks should pass. Our linter rules are in the .eslintrc file.

@crokita Question about camelcase naming violations. Do we need to add these 30 parameters as exceptions to .eslintrc? Or is it better to add processing to the parser for such cases?

We have now camelcase naming violations for these parameters/functions:
struct:
DateTime.js
setTz_hour
tz_hour
getTz_hour

setTz_minute
tz_minute (set, get, parameter)
getTz_minute

enum:
Dimension.js
Dimension_NO_FIX
Dimension_2D
Dimension_3D

messages:
GetVehicleData.js
setFuelLevel_State
level_state
getFuelLevel_State

GetVehicleDataResponse.js
setFuelLevel_State
level_state
getFuelLevel_State

OnVehicleData.js
setFuelLevel_State
level_state
getFuelLevel_State

SubscribeVehicleData.js
setFuelLevel_State
level_state
getFuelLevel_State

unsubscribeVehicleData.js
setFuelLevel_State
level_state
getFuelLevel_State

SubscribeVehicleDataResponce.js
setFuelLevel_State
level_state
getFuelLevel_State

UnsubscribeVehicleDataResponce.js
setFuelLevel_State
level_state
getFuelLevel_State

@nickschwab
Copy link

@BorisTm Thanks for asking! Instead of placing the overrides in the .eslintrc file, please use in-line override comments in the generated files themselves: https://eslint.org/docs/user-guide/configuring.html#disabling-rules-with-inline-comments

e.g.

// eslint-disable-next-line camelcase
[line which violates the camelcase rule here]

@vladmu
Copy link
Contributor Author

vladmu commented Jan 27, 2020

@nickschwab thank you for advice, from the perspective of the manual changes it is the best approach, but it seems this requires additional code for auto-checking names on the fly during the generation process and mark invalid lines with the corresponding comment, which could be slightly complicated than the adjusting of .eslintrc at the current stage. Is that really required?

@nickschwab
Copy link

@vladmu I recommend either applying the in-line override to all entities (rather than performing a check to determine whether or not each entity actually violates the rule), or we can use a file-scoped override to specifically ignore camelcase violations for the entire file (e.g. /* eslint-disable camelcase */ at the top of the file)

@vladmu
Copy link
Contributor Author

vladmu commented Jan 27, 2020

@nickschwab the last recommendation is simplest, but in this case, all RPC names will not be validated, is that suitable?

@nickschwab
Copy link

@vladmu Yes 👍

@crokita
Copy link
Contributor

crokita commented Jan 27, 2020

Hello! Thank you for making some of the requested revisions. After a more thorough review of the code we only have a few additional changes to suggest before approval.

  • The validateType method in RpcStruct accepts a third argument (isArray) which makes it capable of validating arrays of objects. This argument should be used instead of ignoring array types
  • Regarding JSDoc comments with describing arrays of objects, it needs to be either the format Array.<Object> or Object[] instead of currently Array<Object>. We suggest using Object[].
  • The variables used in for loops for the template scripts shouldn't have single character identifiers (ex. looping over 'methods', the iterating variable should be more descriptive like 'method'). This makes it easier for us to understand the code when looking through it.
  • Per the guidelines regarding Enum generation: The value of the pair shall be set to the value of the hexvalue attribute (if available), otherwise the name attribute. Currently the only instance is with the FunctionID enum class (ex. RegisterAppInterface. Value is 1 instead of 0x01)
  • RpcCreator.js is a class that needs to be generated alongside the other RPC files. We have a currently unfinished version at lib/js/src/rpc/RpcCreator.js that will need to have its case statements and imports expanded to include all RPCs.

@theresalech
Copy link
Collaborator

@vladmu please let us know once all feedback has been addressed and this PR is ready for Livio's re-review. Thanks!

@vladmu
Copy link
Contributor Author

vladmu commented Jan 30, 2020

@theresalech We've done all the requested changes. So this PR is now ready for Livio's review again. Thank you!

@crokita
Copy link
Contributor

crokita commented Jan 30, 2020

@vladmu
Thank you again for the changes! I've done another review and have the following revisions:

Below are change requests to the mappings.json file:

  • enums.FunctionID object can be removed
  • structs.DisplayCapabilities object can be removed
  • structs.TextField can be removed
  • structs.RGBColor can be removed
  • functions.OnHMIStatusNotification can be removed
  • functions.RegisterAppInterfaceResponse can be removed

Here are other notes:

  • I think scripts broke for the mapping.json file. I don't see PutFileRequest or RegisterAppInterfaceRequest custom code in the generated output
  • method_title is the property used in the mapping.json, but in the README file it says method_name
  • ESLint tests all pass except for the rule "id-length", for files Rectangle.js, TouchCoord.js, and TouchEvent.js. I think having another override which doesn't report those warnings should be made, just like how the camelcase rule is ignored for these files.

@vladmu
Copy link
Contributor Author

vladmu commented Jan 31, 2020

@crokita thank you, all points are fixed. Please review.

@crokita
Copy link
Contributor

crokita commented Jan 31, 2020

@vladmu Looks good 👍
I'll be doing some final checks and include the generated output for the RPCs in this PR

@crokita crokita merged commit d89dcd4 into smartdevicelink:develop Jan 31, 2020
@@ -1,4 +1,4 @@
[submodule "lib/rpc_spec"]
path = lib/rpc_spec
url = git@github.com:vladmu/rpc_spec.git
url = https://github.com/smartdevicelink/rpc_spec.git
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@crokita you pointed the submodule to the correct repository, but please take into account the master branch of rpc_spec doesn't contain the parser code yet. The corresponding PR is not merged yet. It would be good if you notify @JackLivio in answer to this comment that JS generator passed your checks and rpc_spec could be merged too.

@vladmu vladmu deleted the feature/#2-SDL-0234-Proxy-Library-RPC-Generation branch February 3, 2020 11:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[SDL 0234] Proxy Library RPC Generation
8 participants