[PropertyAccess] Allow different prefixes than "add" and "remove"

[webmozart]

Currently, adders and removers must be prefixed with "add" and "remove". When applying DDD, this sometimes doesn't make sense, for example:

class Contact
{
    public function addGroup(ContactGroup $group) { }
    public function removeGroup(ContactGroup $group) { }
}

Here it would make much more sense to prefix the methods with "join" and "leave":

class Contact
{
    public function joinGroup(ContactGroup $group) { }
    public function leaveGroup(ContactGroup $group) { }
}

The PropertyAccessor should provide a way to use these methods.

[webmozart]

ref #5013

[stof]

@bschussek it should actually allow defining the full name for adders and removers, not only the prefix. This will allow people to customize it in case they write their method names in a different language than English, for whch the inflection rules will fail to find the singular. See #9205 for the report

[dolbertz]

I would like to take on this ticket as my first active involvment with Symfony.

In which branch should I make this contribution?
And what about the best approach to this? Adding the name of the getter/setter as another parameter to PropertyAccessor::get/setValue() seems a bit harsh. Maybe an $options array Parameter? With 'callback' as key?

[dolbertz]

After looking further into this and into Ticket #5013 I don't think this is such an Easy Pick. Adding the ability to the current setValue/getValue through an $options array would lead to a lot of changes just so that PropertyAccessor::findAdderAndRemover() can use those settings.

That could call for a similar approach as the enableMagicCall(). Maybe something like enableCallbacks() which takes an array of callback names for add/remove/get/set.

I really would like to get some feedback on this.

[TomasVotruba]

@webmozart Is this still relevant?

I've been using this component so this might be easy.

What's the final decision? I would be for custom callbacks. Because there might be loads off different prefixes like has/join/leave/remove/attach/add/get/set etc... (just from the top of my head).

Any relevant sources?

[TomasVotruba]

Ping @webmozart

[webmozart]

@TomasVotruba Indeed this is not such an easy pick. This post in #9336 and the following posts explain how this could be solved in a nice manner.

The difficulty is that, if we use annotations to configure property paths, we also have to provide XML and YAML mappings and their respective loaders, as we do in other places. That's quite a bit of work and duplicating what we already have in other components. A solution for this problem (at least for XML) would be native support for XML-based annotations in Doctrine, and as far as I know (ping @Ocramius) this is WIP.

Second, we could refactor all the different metadata loaders into a separate component. There is a library that does that already, but it's not maintained anymore and I'm not sure whether it applies to our use cases.

The benefit is that the PropertyAccess-based serializer would become more powerful, as would the Form component.

[lrlopez]

@webmozart I've been studying how metadata gets loaded by other Symfony components (i.e. Validator, Routing, etc.) and you're right: there is a lot of overlapping. I'm about to try replicating the loader code from the Validator component while taking out any unneeded feature as a first approach.

Later we can figure out how to extract all metadata loaders their own independent component. The library you pointed out, jms/metadata could be used as a base (it seems to be rather stable and supports pluggable caching) so we'd just have to implement the annotation, YAML and XML drivers. Then we could refactor all the current code that need metadata info to use the new component.

[fabpot]

Just a quick note: jms/metadata cannot be used due to licensing issues.

The loader from the Validator component is the one that we need to get rid of. All the other components are already using a standardized way.

[Ocramius]

and as far as I know (ping @Ocramius) this is WIP.

It's not something for ORM 2.x anyway. We are crunching on it, but far from getting anywhere soon, sorry.

[sstok]

https://github.com/rollerworks/metadata/ MIT licensed, documentation is missing currently.
You can see a working implementation in https://github.com/rollerworks/search-metadata

Feel free to reuse my work and move it Symfony 👍

[lrlopez]

Thanks @fabpot for the hint. I had already changed my mind and used the Serializer mapping as the implementation reference because I found its code much cleaner. Anyway, it hurt a lot copying so many LOCs, it just doesn't seem right.

@sstok, I'll have a look into it, I really appreciate your offer.

[lyrixx]

@Korbeil #30704 has been merged. Does it help this issue?

[Korbeil]

@Korbeil #30704 has been merged. Does it help this issue?

Yes, now you can instantiate PropertyAccessor with custom $writeInfoExtractor and you can give him: new ReflectionExtractor(null, null, ['join', 'leave']); to use theses prefixes.

In services.yaml, you'll have to do:

CustomWriteInfoExtractor:
  class: Symfony\Component\PropertyAccess\PropertyAccessor
  arguments:
    $arrayMutatorPrefixes: ['join', 'leave']

Symfony\Component\PropertyAccess\PropertyAccessorInterface: 
  arguments:
    $writeInfoExtractor: '@CustomWriteInfoExtractor'