Ability to call client functions not wrapped in main class about postnl HOT 5 CLOSED

Actually, there's getClient. It's just protected is all. I have considered making it public in the past, but decided not to, because I figured the main class might only be an obstacle for a developer with more custom needs.

I don't think proxying all methods is a good idea, unless the wrapper function actually adds value (which is the case for the functions currently in there). Making the getClient function public is probably the best solution.

from postnl.

I think it it is more convenient to have the getClient method public. That way, there is a single access point to the api. This also prevents the consumer from dealing with the SecurityHeader. Are there any downsides in doing this?

from postnl.

Are there any downsides in doing this?

Probably only psychological. In other words, no :)

from postnl.

On second thought, that would result in code like this (and wouldn't catch CIF exceptions):

$request = new ComplexTypes\CompleteStatusRequest($message, $customer, $shipment);

// Query the webservice and return the result.
return $postnl->getClient('ShippingStatusClient')->completeStatus($request);

Making the call method available would be preferable, and using that will result in something like this (AND have proper CIF error handling):

$request = new ComplexTypes\CompleteStatusRequest($message, $customer, $shipment);

// Query the webservice and return the result.
return $postnl->call('ShippingStatusClient', 'completeStatus', $request);

If you agree then I'll patch it.

from postnl.

That is probably better. Great work!

from postnl.