draft to show some advantages

[LewerenzM]

Showing some advantage of the generic parameter map

Using generic TreeMap to provide the parameters to each handler was mentioned as a disadvantage in #157. Additionally the loss of the possibility to recognize missing parameters by the compiler were mentioned in the last meeting.
But maybe it is not as problematic as thought and additionally it has some advantages.

This commit is just an outline to think about it, one more time. The code will not compile successfully.

Problems at development runtime, not at productive runtime

The parameters will be extracted from the generic TreeMap at the beginning of each handler. The TreeMap contains ValueContainers. To extract the values the handlers has to call getString() or getBool(), depending of the needed Type.
If the parameter doesn't exists or has another type, a NullPointerException or InternalException will be thrown. See ValueContainer.checkType().

That's why a developer will see while testing, if parameters are missing or maybe have a wrong type. The Developer will fix the problem in development time and the needed parameters will be routed to the handler in the correct way after that. Not the compiler, but this small generic "framework" will show the developer, if there is a problem.

The better way would be having dynamic method parameter lists with different types in Java. Or maybe, like suggested, creating handlers manually with individual parameter lists in their constructors. But if we do that we're also loosing some advantages of the dynamic parameter lists. See next section for details

Pre- and post processing in RequestHandlerService

Currently the RequestHandlerService concerns about determining the type of the given ID (prepared, session, anonymous), managing the different handlers and calling the right handler when a request arrives.

Additionally it could be the right place for pre and post processing like it was outlined in this commit. Especially the dynamic parameter map helps here to create the Transmitter message in a generic way. This reduces a lot of lines of code in each specific handler class (were the Transmitter is called currently). So we could solve the problem with similar code in the the post processing for each handler class very easily, like it is shown in this commit.
Different handlers are writing different parameters to the Transmitter stream (see diagram), and it would not be trivial, to write a common solution for all with a different approach than showed in this commit.

Additionally the pre processing could be managed here. The validateUUID method could be made more common and even the log-call. And later the creation of the DataSelection could be triggered here

Conclusion

Making things generic seems complex at the first sight. But this approach has its own advantages and some of them will may become visible later when new requirements are incoming.

[RKrahl]

Sorry, I'm not convinced. As pointed out in detail in the review for #157, I don't think there is any fancy post- or preprocessing needed in RequestHandlerService.

The transmit() method could be simple helper class. Then, what you call post- or preprocessing here could easily be done by with very few lines of code in IdsService respectively. There, the distinction between the processed and the unprocessed case is know anyway.