Description
The PropertyPath
class currently makes a list of assumptions:
1. Objects are treated by reference
When the path author.name
is modified, the following methods are called:
getAuthor()
setName() // on the author
Note that setAuthor()
is not called.
2. Adders and removers are used if they exist
If a collection is written into the path tags
and the methods addTag()
and removeTag()
exist, these are used to merge into the old collection instead of accessing the old collection directly via its ArrayAccess
interface. The following methods are called:
getTags()
addTag(...) // instead of $tags[] = ...
removeTag(...) // instead of unset($tags[...])
3. Adders and removers follow English singularization rules
If a property path is called children
, the guessed adders and removers are addChild()
and removeChild()
.
Limitations
The above assumptions do not hold in all applications:
- Sometimes setters should be called (no by-reference handling, see [Form] by_reference when embedding a single object #6965)
- Sometimes elements should be written directly into collections even though adders/removers exist ([2.1][Form] CollectionType / PropertyPath BC Break? #4158, [Form] Fixed undefined index in writeProperty when saving value arrays #5257)
- For other languages than English, singularization does not work
So, these assumptions should be made configurable. The challenge is how to build this API in an intuitive way.
Alternative 1: Option arrays
The first alternative is to pass the options in an array separately from the property path. For example:
Path: artikel.stichwörter (= article.tags)
Options: array(
'artikel' => array(
'by_reference' => false,
),
'artikel.stichwörter' => array(
'use_adders' => false,
// or
'singular' => 'stichwort',
),
)
Alternative 2: Path flags
The second alternative is to build the configuration options into the path:
artikel{!byref}.stichwörter{!adders}
// or
artikel{!byref}.stichwörter{singular=stichwort}
Alternative 3: Your suggestions
Do you have any other ideas? What approach do you prefer?