You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
What about moving the Piwik\IP class out of Piwik and into a standalone repository?
Most of this class is completely unrelated to Piwik, I've done a POC and it was fairly easy to move it out. The good thing with this is that we can take advantage of this to refactor it into a non-static class. And we can also add more unit tests as the new class will have no global state.
Piwik\IP would actually be kept where it is for backward compatibility, however the content of the class would be moved.
After a quick discussion with some of us we thought naming that new component network would be better than ip, it leaves us the opportunity to move additional classes in there later if applicable. Thoughts?
We also thought about moving Piwik\Url in the new component. But I disagree with that because Piwik\Url has actually much more to do with the current request than urls (i.e. it's mostly a wrapper over $_SERVER). I see that class replaceable with a Request class (either Symfony or our own or whatever, that's not the topic), and to me it belongs more in a HTTP/MVC component (like Symfony's HttpFoundation for example). For the few methods that are strictly related to URLs (i.e. manipulating string urls), 3rd party librairies already cover that (e.g. http://url.thephpleague.com/). So all in all, I don't think Url should be moved to the network component, at least not right now.
The text was updated successfully, but these errors were encountered:
mnapoli
added
the
RFC
Indicates the issue is a request for comments where the author is looking for feedback.
label
Oct 22, 2014
There's also something really cool: we can move the IP anonymization stuff from the IPAnonymizer plugin into the new IP class. Anonymizing an IP address is pretty standard stuff (for a library to manipulate IPs) so I think it definitely belongs there. That's also good because we can move some more tests out of Piwik.
Related to #6487
What about moving the
Piwik\IP
class out of Piwik and into a standalone repository?Most of this class is completely unrelated to Piwik, I've done a POC and it was fairly easy to move it out. The good thing with this is that we can take advantage of this to refactor it into a non-static class. And we can also add more unit tests as the new class will have no global state.
Piwik\IP
would actually be kept where it is for backward compatibility, however the content of the class would be moved.After a quick discussion with some of us we thought naming that new component
network
would be better thanip
, it leaves us the opportunity to move additional classes in there later if applicable. Thoughts?We also thought about moving
Piwik\Url
in the new component. But I disagree with that becausePiwik\Url
has actually much more to do with the current request than urls (i.e. it's mostly a wrapper over$_SERVER
). I see that class replaceable with aRequest
class (either Symfony or our own or whatever, that's not the topic), and to me it belongs more in a HTTP/MVC component (like Symfony's HttpFoundation for example). For the few methods that are strictly related to URLs (i.e. manipulating string urls), 3rd party librairies already cover that (e.g. http://url.thephpleague.com/). So all in all, I don't think Url should be moved to the network component, at least not right now.The text was updated successfully, but these errors were encountered: