Chapters

48 Chapters | 5:13:28 |

01

App & Test Setup

7:44
02

Data Persister Decoration

6:48
03

Decorating Data Persisters vs Context Builders

8:54
04

Custom Logic Only for some Operations

5:02
05

Publishing a Listing

6:02
06

Detecting the "Published" State Change

9:08
07

Validating Who/When Can Publish

8:22
08

Publish State Change Validator Logic

8:26
09

Completely Custom Field via a Data Provider

9:19
10

Leveraging the Doctrine Data Provider

5:27
11

Adding & Populating the Custom Field

5:10
12

Custom Item Data Provider

6:57
13

Setting a Custom Field Via a Listener

5:32
14

Core Listeners & Accessing the "Resource" Objects

4:37
15

Doctrine postLoad Listener

8:03
16

Completely Custom Resource

5:25
17

Custom Resource Data Provider

6:40
18

Property Metadata

6:20
19

Why/When a Many Relation is IRI Strings vs Embedded

5:19
20

Collection "Types" and readableLink

7:12
21

Custom Resource GET Item

5:50
22

Custom Paginator

7:04
23

Pagination Context

7:09
24

Custom Resource PUT Operation

5:19
25

Custom Filter, getDescription() & properties

7:09
26

Custom Filter Logic for Entities

8:25
27

Custom Filter for Custom Resources

7:49
28

Custom Filter apply()

8:15
29

Filter Class Arguments

4:26
30

Filter Autowiring

5:46
31

Output DTO Class

4:40
32

DTO Data Transformer

5:31
33

Output Properties & Metadata

7:14
34

DTO Quirks

5:23
35

DTO Quirks: Embedded Objects

6:37
36

Input DTO Class

7:16
37

Input DTO: Denormalizing IRI Strings

5:33
38

Input Data Transformer

4:24
39

Input DTO Update Problems

6:38
40

DTO Input "Initializer"

6:41
41

DTO Input Initializer Logic

6:19
42

DTO Class Organization

5:12
43

Type Validation

7:29
44

Input DTO Validation

5:43
45

UUID's

7:29
46

UUID as a API Identifier

5:16
47

Setting the UUID on POST

5:15
48

UUID Quirk with "id" Name

7:09

This tutorial has a new version, check it out!

> Symfony 5 > API Platform 2 Part 3: Custom Resources

Buy Access to Course

44.

Input DTO Validation

|

Autoplay

Keep on Learning!

If you liked what you've learned so far, dive in! Subscribe to get
access to this tutorial plus video, code and script downloads.

Start your All-Access Pass

Buy just this tutorial for $12.00

Previous Chapter

Next Chapter

With a Subscription, click any sentence in the script to jump to that part of the video!

Login Subscribe

Login or register to check out the script

5 Comments

Sort By

Login or Register to join the conversation

adeoweb 4 years ago edited

Ryan, I think you forgot one constraint under CheeseListing: the one called ValidIsPublished, which is applied to the class itself. Ironically, this constraint might be especially troublesome to move not only because we made it to specifically work with CheeseListing objects only, but also because it involves digging into Doctrine internals, which would likely complicate moving the constraint to a non-entity even further. I wonder how you would have solved that. :)

|

weaverryan SFCASTS adeoweb 4 years ago edited

Hey Adeoweb!

Ah, nice catch! I can't remember now if I did this on purpose... or accident, but I do sometimes miss details like this :).

But let's think. For reference, here is the finished validation logic: https://symfonycasts.com/screencast/api-platform-extending/validator-logic#codeblock-f8b1e9b4ae

I think the key difference is that, if we added this constraint above our input class, the actual CheeseListing entity will, I believe, NOT have been modified yet: only the input class will be modified at this point. And so, believe the logic actually becomes a bit simpler. To get the "original value", instead of using using Doctrine's UnitOfWork, we could just query for the CheeseListing entity itself inside the validator and read its value. Well, to do that, we would need the id, which we don't have. So intsead, I would inject the RequestStack and grab the current request. The CheeseListing object should then be accessible via $request->attributes->get('data'). I believe that would be null if this is a CREATE operation. And so, in that case, you would know that the "original published value" is "false".

Does that help? I could be missing something - I'm just "coding by looking" here, but I think that would do it :).

Cheers!

|

adeoweb weaverryan 4 years ago

"Does it help?" – I don't know, but I guess it would, if it was the problem I was facing. Although injecting stuff like UOW and RequestStack into validators seems somewhat dirty. I'm lucky I don't need to validate cases like this, or I'd be stuck trying to find better ways for a while. :D

|

Simo 5 years ago edited

Hi folks,

there is a small thing which confuses me and I would appriciate if someone could clear thigns for me. In CheeseListingInputDataTransformer:25 we call validator and validate user input but I feel thing might not be the optimal place for it. Shouldn't we do the validation after we merge user-provided input with whatever we potentialy have in DB or I'm missing something. Something like this:

<b>tl;dr;</b>


    public function transform($input, string $to, array $context = [])
    {
     // $input might only be partialy set here, for example if we're in an update
     // $this->validator->validate($input);


    $cheeseListing = $context[AbstractItemNormalizer::OBJECT_TO_POPULATE] ?? null;


     $cheeseListingInput = $input->createOrUpdateEntity($cheeseListing);


     // At this point we need to be sure that $cheeseListingInput is 100% valid
     $this->validator->validate($cheeseListingInput);


     return $cheeseListingInput;
    }

|

weaverryan SFCASTS Simo 5 years ago edited

Hey @s!

I think I can help with this :). The flow is a bit complex. Here is what's going on (by the time you've finished this chapter):

1) API Platform queries for the actual CheeseListing entity object from the database
2) Thanks to our custom denormalizer - https://symfonycasts.com/screencast/api-platform-extending/input-initializer and the next chapter - we create a CheeseListingInput DTO that is populated with data from the database
3) API Platform then deserializes the JSON from the user onto our CheeseListingInput. This is invisible to us - it happens between our custom normalizer (described above) and our data transformer (next step). This is when, effectively, the user's JSON is merged with the database daata
4) THEN, our data transformer is called. By the first line of transform(), the $input object already represents the merged database and user input data.

So when you say:

Shouldn't we do the validation after we merge user-provided input with whatever we potentialy have in DB

You re 100% correct! That "merge" happens on step 3, which means at step 4 (in our transform() method) it's the perfect place to validate.

As I mentioned, the flow is complex because API Platform does a few things in the background, and we do a few things throughout that process. Hopefully seeing it all listed helps.

Let me know!

Cheers!

|

This tutorial also works great with API Platform 2.6.

Api Platform 2.5 Symfony 5

What PHP libraries does this tutorial use?

// composer.json
{
    "require": {
        "php": ">=8.2",
        "ext-ctype": "*",
        "ext-iconv": "*",
        "api-platform/core": "^2.1", // v2.5.10
        "composer/package-versions-deprecated": "^1.11", // 1.11.99
        "doctrine/annotations": "^1.0", // 1.12.1
        "doctrine/doctrine-bundle": "^2.0", // 2.1.2
        "doctrine/doctrine-migrations-bundle": "^3.0", // 3.0.2
        "doctrine/orm": "^2.4.5", // 2.8.2
        "nelmio/cors-bundle": "^2.1", // 2.1.0
        "nesbot/carbon": "^2.17", // 2.39.1
        "phpdocumentor/reflection-docblock": "^3.0 || ^4.0 || ^5.0", // 5.2.2
        "ramsey/uuid-doctrine": "^1.6", // 1.6.0
        "symfony/asset": "5.1.*", // v5.1.5
        "symfony/console": "5.1.*", // v5.1.5
        "symfony/debug-bundle": "5.1.*", // v5.1.5
        "symfony/dotenv": "5.1.*", // v5.1.5
        "symfony/expression-language": "5.1.*", // v5.1.5
        "symfony/flex": "^1.1", // v1.21.6
        "symfony/framework-bundle": "5.1.*", // v5.1.5
        "symfony/http-client": "5.1.*", // v5.1.5
        "symfony/monolog-bundle": "^3.4", // v3.5.0
        "symfony/security-bundle": "5.1.*", // v5.1.5
        "symfony/twig-bundle": "5.1.*", // v5.1.5
        "symfony/validator": "5.1.*", // v5.1.5
        "symfony/webpack-encore-bundle": "^1.6", // v1.8.0
        "symfony/yaml": "5.1.*" // v5.1.5
    },
    "require-dev": {
        "doctrine/doctrine-fixtures-bundle": "^3.3", // 3.3.2
        "symfony/browser-kit": "5.1.*", // v5.1.5
        "symfony/css-selector": "5.1.*", // v5.1.5
        "symfony/maker-bundle": "^1.11", // v1.23.0
        "symfony/phpunit-bridge": "5.1.*", // v5.1.5
        "symfony/stopwatch": "5.1.*", // v5.1.5
        "symfony/twig-bundle": "5.1.*", // v5.1.5
        "symfony/web-profiler-bundle": "5.1.*", // v5.1.5
        "zenstruck/foundry": "^1.1" // v1.8.0
    }
}

Previous Chapter

Next Chapter