{"action":"created","issue":{"url":"https://api.github.com/repos/primefaces/primefaces/issues/3542","repository_url":"https://api.github.com/repos/primefaces/primefaces","labels_url":"https://api.github.com/repos/primefaces/primefaces/issues/3542/labels{/name}","comments_url":"https://api.github.com/repos/primefaces/primefaces/issues/3542/comments","events_url":"https://api.github.com/repos/primefaces/primefaces/issues/3542/events","html_url":"https://github.com/primefaces/primefaces/issues/3542","id":309808151,"number":3542,"title":"Remove CoreRenderer","user":{"login":"Rapster","id":7521311,"avatar_url":"https://avatars0.githubusercontent.com/u/7521311?v=4","gravatar_id":"","url":"https://api.github.com/users/Rapster","html_url":"https://github.com/Rapster","followers_url":"https://api.github.com/users/Rapster/followers","following_url":"https://api.github.com/users/Rapster/following{/other_user}","gists_url":"https://api.github.com/users/Rapster/gists{/gist_id}","starred_url":"https://api.github.com/users/Rapster/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Rapster/subscriptions","organizations_url":"https://api.github.com/users/Rapster/orgs","repos_url":"https://api.github.com/users/Rapster/repos","events_url":"https://api.github.com/users/Rapster/events{/privacy}","received_events_url":"https://api.github.com/users/Rapster/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":9,"created_at":"2018-03-29T15:49:15Z","updated_at":"2018-04-03T11:54:17Z","closed_at":null,"author_association":"CONTRIBUTOR","body":"Lately, I was having a look to CoreRenderer and realized it's more an utility than a Renderer per say. I'll go straight to the point, but what about moving all methods in RendererUtils, and delete CoreRenderer?\r\n\r\n> Thomas Andraschko\r\n> +0\r\n> moving to a util makes nothing better\r\n> You would have a SelectRendererUtils instead of SelectRenderer...\r\n\r\n> Sébastien Lepage\r\n> Well, first it gives less complexity to the class hierarchy. Second, let's say I'm creating a custom Renderer which already inherits from something, I can't reuse utility method of CoreRenderer, only choice I'll have left is copy/paste. SelectRendererUtils? CheckRendererUtils (which btw is RendererUtils)? I don't know... why not? Or put everything in RendererUtils... Another reason is, when I read a class I expect some of these method to be used as Template Method pattern, but none of these are, which is kind of confusing... it's not when you realized that, these methods are utils and not instance based. Last reason is, on a performance level it might have a difference, since the method is not related to an object but a class, i won't put my money it, but it might be faster. Saying all this, I think it will be better to remove CoreRenderer and move these methods in RendererUtils\r\n\r\n> Thomas Andraschko\r\n> For me there is no reason as\r\n\r\n> - all of our component renderers inherit from CoreRenderer\r\n> - there is no performance difference\r\n> - we already have soo many utils, i prefer inheritance\r\n> \r\n> but lets talk later, i currently don't have time to do big refactorings\r\n> maybe in ~2 months\r\n> as i said, i currently don't like that much utils and with the escaping stuff, they get even more\r\n\r\n\r\n> Sébastien Lepage\r\n> - all of our component renderers inherit from CoreRenderer: IMO, this is actually a design mistake\r\n> - there is no performance difference, it won't make 5x faster sure, but I'm not an export in memory allocation either so I can't really argue\r\n> - we already have soo many utils, i prefer inheritance: I don't think this is a good reason to not doing it, if it makes more sense to be static method so be it. Number of utils shouldn't be a problem as long their responsability are well defined"},"comment":{"url":"https://api.github.com/repos/primefaces/primefaces/issues/comments/378223873","html_url":"https://github.com/primefaces/primefaces/issues/3542#issuecomment-378223873","issue_url":"https://api.github.com/repos/primefaces/primefaces/issues/3542","id":378223873,"user":{"login":"melloware","id":4399574,"avatar_url":"https://avatars1.githubusercontent.com/u/4399574?v=4","gravatar_id":"","url":"https://api.github.com/users/melloware","html_url":"https://github.com/melloware","followers_url":"https://api.github.com/users/melloware/followers","following_url":"https://api.github.com/users/melloware/following{/other_user}","gists_url":"https://api.github.com/users/melloware/gists{/gist_id}","starred_url":"https://api.github.com/users/melloware/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/melloware/subscriptions","organizations_url":"https://api.github.com/users/melloware/orgs","repos_url":"https://api.github.com/users/melloware/repos","events_url":"https://api.github.com/users/melloware/events{/privacy}","received_events_url":"https://api.github.com/users/melloware/received_events","type":"User","site_admin":false},"created_at":"2018-04-03T11:54:17Z","updated_at":"2018-04-03T11:54:17Z","author_association":"CONTRIBUTOR","body":"It's definitely doable but I have found avoiding PowerMock and PowerMockito should be done at all costs unless using it to test a legacy library that you can't control.\r\n\r\n> If you can avoid it, do; PowerMock is basically only for tests that interact with badly designed code that you can't change. But sometimes you need to depend on a badly designed library, in which case having a somewhat cumbersome way to mock it is better than nothing.\r\n\r\nhttps://news.ycombinator.com/item?id=8775233"}}
{"actor":{"display_login":"melloware"}}