Testing Guzzle Services doesn't work about guzzle-services HOT 7 CLOSED

I just tagged a release of guzzle/command that addresses various issues I encountered while testing command based clients. Can you pull that down and see if it helps?

from guzzle-services.

Hey,

thanks for updating the repository. I still encounter the same issue. Here's the guzzle part of my package.json :

"require": {
    "guzzlehttp/guzzle": "~4.0",
    "guzzlehttp/guzzle-services": "dev-master",
    "guzzlehttp/command": "0.4.0",
}

from guzzle-services.

Hi again,

I have finally solved, but I think this is still an issue.

The problem was that I didn't know that I had to replace the responseClass by responseModel, as it was not documented in the https://github.com/guzzle/guzzle/blob/master/UPGRADING.md .

FurtherMore, the test to see if an operation has a responseModel fails silently:

    $operation = $command->getOperation();
    if (!($modelName = $operation->getResponseModel())) {
        return;
    }

in the ProcessResponse Class

from guzzle-services.

Hey guys! Sorry for jumping in out of nowhere.

@edi9999 if you want a working Guzzle 4 service client example, please take a look at this - https://github.com/dev-machine/guzzle-markus-client

It might be not perfect (as I'm investigating Guzzle 4 myself), but at least you can have a reference at service description and some tests. hth

from guzzle-services.

Yeah, you definitely need to specify responseModel (previously responseClass). I don't see that specified in your provided code which explains why nothing happened. I think it makes sense to convert responseClass attributes to responseModel when constructing an operation so that this works without needing to change an existing description.

As for failing silently, that's intentional; the command event system does not force a specific implementation but just provides a framework for injecting results onto commands. This should be allowed in most implementations of the command package to allow for flexible interoperability with other subscribers (e.g., someone might make a cache subscriber that intercepts commands).

from guzzle-services.

Ok thanks for the explanation, makes sense actually.

@lakiboy thanks a lot too, seems to be doing the same abstract things as I want !

from guzzle-services.

I pushed a change to make sure that responseClass is an alias of responseModel.

from guzzle-services.