the way this works currently is:
lets say i pick a choice rendered as "17". when we need to resolve this back from the client string to the object we load up all the choices, go through them one by one, render the id using the renderer, and look for the match.
this is ok for most cases, but when you have multiple filters on the page each with 200ish choices this may get slow because not only are you doing a linear search across all options, you are also loading all options from the database or other potentially slow storages.
the idea behind this ticket is to make that reverse lookup ("17"->object) configurable. for large dropdowns a good optimization can be to simply cast "17" to 17 and load the object with that id from the database.
there are two places for this kind of lookup: a method on the component and a method in the renderer.
imho the better place is the renderer because that is the more likely place for specializations to occur and since renderer is the thing that transcodes an object into a string representation it makes it logical that it handles the inverse. for example we have an EntityChoiceRenderer that knows how to pull the database id out of entities; it makes it a logical place to override the lookup. so we would have an EntityChoiceRenderer that knows how to deal with entities in a more complete way: encode them into html and decode them efficiently.
this would change the renderer from an interface into an abstract class, thus wicket 7.0, so it can provide the default linear lookup. maybe
T getObject(String value, IModel<List<T>> choices)
. im not sure if the component instance would be useful in the method signature, my feeling that most likely not really and if its needed the user can pass it in manually.