-
Notifications
You must be signed in to change notification settings - Fork 7
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
🏗 Request builder for Item Properties Setup #15
Conversation
$this->requestManager = $requestManager; | ||
} | ||
|
||
public function itemPropertiesSetup(): ItemPropertiesSetupRequestBuilder |
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.
itemPropertiesSetupBuilder
?
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.
Its already inside a BuilderFactory, so this would be imho not necessary "noise" in the method naming...
Also we're trying to make the builder API as much readable as possible, so not naming the class names in a full name (but using "natural language" aliases) is kind of the goal.
Does it make sense :-)?
I like it, although I'm iffy about the Two approaches come to mind. One would be to use different // Create or update properties:
$response = $matej->request()
->createOrUpdateItemProperties() // creates ItemPropertiesSetupRequestBuilder with "POST" flag
// ...
->send();
// Delete properties:
$response = $matej->request()
->deleteItemProperties() // creates ItemPropertiesSetupRequestBuilder with "DELETE" flag
// ...
->send(); Second approach could be changing the final $matej = new Matej('foo', 'apikey');
// Create or update item properties:
$response = $matej->request()
->itemPropertiesSetup()
// ...
->post();
// Delete properties
$response = $matej->request()
->itemPropertiesSetup()
// ...
->delete(); The beauty of that would be, that in future we could easily expose any Yay or nay? |
Add - third option - rename $matej = new Matej('foo', 'apikey');
// Create or update item properties:
$response = $matej->post()
->itemPropertiesSetup()
// ...
->send();
// Delete properties
$response = $matej->delete()
->itemPropertiesSetup()
// ...
->send(); I'm not sure how these affect readability of other calls. |
|
||
private function assertRequestManagerIsAvailable(): void | ||
{ | ||
if ($this->requestManager === null) { |
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.
How would you feel about if (!$this->requestManager instanceof RequestManager)
?
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 don't feel much difference here. Maybe prefer this version a little bit, as I read it like "there is no requeste manager", while the instanceof version is more like "request manager is request manager".
What about you :)? Any advantage for the instanceof version?
@foglcz Great ideas, thanks! I agree with the point, and I like the custom factory approach the most. I will update the PR soon :). (BTW there is no update for ItemPropertiesSetup endpoint - once created, the properties (= "columns" in Matej database) cannot be altered. To change their data type you must first delete and then recreate them.) So maybe this methods of the factory builder?
|
Ok, PR updated, how do everyone like the API now? cc @jirinovak @foglcz etc. $matej = new Matej('foo', 'apikey');
// Create new:
$response = $matej->request()
->setupItemProperties()
->addProperty(ItemPropertySetup::timestamp('valid_to'))
->addProperty(ItemPropertySetup::string('title'))
->send();
// Delete:
$response = $matej->request()
->deleteItemProperties()
->addProperty(ItemPropertySetup::timestamp('valid_to'))
->addProperty(ItemPropertySetup::string('title'))
->send(); |
Nice one! :) |
This is only until PHPStan supports intersections in PHPDoc in 0.9.
54b065d
4ff01f1
to
54b065d
Compare
This is finally the first part of the facade layer, which will be used by the end application.
(Names of the builder methods may change later - any suggestions?).
Example usage for this builder and builder factory (this is from the end application point of view):
Thoughts, comments? PR with builder for Event endpoint will follow soon.