Yeah, I already had a renderer that was taking care of the conversion for me, it’s just I was subclassing DropDownChoice whose generics are only 1 type (both choices and model value). I ended up subclassing AbstractChoice and copying methods (and modifying them to support model values and choices being different) from AbstractSingleSelectChoice, which kind of sucks, but does what I need. :)
-Lon On Thu, Jun 15, 2017 at 12:52 AM, Sven Meier <s...@meiers.net> wrote: > > Hi, > > for Wicket's choice components the model object type (possibly wrapped in a collection) and the type for each choice has to be identical. That is intended. > > >In my case, the model object may be a string, but my choices > >and renderer are rendering from a complex class. > > You have two options: > > - use an 'adapter' model, that adapts the string to your complex class and back > > - let your choices and renderer operate on strings, where the renderer just retrieves your complex objects to do the rendering > > Have fun > Sven > > > > > Am 15.06.2017 um 01:22 schrieb Lon Varscsak: >> >> Am I wrong to assume that DropDownChoice (and a few of it’s superclasses) >> should be using the generic of <T, E> that AbstractChoice defines where T >> is the class of the model object and E is the class of choice object? >> >> It seems that from AbstractSingleSelectChoice up, it assumes that the value >> from the model is the same as the choice. >> >> In my case, the model object may be a string, but my choices and renderer >> are rendering from a complex class. >> >> Thoughts? >> >> -Lon >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org >
