Aggregate hydrator #4448
Aggregate hydrator #4448
Conversation
|
Note: please ignore CS! I'm not handling CS until it is clear what path has to be taken. |
|
|
||
| public function add(HydratorInterface $hydrator, $priority = self::DEFAULT_PRIORITY) | ||
| { | ||
| $this->getEventManager()->attachAggregate(new HydratorListener($hydrator), $priority); |
There was a problem hiding this comment.
Feedback needed: this attaches both to the extract and the hydrate event with the same priority. Usually, extraction is symmetrical to hydration, should I therefore attach one with $priority and another with - $priority?
There was a problem hiding this comment.
This remains a tricky one - @weierophinney any idea on how to make this flexible enough to avoid regretting any wrong choice now? :)
|
What are the benefits here of the EM? If you only need priorities, no short circuiting and reusing the same priority, I think you can use the Zend\Stdlib\PriorityQueue too? They are in the same component, so that saves another dependency. |
|
@juriansluiman didn't think about the dependency: good point! The basic use case for the EventManager here is applying decoration work on hydrated/extracted data. A simple use case would be serialization of an object an adding HAL data to it later on. Another use case may be removal of fields that are not allowed for displaying in frontend |
| * Attaches the provided hydrator to the list of hydrators to be used while hydrating/extracting data | ||
| * | ||
| * @param \Zend\Stdlib\Hydrator\HydratorInterface $hydrator | ||
| * @param int $priority |
There was a problem hiding this comment.
Will not make the HydratorListener symmetrical for now. I think that's a fairly advanced use case that should be handled by the user in very particular cases /cc @prolic
ghost
assigned 
…ture/aggregate-hydrator [WIP] Aggregate hydrator
As of #3829, this PR tries to implement a fairly flexible aggregate hydrator
zendframework/zend-eventmanager