The Symfony\Component\Form\Util\PropertyPath has changes in its behavior.
My question is; whether this is intended and if so should be noted as a BC break, or whether the given object should be considered valid (maybe adding an option to force the use of the setter method):
An object having the methods addOccupation and setOccupations (Propel model) worked by using setOccupations.
The same object is now broken, the PropertyPath::writeProperty throws an Exception due to the missing removeOccupation method. However, the setOccupations is still there, but not used anymore.
The question is how PropertyPath should behave in that case?
If we remove the exception and change it to use setOccupations unless both the add and remove method are found, it is very hard to spot why for example the add method is not used when the developer simply forgot to add the remove method as well.
That's the case, where/why I would suggest to add an option that's false by default; allowing one to force the usage of the setter, despite the fact there is only one (or even both) of the add and remove methods.
btw, shouldn't the by_reference option allow to change this ?
It used to be; as far as I can see this is not passed to the PropertyPath itself, only the PropertyPathMapper is using it to reference or clone the value to further determine whether an actual change is required.
@stof: Not anymore. Handling of add/remove has been moved into the PropertyPath class. Think of a form field with the following property path:
The field maps to a collection. There are three possible approaches for modifying this collection:
The question is how PropertyPath distinguishes between 2 and 3. Any solution to this problem necessarily introduces a new syntax that enforces usage of a setter/adder, for example
// enforce setter usage, use adders by default if present
// enforce adder usage, use setter by default if present
The problem is that we already introduced a special syntax for configuring custom singulars, which is
We must take care now not to introduce anything that will hurt us in the future, for example, by limiting the set of allowed property names.
@bschussek @havvg I have a PR for Propel waiting to add remove method, but with that I got an issue with the property path :
The remove method work only for the first element, because when remove is called, the collection is modified and the foreach break.
to make it work I have to add this line in PropertyPath.php:495 :
$previousValue = is_object($previousValue)? clone $previousValue : $previousValue;
@jaugustin Could you please open a separate ticket for this? I'll look at this.
Closing this old issue.