Inconsistent use of camelCase breaks things about client-php HOT 5 CLOSED

Hey @dynamodan ! Do you have some concrete examples where this is causing problems?

As mentioned in the README, the SDK is auto-generated and some of the controller functions did not have automatic model mapping - just return $response->body;

To work around this, CamelCaseHelper::keysToCamelCase($response->body) was added to transform the response to at least identical format (keys in camelCase instead of snake_case as they appear in the raw response).

Indeed there is a difference in typing: model-specific objects (a la Pipedrive\Models\CreatorUserId Object) vs stdClass Object after CamelCaseHelper. Is this the blocker for you?

from client-php.

It's for a client so I can't be very specific. Is it concrete enough to say it made my javascript throw a "can't do this because object is null" when I tried to access something in the pipedrive response by its snake_case key?

I had been loading deal IDs by using an itemSearch, then loading the deals one-by-one from the deal id using getDetailsOfADeal. Not efficient, I admit. THEN I discovered I can get the same amount of detail by doing listDealsAssociatedWithAnOrganization and that's when I got camelCased keys. The browser side javascripts were expecting the snake_cased keys as getDetailsOfADeal provides, but got camelCased keys instead.

I really don't have a preference of snake_keys over camelCased. But it would be conventional, consistent, and follow the principles of least astonishment, etc for it to be all one or the other not a mixture.

from client-php.

For now, I've worked around it by implementing an unCamelCase function in my own code.

from client-php.

Thank you for the additional details! I see now - the keys at the root level of the getDetailsOfADeal() response are mapped to camelCase as expected but some of the sub-properties (like the nextActivity object) contain snake cased keys. This definitely should not happen and we'll implement a fix to unify everything (to camel case)

from client-php.

@dynamodan would you be able to verify that #45 fixes the issue on your side?

from client-php.