-
Notifications
You must be signed in to change notification settings - Fork 25
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
Convert old rest stack: supremm module #28
Conversation
} else { | ||
$payload['message'] = self::_DEFAULT_ERROR_MESSAGE; | ||
} | ||
} catch (BadRequestHttpException $e) { |
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.
Is it necessary to catch all of these exceptions? Surely the middleware should handle this for you automatically.
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.
This is modeled rather heavily on the other NewRest controllers, which similarly catch lots of exceptions. I will review...
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.
Exception code has been removed; framework handles this, as you point out!
->get("$root/dbstats", "$base::getDbstats") | ||
->assert('resource_id', '(\w|_|-])+') | ||
->convert('db_id', "$conversions::toInt") | ||
->convert('resource_id', "$conversions::toString"); |
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.
This definition says that db_id is an int and resource_id is a string, but on lines 123 and 124 you require the exact opposite: get db_id must be a string and resource_id must be an int.
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.
Yup, it's wrong here, I will fix. Maybe changing the variable name will also help clarify this.
} catch (HttpException $e) { | ||
$payload['message'] = $e->getMessage(); | ||
$statusCode = $e->getStatusCode(); | ||
} catch (\Exception $e) { |
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 authorize() throws an AccessDeniedException then this code will catch it and change the status code to internal error. This is wrong.
I think that you should not be catching exceptions here. Instead let the framework handle them
* @param timestamp $ts | ||
* @return mixed | ||
*/ | ||
private function _time2str($ts) |
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 feel like this should be a utility function that anything can use. Maybe even remove this from the backend code and use something like moment in the frontend to do this as a display thing...
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 the idea is to port what's there. Moving general functionality into utility functions should absolutely be done separately...
* @param numeric $d | ||
* @return mixed | ||
*/ | ||
private function _formatDataSize($d) |
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.
This as well seems like a utility function that is able to be used in multiple places.
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.
As mentioned above, yes, I agree--in a separate pull request.
I think it would help to run the code through phpcbf to fix a bunch of the warnings and errors from travis ci. |
And I missed that travis ci failed. OK, I'll revisit. Thanks. |
<script type="text/javascript" src="/gui/lib/extjs/ext-all-debug.js"></script> | ||
|
||
<!-- RESTProxy --> | ||
<script type="text/javascript" src="../../gui/js/CCR.js"></script> |
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.
Why are you including the REST.js RESTProxy and CCR.js javascript files? They are not needed.
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 believe you are right...duly noted, I'll remove those includes.
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.
Done.
b6c9614
to
7a05970
Compare
Moving utility/format functions will be done in a separate pull request.
In order for integration tests to work, the fix-framework-authorize-exceptions branch on xdmod repo will be needed (pull request to follow once unit tests exist) |
9dcf0e8
to
1bbe21d
Compare
Existing travis CI Errors will be fixed by #35 and an update to https://github.com/jpwhite4/lint-diff |
…wRest stack, to enable elimination of old REST stack code.
0c6114a
to
d5d81d8
Compare
This is a step along the way toward killing off the old REST stack.
Description
Create a NewRest-style controller for the internal dashboard's supremm dataflow functionality, to replace the old classes/REST/supremm code.
Refer to pull requests against
Motivation and Context
Tests performed
Changes are limited to the internal dashboard's supremm dataflow, which reports on the last time various supremm sources contributed data. These were tested by hand to verify, using chrome debugger to observe which rest endpoints are in use. Finally, tests for the new endpoints have been added and use the integration test harness.
Types of changes
Checklist:
Caveats:
More things I'd like to do related to the rest stacks (but not a part of the current pull request):
To Do:
Remaining to do in this exercise: