You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jan 21, 2020. It is now read-only.
As reported on the mailing list, create() casts $data to an object if it is an array. This is useful to ensure that any changes a listener makes to $data will be reflected in the event for later listeners. However, it breaks one critical situation: when a user posts multiple entities at once (which will be an array of either arrays or objects).
The logic for this needs to be updated to accommodate both use cases. One possibility is to cast to an ArrayObject, but I'm unsure if that will address the "changes made in one listener will affect later listeners" use case (in the event that an item in the ArrayObject is an array, and that item is changed).
The text was updated successfully, but these errors were encountered:
…ion routines
- Altered `create()` to only inject the Location header if the entity
has an identifier. If no identifier is present, it no longer raises a
problem response.
Is reasonable that if $datais a list then items in $data are casted to objects (like in *List methods)?
Also, casting to object the first level only of $data does not address the "changes made in one listener will affect later listeners" in case of nested arrays too (I noticed that using a resource with embedded resources).
Could a recursive conversion of $data (using ArrayObject for lists and casting to object for hashmaps) address all use cases?
I'd like this solution if there're no side effects nor BCs.
PS: right now I've found the usage of ArrayObject in patchList but not in other methods.
As reported on the mailing list,
create()
casts$data
to an object if it is an array. This is useful to ensure that any changes a listener makes to$data
will be reflected in the event for later listeners. However, it breaks one critical situation: when a user posts multiple entities at once (which will be an array of either arrays or objects).The logic for this needs to be updated to accommodate both use cases. One possibility is to cast to an
ArrayObject
, but I'm unsure if that will address the "changes made in one listener will affect later listeners" use case (in the event that an item in theArrayObject
is an array, and that item is changed).The text was updated successfully, but these errors were encountered: