Skip to content
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

[3.0] Use serializer expression language #267

Merged
merged 4 commits into from
Nov 23, 2018
Merged

[3.0] Use serializer expression language #267

merged 4 commits into from
Nov 23, 2018

Conversation

goetas
Copy link
Collaborator

@goetas goetas commented Nov 11, 2018

Following up on #266, here a proposed refactoring for a possible v3

Currently is still work in progress, I would like to drop some functionalities.
Hope to have some time in the next days to prepare a list of features would like to drop ( to make the code more maintainable)

feedback is welcome

EDIT: list of features I would like to drop:

  1. ability to use the expression language for the rel value

This attribute is the "reason" for a link to exist. This reason should be one. A "dynamic reason" means that most likely need a different link. Having this property not-dynamic will make the life easier when documenting the api (or generation documentation)

  1. ability to use the expression language for the is_absolute route value

Same as for the point n.1. A link should be either relative or absolute, having it dynamic, makes it more difficult for the consumer to know what to do.

  1. ability to use the expression language for attribute names (will still be possible to used it for the attribute value)

Same as for the point n.1 and n.2. The list of attributes to expect IMO should be well defined.
Makes life easier for clients, for documentation.

  1. drop completely the relation_providers

This point is related to the previous 3 points. Essentially the main idea is to get rid of "dynamic" things and have relations more predictable.

Removing the dynamical parts will make this lib more performant and will allow in the future to compile many parts of this library, that currently is done at runtime ( as example implementing #201)

@adrienbrault
Copy link
Contributor

Looks good so far 👍

Maybe it is a good time to add phpstan with the strict rules ?

@goetas
Copy link
Collaborator Author

goetas commented Nov 12, 2018

@adrienbrault Did not think about it, but sounds a great idea!

@goetas
Copy link
Collaborator Author

goetas commented Nov 12, 2018

I have updated the description adding a proposal for some changes. None of them are implemented yet, I'm open to hear feedback!

@Jean85
Copy link

Jean85 commented Nov 12, 2018

Maybe it is a good time to add phpstan with the strict rules ?

Good idea, but it should be done in a separate PR!

@@ -13,21 +13,19 @@
}
],
"require": {
"php": "^5.5|^7.0",
"php": "^7.2",
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not 7.1? Are you using any specific language feature?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

jms/serializer requires 7.2, and this lib fully depends on it

@@ -13,21 +13,19 @@
}
],
"require": {
"php": "^5.5|^7.0",
"php": "^7.2",
"doctrine/common": "~2.0",
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Common is deprecated and splitted into several libraries, we should drop it.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, true. Will check where is used. Probably in a separate pr

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As reference: doctrine/common#826

@goetas
Copy link
Collaborator Author

goetas commented Nov 16, 2018

@willdurand @adrienbrault what are your toughs on

  • drop completely the relation_providers

This point is related to the previous 3 points. Essentially the main idea is to get rid of "dynamic" things and have relations more predictable.

Removing the dynamical parts will make this lib more performant and will allow in the future to compile many parts of this library, that currently is done at runtime ( as example implementing #201)

@adrienbrault
Copy link
Contributor

@goetas Would there be a way for a library/application to add relations at compile time to a class ?

@goetas
Copy link
Collaborator Author

goetas commented Nov 16, 2018

Actually should be not too complicated to move RelationsRepository at compile time (when metadata are cached for the first time).
The current user-api should remain almost the same except that relations will be created only once when metadata are generated.

@adrienbrault
Copy link
Contributor

@goetas Would there also be an easy to add serializer type configuration to embedded ? The goal is that the api doc bundle could then show sample models/schemas within _embedded

@goetas
Copy link
Collaborator Author

goetas commented Nov 16, 2018

@goetas Would there also be an easy to add serializer type configuration to embedded ? The goal is that the api doc bundle could then show sample models/schemas within _embedded

This is something that at the moment this lib does not offer, but is something I definitivnim plan to add (i have exactly the same use-case!)

@adrienbrault
Copy link
Contributor

@goetas Ok ;-). Just asking in case it's easier to do in the refactoring, though it's probably better as a follow up PR

@goetas goetas changed the title [WIP] V3 [3.0] Use serializer expression language Nov 16, 2018
@goetas goetas added this to the 3.0 milestone Nov 16, 2018
@@ -34,5 +35,11 @@ public function __construct(Exclusion $exclusion = null, Relation $relation = nu
$this->sinceVersion = $exclusion->getSinceVersion();
$this->untilVersion = $exclusion->getUntilVersion();
$this->maxDepth = $exclusion->getMaxDepth();

if ($exclusion->getExcludeIf() !== null && preg_match(self::EXPRESSION_REGEX, $exclusion->getExcludeIf(), $matches)) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This logic is now duplicated 3 times. Why did you remove the ExpressionEvaluator class ?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

indeed, this will be solved in a separate PR (see #270)

} else {
$serializedEmbeddeds[$embedded->getRel()][] = $navigator->accept($embedded->getData(), null, $context);
}
} catch (NotAcceptableException $e) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it make sense to log this error ?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@goetas goetas changed the base branch from master to develop November 23, 2018 09:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants