Re: DropDownChoice with a different choice class than model class
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 Meierwrote: > > 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 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 >
Re: DropDownChoice with a different choice class than model class
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 ofthat 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
DropDownChoice with a different choice class than model class
Am I wrong to assume that DropDownChoice (and a few of it’s superclasses) should be using the generic ofthat 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