Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[WIP] adds an event system #189

Merged
merged 1 commit into from
Oct 6, 2012
Merged

[WIP] adds an event system #189

merged 1 commit into from
Oct 6, 2012

Conversation

schmittjoh
Copy link
Owner

TODO: Add some docs, and tests

This adds an event system to the serializer. Basically, you can now register dedicated classes where you currently could only use methods on objects, that is on pre-serialization, post-serialization, and post-deserialization.

I've not re-used an existing event dispatcher (I've looked at Symfony, and Doctrine ones) for several reasons:

  • making listener registration cheap: You can have many event listeners without any significant performance impact now.
  • Lazy-load only what is needed; in that regard you can register listeners for a specific class and/or format only which will never be loaded otherwise.

This should help to implement something like #121 in a cleaner, more re-usable way. I've also thought about allowing listeners to skip serialization for an object, but I'm not sure about this yet.

Feedback welcome.

}

foreach (call_user_func($subscriberClass, 'getSubscribedEvents') as $eventData) {
if ( ! isset($eventData['name'])) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

according to the phpoc of the interface, it should be event, not name. either the phpdoc need to be fixed or the compiler pass

@stof
Copy link
Contributor

stof commented Oct 5, 2012

Is it possible to add additional stuff in the serialized data, which is not in the original object ?
An example would be an object storing a markdown string, and for which the serialized data should also provide the rendered content. Currently, I'm hacking this using a non-persistent property populated by a custom handler running first (and not marking the object as visited) but using a listener would be far cleaner IMO.

@@ -110,12 +109,16 @@ public function accept($data, $type, VisitorInterface $visitor)
foreach ($metadata->preSerializeMethods as $method) {
$method->invoke($data);
}

if (null !== $this->dispatcher && $this->dispatcher->hasListeners('serializer.pre_serialize', $type)) {
$this->dispatcher->dispatch(new Event($visitor, $data, $metadata));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There should be 3 more arguments. The EventDispatcherInterface interface expects $eventName, $class, $format, $event.

@baldurrensch
Copy link
Contributor

I like this. I think I could also use that to skip serialization of ToMany relations. +1

schmittjoh added a commit that referenced this pull request Oct 6, 2012
@schmittjoh schmittjoh merged commit 1a1b60a into master Oct 6, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants