Stateful UrlIdHandler about newpipeextractor

[karyogamy]

I'm not really sure. But looking around the uses for the handler, it seems like the original author intended to inject different handler implementation for each service and type of extraction, which then can be used for processing urls statelessly. Since we now need to keep track of multiple fields at the same time, off the top of my head, we can probably either:

• Retain the stateless nature of the handler and pass around an immutable data class (containing originalUrl, id and cleanUrl) in and out of the handler for processing.
• Or we can inject a UrlIdHandlerFactory at the service level for creating individual handlers, which can be used to store both the data and do processing internally. This way, each factory is stateless and the handlers are immutable.

[theScrabi]

I figured that I destroyed something. I wanted to take a look at it, but I'm still heavily refactoring the SearchEngine aka SearchExtractor.

@karyogamy what would you do to fix this problem. We need to change the way UIHs are used in the fronted. -> get rid of the singletons.

Would it be useful to make UIHs imitable as well?

[theScrabi]

I wrote both types of UrlIdHandler, and I think we need the new implementation of the the statefull once for keeping track of additional sort querris which will be added to the url. So far this was done in the extractors but it does not belong there.

I think having a UrlIdHandlerFactury would be a good idea. So you would override them instead of the UrlIdHandler, and make the handler imitable then.

[FlorianSteenbuck]

When OtherUrl is ready we could create one UrlFactoryProcessor that take a Feature, from OtherFeatures, and a Map<String, ?> of options or/and Object...params for create one unique way to clean Urls. The params could also be mapped on the right method using reflection of the Feature mapped static Class.