Major touchup

[omares]

• Added docblocks
• Added namespace
• Improved composer configuration
• Streamlined the API (BC Breaks).
• Refactored code for more readability
• Added adapters. Guzzle as client is now interchangeable.
• Added request and response filters. Users can now modify the Symfony requests and responses to their liking.

[dfreudenberger]

seems redundant

[omares]

Btw, the project should be added to the https://packagist.org/ list for easier installation. :)

[jenssegers]

Having a different Factory class for each adapter seems a bit overkill to me. Would it not be better to use something similar like the Laravel connection manager? A single class that would create proxy objects based on the default adapter or by selecting a different adapter. Something like this:

Factory::create(); // returns a Proxy with a GuzzleAdapter

Factory::create('dummy'); // returns a Proxy with a DummyAdapter

Factory::setDefaultAdapter('dummy');
Factory::create(); // returns a Proxy with a DummyAdapter 

This is similar to what I'm using from Lusitanian/PHPoAuthLib:

$facebookService = $serviceFactory->createService('facebook', ...);

[omares]

@jenssegers Yeah i would apply the Abstract Factory pattern (A Main Factory uses the various other Factories to create the one you want) but atm there is only one Adapter and so there is no need. Anyway the GuzzleFactory should stay because the MainFactory would need it to for creation.

Btw if we are okay with the current api and feature set ill start creating unit tests.

[jenssegers]

I just want it to be as easy as possible for developers to use this proxy. Creating too many classes might make it a bit too difficult to get started.

[omares]

Thats why i wouldnt add another factory ;)

[jenssegers]

I merged the PR, let me know what you think.

For now, I included Guzzle in the composer file. Because it seemed a bit silly to suggest a package which it needs to work properly.

[omares]

Cool, thanks for the merge! :) Working on some unittests right now. Here is a my feedback regarding your changes:

• When vardumping the response you also see the headers, which is nice for demo/testing. Thats why i would keep it in the example.
• It became pretty common to add the Interface Suffix to Interfaces. (e.g. Syfmonfy or Guzzle do it) to avoid name clashes with the proper implementations.
• Having namespaced classes in the docblocks is unnecessary and just adds maintenance overhead. Why the change?
• Why did you change the visibility of the private variables and methods? Keep your api small and clean, allowing overloading will lead to messy code. People will extend instead of inherit.
• Why the old array synatx [] vs array()?
• You removed information regarding the Type of the the filter arrays, that makes me sad. Now my IDE is unable to autocomplete the methods and it also is a common standard to annotate it that way.
• Why removing the explizit PhpProxy Exception? So now its impossible for users to distinguish between common and library problems? :(
• Creating instances of classes in the Adapter breaks various principles like loose coupling. ($this->client = $client ?: new Client;) Thats a change i really cannot appreciate and understand, thats why we have a factory.
• Please please please revert the RewriteLocationFilter changes, thats something you maybe need and thats why you should implement an own filter in your application but dont enforce it on the library users.

[omares]

And overall i would suggest following the PSR-2 Standard regarding formatting, naming, etc. Makes maintenance easier when you can follow a common standard.

[jenssegers]

• I have been watching too many laracasts video's I think. Jeffrey Way always drops the Interface suffix. Adding it again is not that big of a deal.
• Laravel also uses full namespaces classes in docblocks, that's why I did so as well. But this can be changed if it's better without.
• I prefer having protected methods vs. private methods.
• I'm used to writing array() in libraries so that the code would be usable on PHP 5.3. Increasing the PHP version, for just [] seems a bit silly.
• What do yo mean with "type of the the filter arrays"? The type in the docblock?
• I think the native InvalidArgumentException is okay. It's only 1 exception, and it has a decent error message.
• I think the GuzzleAdapter is fine, you can still inject the client if you want to.
• I'm not enforcing the RewriteLocationFilter, it's just there if they need it.

[omares]

• Could you elaborate on the private vs protected method argument. Just because to have it, is not a strong argument regarding SOLID principles. Always use the lowest possible visbility, make it private if you dont know why it should be protected.
• Regarding the php version: Why not? PHP has now has a pretty steep release cycle, libraries shouldnt sit on old versions like a duck that prevents evolution ;)
• Yeah i meant the type in the docblock @var RequestFilterInterface[] instead of simply array.
• Adding an specific exceptions doesnt hurt anybody and gives us more flexibility.
• Imho the clienst is not fine, you are building up relations that are hard to break. DI Container, and IoC are there to prevent that kind of binding.
• Wont argue about the RewriteLocationFilter, i still think its to specific. Do you mind when i re add the RemoveLocationResponseFilter?