Add a filter for serialization attributes#1123
Conversation
meyerbaptiste
commented
May 17, 2017
| Q | A |
|---|---|
| Bug fix? | no |
| New feature? | yes |
| BC breaks? | no |
| Deprecations? | no |
| Tests pass? | yes |
| Fixed tickets | #1083 |
| License | MIT |
| Doc PR | N/A |
| { | ||
| const QUERY_PARAMETER_KEY = 'exists'; | ||
|
|
||
| public function __construct(ManagerRegistry $managerRegistry, RequestStack $requestStack, LoggerInterface $logger = null, array $properties = null) |
There was a problem hiding this comment.
I've seen this in other filters I think. Do this need to be part of this commit?
There was a problem hiding this comment.
No this is the only filter where there is this useless constructor! I will open another PR.
There was a problem hiding this comment.
Okay, we have other useless constructors (QueryChecker for example)
There was a problem hiding this comment.
Not totally useless, the QueryChecker's constructor is private! 😛
f738976 to
d3cd6e5
Compare
|
Perhaps "properties" instead of "fields" to be consistent in our terminology? |
|
But I guess people are more used to "fields"... Maybe we should just keep it this way. 😄 |
|
I'm for |
d3cd6e5 to
ad9acf1
Compare
|
Done. |
ad9acf1 to
f62f14c
Compare
Yes, but what would people be looking for, when they want that feature? "Fields". It might be worth using the term most people are likely most familiar with. |
ae5a752 to
ddb72a3
Compare
It's a doc issue. We need to make it easy to find on the website using both terms, but in the code, consistency is the key. Keep it as is. |
ddb72a3 to
722165c
Compare
|
Good job!! |