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
Add endpoint for getting item properties #53
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.
Could you also add some exmaple usage to readme? (But keep it short - as this is just an "auxiliary" endpoint used mainly for debugging, and not a main feature :) ).
Also something is missing code coverage according to coveralls, could you have a look, please?
@@ -7,10 +7,8 @@ | |||
use Lmc\Matej\Model\Command\ItemPropertySetup; | |||
use Lmc\Matej\Model\Request; | |||
|
|||
class ItemPropertiesSetupRequestBuilder extends AbstractRequestBuilder | |||
class ItemPropertiesModifierRequestBuilder extends ItemPropertiesGetterRequestBuilder |
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.
My preference is to keep this name as is - its meaning is already IMHO clear and distinctive from the GET version, and this adds no extra value - maybe even is confusing, because you actually cannot modify (like change data type) item properties once they are created in the database. So the the ItemPropertiesSetupRequestBuilder
is for me ok. What do you think?
use Fig\Http\Message\RequestMethodInterface; | ||
use Lmc\Matej\Model\Request; | ||
|
||
class ItemPropertiesGetterRequestBuilder extends AbstractRequestBuilder |
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 a builder, which build request to get item properties (Its not building "getter request"), so why not just ItemPropertiesGetRequestBuilder
? (But only if the other one is kept as ItemPropertiesSetupRequestBuilder
)
array $properties | ||
): ItemPropertiesModifierRequestBuilder { | ||
foreach ($properties as $name => $definition) { | ||
$property = forward_static_call([Command\ItemPropertySetup::class, $definition[0]], $name); |
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.
ItemPropertySetup::$definition[0]($name)
:)?
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.
That wouldn't work as PHP would think that $definition is a static array on ItemPropertySetup
class.
Would have to be ItemPropertySetup::{$definition[0]}($name)
which I found pretty ugly :|
} | ||
|
||
/** | ||
* @return array[string, array[string, mixed]] |
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'm not sure there is any common PHP standard of defining internal array structure (and PHPStorm don't understand this, no?) , so we may just stick with standardized array[]
...
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.
It's true that phpstorm doesn't understand this notation, but PHPStan does :)
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 documented somewhere in PHPStan? I couldn't find it...
@@ -7,10 +7,8 @@ | |||
use Lmc\Matej\Model\Command\ItemPropertySetup; | |||
use Lmc\Matej\Model\Request; | |||
|
|||
class ItemPropertiesSetupRequestBuilder extends AbstractRequestBuilder | |||
class ItemPropertiesModifierRequestBuilder extends ItemPropertiesGetterRequestBuilder |
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 the inheritance is there just because of the endpoint path, I'd not introduce it at all and rather have the endpoint path copied on two places. "Setup request builder" is from my POV not specific version of "Get request builder". It would only make sense IMHO to have AbstractItemPropertiesRequestBuilder
with two childs, but would be a bit overengineered :).
28b6d5a
to
96c7edd
Compare
use Fig\Http\Message\RequestMethodInterface; | ||
use Lmc\Matej\Model\Request; | ||
|
||
class ItemPropertiesGetRequestBuilder extends AbstractRequestBuilder |
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.
Could you please add also simple unit test for this builder? (See other unit tests for builders).
02ca722
to
02cf89f
Compare
CHANGELOG.md
Outdated
@@ -5,6 +5,7 @@ | |||
<!-- There is always Unreleased section on the top. Subsections (Added, Changed, Fixed, Removed) should be added as needed. --> | |||
|
|||
## Unreleased | |||
- Endpoint `$matej->getItemProperties()` that returns all defined item properties |
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.
### Added
- Endpoint to get all defined item properties in the Matej database (`$matej->request()->getItemProperties()`).
e5aa9f9
to
6c15fb2
Compare
@@ -7,10 +7,8 @@ | |||
use Lmc\Matej\Model\Command\ItemPropertySetup; | |||
use Lmc\Matej\Model\Request; | |||
|
|||
class ItemPropertiesSetupRequestBuilder extends AbstractRequestBuilder | |||
class ItemPropertiesSetupRequestBuilder extends ItemPropertiesGetRequestBuilder |
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.
What do you think about this? (The comment got "outdated" by github after the rebase...)
If the inheritance is there just because of the endpoint path, I'd not introduce it at all and rather have the endpoint path copied on two places. "Setup request builder" is from my POV not specific version of "Get request builder". It would only make sense IMHO to have
AbstractItemPropertiesRequestBuilder
with two childs, but would be a bit overengineered :).
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 a very good point; I was thinking from the perspective of REST endpoints - and not from the perspective of RequestBuilders.
Will update code in a sec.
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 could please rebase the PR (to get rid of the fixup commits) and we can merge it then 🎉
2504f2e
to
d9db672
Compare
Depends on matej's deploy of RAD-720
Depends on #46 - before merging, change base of PR
Implements
GET /item-properties