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

18.

Property Metadata

|

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

10 Comments

Sort By

Login or Register to join the conversation

Gianluca-F 3 years ago

Hi,
I have a hierarchy of contents: News extends Content, Tag extends content.
Slug is defined on Abstract Content superclass.

The problem is that the identifier for the News is the {id} but the identifier for the Tag is {slug}; the Slug, common to both entity, is on Superclass.
Is there a way to customize ApiProperty(identifier=<<some function>>) so I can avoid to replicate slug property also on tag, only because identifier is different from news?
I have tried with ApiProperty(identifier=self::SLUG_AS_IDENTIFIER) , in superclass, but obviusly does not work cause self is related to masterclass, also in Tag class ... static::SLUG_AS_IDENTIFIER does not work..

Is possible? or I have to define $slug also on Tag?

Thanks

|

weaverryan SFCASTS Gianluca-F 3 years ago

Hey Gianluca-F!

The only way I can think of is to hook into the "property metadata factory" system: this is the system that collects all of the API Platform metadata about each property. To do this, you would create a service that decorates https://github.com/api-platform/core/blob/2.7/src/Metadata/Property/Factory/PropertyMetadataFactoryInterface.php - kind of like we do for the resource metadata factory here - https://symfonycasts.com/screencast/api-platform-security/resource-metadata-factory - except that decoration is easier in Symfony now with the AsDecorator attribute.

Anyways, you would add your own property metadata factory decorator that, when called, would call the inner property metadata factory then, if the resource class is the class you want and the property is the one you want, change its metadata to set it as an identifier / not an identifier. Looking at one of the core decorators might help: https://github.com/api-platform/core/blob/2.7/src/Metadata/Property/Factory/AttributePropertyMetadataFactory.php

So, doable - but not in a super simple way.

Cheers!

|

Mihail 5 years ago

hello, tried with old and the latest api platform versions, but somehow normalization context +groups does not help show fields for this DailyStats, really strange, for User and CheeseListings - works as expected, I use SF5.2
clearing cache didn't help https://github.com/api-plat...

|

weaverryan SFCASTS Mihail 5 years ago edited

Hey Mihail !

Hmmm. So you simply mean that, if you set normalizationContext={"groups"={"daily-stats:read"}}, and then put @Groups({"daily-stats:read"}) above a property (exactly like we're doing in this video), that property isn't returned? Or are you doing something a bit different that we're doing here? It is possible that a bug was introduced in Symfony 5.2, but in that case, I can't think why it would affect this class, but not the entity classes.

Cheers!

|

Mihail weaverryan 5 years ago

Hey, Ryan!

Definitely, I tried to rewrite this part several times, this happens only to the custom resource.
I checked on github that APIPlatform is still being updated to SF5.2 and the issue is present in `2.6.0-alpha.1` https://github.com/api-plat...
The version for code example to this tutorial for SF5.1 works as expected.

|

weaverryan SFCASTS Mihail 5 years ago edited

Hey Mihail!

Ah, interesting! What happens if you try Symfony 5.2 and API Platform 2.5? API Platform 2.5 does work Symfony 5.2 - the ^5.1 in API Platform's composer.json allows 5.2. I would be curious if the bug lies in using Symfony 5.2 or API Platform 2.6 (my "instinct" is that it is in API Platform 2.6, but I could definitely be wrong). If we can figure this out, it would be worth creating an issue on either API Platform or Symfony - it smells like a bug.

Cheers!

|

Mihail weaverryan 5 years ago edited

OMG I see the mistake "dailystats:read" vs "daily-stats:read"

Somehow it does not react to manual setting normalizationContext groups either in camelcase "dailyStats:read" or with dash "daily-stats:read", or "dummystats:read". But the data is displayed correctly with default groups "dailystats:read"`

For class defined like below I see only totalVisitors``

/**

@ApiResource(
normalizationContext={"groups"={"dummystats:read"}},
itemOperations={
"get"={},
},
collectionOperations={"get"}
)
/ class DailyStats { /*
- @Groups({"dummystats:read"})
  */
  public $date;
/**
- @Groups({"dailystats:read"})
  */
  public $totalVisitors;
  }
  `

1 |

weaverryan SFCASTS Mihail 5 years ago edited

Hey Mihail!

Wait, I want to make sure I'm not getting confused. In the above code, where you have "groups"={"dummystats:read", ONLY the totalVisitors property is returned... even though it only has the group dailystats:read? Who/what is setting that group - do you have some "context builder" somewhere that's adding extra groups? I think I'm not seeing some detail...

Cheers!

1 |

Mihail weaverryan 5 years ago

Hey Ryan,

Oh yeah, now I see my mistake, I'm still using the `AutoGroupResourceMetadataFactory::getDefaultGroups` from https://symfonycasts.com/sc...

While it has been deleted for the 3rd tutorial :)

Just disabled - everything works!

|

weaverryan SFCASTS Mihail 5 years ago

Whooops! Yea, sorry about that. I deleted it for the 3rd tutorial to help make "less" variables for people watching the tutorial to keep track of... but it had the opposite effect for you!

Happy you figured it out!

Cheers!

1 |

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