Setting a Custom Field Via a Listener

Hey Johanna B.!

My apologies for the very slow reply - I was just starting a holiday when you commented, and the team left this (tough) question for me :). I think, unless I'm neglecting a complication - that adding a filter for a virtual property would not be any different than any other custom filter. For example, here is the main video where we implement a custom filter for a Doctrine entity - https://symfonycasts.com/screencast/api-platform-extending/entity-filter-logic

In that example, in getDescription(), we name the filter "search". But that does not need to correspond to any property name on our class. So we could also call it "isMe" or "fooBar". It really controls what the query parameter will be called. So, assuming you call your filter isMe, in filterProperty, if $property is set to isMe, then you could then do whatever logic you wanted to modify the query. Specifically, you would probably get the current user and add something like:

$alias = $queryBuilder->getRootAliases()[0];
$queryBuilder->andWhere(sprintf('%s.owner = :owner', $alias))
    ->setParameter('owner', $this->security->getUser());

If you do this, I think it's all you need. You would still be using the built-in entity data provider, which is nice because that also automatically handles pagination. For example, if I own 50 CheeseListing, then the results for isMe=1 would automatically be paginated for me.

If I'm missing some complication, let me know - I'm just thinking through this problem, so something may not be occurring to me :).

Cheers!

Many thanks for your reply! Yes, that makes a lot of sense to me. If you don't mind me asking another question - what now happens if we have a virtual property which we cannot (feasibly) filter for using the queryBuilder, perhaps because it involves very complicated logic and is far removed from any property mapped to the database? I hope my question makes sense! Many thanks

Hey Johanna B.!

My pleasure - but sorry for the slow reply to this one! :).

> what now happens if we have a virtual property which we cannot (feasibly) filter for using the queryBuilder, perhaps because it involves very complicated logic and is far removed from any property mapped to the database

One way or another (even if you were building a normal web app and not an API), you will need to create a query to pull items back from the database. So, somehow, you really need to modify the query to fetch the results you need. If, for some reason, the logic was SO complex that you needed to make a query to the database... and then do extra logic in PHP to filter the final results then, hmm, I think you would need a completely custom data provider for this :). But then you would need to manually add pagination support to that.

Cheers!

Hey Carlos!

That's a pretty interesting question :). I can, at least, give you some hints!

A) What you ultimately want to do is update the OpenAPI JSON documentation - which you can see directly if you go to /api/docs.json.

B) This JSON is created just like any other JSON in the system: via a normalizer. Specifically, it is this DocumentationNormalizer - https://github.com/api-plat...

C) So, like anything else in the system, you can add a custom normalizer that "extends" this. Though, I have never done this, and this is a very complex class :). Iirc, it eventually calls - https://github.com/api-plat... - so if I'm correct, it may even be easier to "decorate" this... or I think it also uses the "property name collection factory" to get the "array of all properties for a class"... and so you could also create a custom https://github.com/api-plat... and use decoration to put your custom class into the system (your custom property name collection factory would return your dynamic properties).

That was a big brain dump - let me know if any of it helps :).

Cheers!