-
-
Notifications
You must be signed in to change notification settings - Fork 312
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
perform default deserialization in the custom handler #353
Comments
You should be able to call the visitor/navigator with an updated type to On Mon, Dec 30, 2013 at 10:22 AM, PLEEROCK [email protected] wrote:
|
Any hints/docs/examples? Do you mean to call this method |
This should be reopened. The only way I figured you can continue the default serialization process is to call $nav->accept($data, $type, $visitor). But that only create an error with "maximum function nesting level reached" because the accept method will call the custom handler again. What it need is a way to tell the serializer to bypass the handlerCallback somehow, or make the context accessible outside the GraphNavigator. |
Does anyone have find a solution for this problem ? It would be really useful if we can load the correct entity if an id is passed or use the default process otherwise. A simple solution would be, to return false or throw a special exception when we want to use the default process, and in the navigator accept method continue the process instead of return the res. |
Bumped into this as well. I want to manipulate the data in the handler and then simply tell the serializer to continue as usual but with the updated data. |
I'm interested in this feature: http://stackoverflow.com/questions/20489479/jms-serializer-visitor-continue-default-deserialization . Sometimes you want to continue default serialization if some of conditions failed. or perform default serialization and then your custom over it. Any support?
The text was updated successfully, but these errors were encountered: