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

Better responseModel/responseClass feature. #163

Open
tlorens opened this issue Feb 5, 2019 · 2 comments
Open

Better responseModel/responseClass feature. #163

tlorens opened this issue Feb 5, 2019 · 2 comments

Comments

@tlorens
Copy link

tlorens commented Feb 5, 2019

Having a dataMapper type method would be a nice to have. I'm having to work with a janky API which doesn't have consistency in it's results. It also is quiet generic and just returns 'data' without any description of what I'm getting back. Having a 'dataMapper' option to trigger a function/callable to iterate over the results mapping the key->values would be a way to do this. I've been able to wire this up using Guzzle Middleware::mapResponse(). However, I can't find an easy way to inject this sort of behavior based on the service/operation being called. I've got a pile of code working by overriding the ServiceClient->__call() method which seeks out the description->command->config.. which I've added an extra array element 'dataMapper' => 'App\Name\Space' and then dynamically instantiate it in the __call() method. It's an ugly ugly hack at best. Suggestions?

@alexdpunkt
Copy link

alexdpunkt commented Feb 20, 2019

Take a look at #138, @danizord had an interesting approach using a filter (e66162a) and @Konafets posted an example of an own command client implementation where the result gets wrapped by your own custom object, which could handle your data mapping.

I'm currently implementing my own data mapper based on a custom \GuzzleHttp\Command\Guzzle\Deserializer.

@tlorens
Copy link
Author

tlorens commented Apr 30, 2019

My current solution is much like what @Konafets did but with the mapper defined in the service config array. It'd be nice if the 'model' configuration would instantiate an actual 'type' object. Then you could define all your result models and they'd be assignable.

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

No branches or pull requests

2 participants