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

15.

Doctrine postLoad Listener

|

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

7 Comments

Sort By

Login or Register to join the conversation

Titoine 5 years ago

Hello,
In some way, can we say that DataProvider/DataPersiter are to APIPlatform as Doctrine Entity Listener are to Doctrine?

|

MolloKhan SFCASTS Titoine 5 years ago edited

Hey @keuwa

That's an interesting question. Let's see the responsibilities of every service:

DataProvider: Is responsible for fetching the requested data and format it.
DataPersister: Is responsible for storing data. This class is kind of coupled to your storing layer
DoctrineEntityListeners: The intention of those listeners is to give you a hook point between the phases of entities lifecycle. For example, if you want to make auditable the changes of your entity records (In other words, track whenever an entity changes). You may hook into the preUpdate() event and create all the necessary records.

So, I'd say no, those are different things.

Does it makes sense to you? Cheers!

|

Titoine MolloKhan 5 years ago

Hi,
thanks for the anwser and btw your courses are neat!

As you say, the DoctrineEntityListeners is purely a place for hooking point.
But you're using UserDataPersister exactly for placing some HOOK on the persist.
The difference is you became responsible for persisting/removing data. But in reality, you just decorate the existing DataPersisterInterface and delegate this to doctrine.
Is that correct?

|

weaverryan SFCASTS Titoine 5 years ago

Hey @keuwa!

Thanks for the nice words :).

So what Diego said is true: data persisters are responsible for the entire saving process... while entity listeners are "hook points". But, you're also correct that we're *using* data persisters in this tutorial *as* a hook point: we do something, then call the core persister so that it can do the *real* work. So in that sense, the two concepts are very similar.

When would I use one vs the other? It's not an easy question to answer. If what we need to do in our hook is something "pure" and "low level" (like making some calculation, logging something, etc), then I like the doctrine listeners. But if what you're doing is more related to your API (e.g. sending emails after a new user registers), then I would do it there. I wouldn't want a registration email to be sent automatically if I were doing some bulk data import of legacy users... and my "entity listener" suddenly triggered and emailed all of them.

Anyways, I hope that makes sense!

Cheers!

|

Titoine weaverryan 5 years ago

Ok, get it, thanks!

|

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