-
Notifications
You must be signed in to change notification settings - Fork 9.3k
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
Improve \Magento\Framework\Api\SortOrder #1422
Conversation
@Vinai thank you for the contribution! Internal reference: MAGETWO-39814 |
@Vinai we have completed the code analysis. Here are outcomes: Classes from API directories are used during wsdl creation process and REST documentation creation process. Particularly, all getters(methods with "get", "is" or "has" prefixes) from such classes are used to build WebAPI representation for appropriate entities. So, this pull request introduces two additional fields("ascending" and "descending") to API and documentation. Also your pull request shown us that in some cases internal PHP api could be richer than Web API. Currently, framework doesn't support such feature, so we forced to reject this contribution. |
Thank you for your feedback! |
I've updated the PR so it no longer includes the new
Please reevaluate the PR. |
The failing integration test |
@Vinai Thank you for fixing the PR. I will get back to you once we complete the analysis. |
@Vinai the code looks good. Could you please update pull request with latest changes from mainline? Conflicts block travis from fetching new commits, so build fails. |
Thanks, will do |
Rebased onto current develop, all unit tests are green. However since the last pull I have hundreds of failing integration tests locally (in the develop branch, so independent of this PR). Will need some time to debug and try to get them running again. I'll push the PR branch never the less, because I'm curious what travis says. |
Purpose == Make the specification of sort directions on sort criteria easier for developers. Background == This PR addresses several issues: **PHPDoc type hint mismatch** All parameter type hints expecting a sort direction specify `@param string $direction`, but the constants `SearchCriteriaInterface::SORT_ASC` and `SearchCriteriaInterface::SORT_DESC` are integers. As a developer, when I see a method `setDirection()` that takes a string, I expect the argument to be either `ASC` or `DESC`. Neither work, but there is no error helpful error message. **Unintuitive placement of constants** Also the location of the constants is not intuitive. When working with the code in question, a developer is focused on the classes SortOrder and SortOrderBuilder. So the expectation would be to find the class constants on either of those classes. **Missing validation** The sort direction can be specified as a scalar argument, but there is no validation. This PR adds validation and throws an explanatory exception on validation failure. Reasons for this PR == The motivation is to make it easier and more intuitive for developers to specify a sort order.
All green - well, I guess that's good for the PR then. I'll just have to debug what is not working locally again. |
- Fixed code style and static tests
Purpose
Make the specification of sort directions on sort criteria easier for developers.
Background
This PR addresses several issues:
PHPDoc type hint mismatch
All parameter type hints expecting a sort direction specify
@param string $direction
, but the constantsSearchCriteriaInterface::SORT_ASC
andSearchCriteriaInterface::SORT_DESC
are integers.As a developer, when I see a method
setDirection()
that takes a string, I expect the argument to be eitherASC
orDESC
. Neither work, but there is no error helpful error message.Unintuitive placement of constants
Also the location of the constants is not intuitive. When working with the code in question, a developer is focused on the classes
SortOrder
andSortOrderBuilder
. So the expectation would be to find the class constants on either of those classes.The addition of the methods
setAscendingDirection()
andsetDescendingDirection()
to theSortOrderBuilder
removes the need for developers to know the location of constants at all.Missing validation
The sort direction can be specified as a scalar argument, but there is no validation.
This PR adds validation and throws an explanatory exception on validation failure.
Reasons for this PR
I simply hope to make it easier and more intuitive for developers to specify a sort order.