Description
Hello ApiPlatform team. We already have few formats supported to read ApiResource metadata (xml,yaml,annotation). But i think its logical to support plain php files in same way as yaml files for example for resource metadata. Example of php file for this can be as simple as yaml format, see example. It should work same as yaml but except yaml parsing at all.
Example
<?php
declare(strict_types=1);
use App\DataForm\Domain\Model\FormTemplate;
use Dotdev\ApiPlatform\ApiConstants;
return [
FormTemplate::class => [
'attributes' => [
'normalization_context' => [
'groups' => [
ApiConstants::READ,
],
],
'denormalization_context' => [
'groups' => [
ApiConstants::WRITE,
],
],
],
'properties' => [
'id' => [
'identifier' => false,
],
'uuid' => [
'identifier' => true,
],
],
'collectionOperations' => [
'get' => null,
'post' => null,
],
],
];
Shouldn't we promote PHP8's attributes instead of a DSL like this?
I think php8's attributes will be de facto standard later, but their behavior will be the same as current annotations.
This is something different from attributes/annotations at all. U still have yaml/xml metadata extractor and they will exist, but plain php array may be more easy to use than YAML, its just YAML in php. Its just "copy" of yaml extractor without reading yaml.
It also means more maintenance burden. We were providing XML and YAML formats because annotations were a hack, but now that they are natively supported by PHP, I would like to drop support for XML and YAML to simplify the code base (they can always be supported in a third-party bundle because the metadata system will stay).
So maybe this PHP config can be in a third-party bundle too.
The problem with annotations and php attributes very simple. If i have class with trait, which uses annotation/attribute for metadata, i should define metadata for trait properties in trait instead of class. So i cant override metadata defined in the trait, is it okay?
Second problem, i dont want to annotate/use attributes, for now we can define metadata using some configs, it is USEFULL anyway, why it should be removed? php attributes cool, but i think they cant cover all use cases.
You have a good point regarding the traits, I've a solution in mind for a while, but I need to try it to be sure it can work.
Regarding XML and YAML, it makes the maintenance of the documentation very hard (no one contributes the docs for XML and YAML, but we get a lot of issues about this lack of documentation). We should at least automate this part before introducing yet another config format.
Yes i understand about the docs part, but at least xml for now gives us some autocomplete and structure, while with other formats u always need to check docs (if they exist at all)/metedata reader code/remember the structure to write configs. As for now i understand ur position, but i hope xml will not be removed soon because its important format, at least in 3dparty bundle. Ty for answers anyway, mby i will try to contribute this myself later.
Most helpful comment
It also means more maintenance burden. We were providing XML and YAML formats because annotations were a hack, but now that they are natively supported by PHP, I would like to drop support for XML and YAML to simplify the code base (they can always be supported in a third-party bundle because the metadata system will stay).
So maybe this PHP config can be in a third-party bundle too.