Closed mladenilic closed 8 years ago
We are actually working on a more modern take on this SDK, which should address this and more.
I hope you don't mind me asking, but are you referring to _kco_restphp?
No, no, for the actual XMLRPC SDK.
Sounds great. Thanks for answering. :+1:
Any chance you know when could we expect first release?
@mladenilic Hopefully v5.0.0 addresses your issue. I'll close this issue.
With current file structure, this library is almost unusable in projects. Lets consider following example project structure:
Project adheres to PSR-0 standard, lib/ is added to include path, so including this library should be straightforward. Since classes in this library are not scoped under directory (Klarna/Invoice/ perhaps?), after adding it, project would look something like this:
Which looks messy to say at least. If we consider using this library alongside _kcophp library (much better one btw, real joy working with it), that's when the things get out of hand:
Libraries get merged into one messy blob of files, making it so much harder to work with them. I would also like to add that this is not some hypothetical scenario, which is unlikely to happen. Project structure used in this example is oversimplified structure of popular e-commerce framework and using these two two libraries together is almost unavoidable.
As a solution, I see scoping this library under Klarna/Invoice/, as mentioned above. That would result in a following project structure:
Which looks much, much better. This would also require some class name changes, to keep the PSR-0, which would than in turn mean that next version would not be backward compatible. Is such a change realistic? If not, I'd like to hear suggestions, which approach should one take to be able to use this library?