Re: DropDownChoice with a different choice class than model class

[Lon Varscsak]

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  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  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

[Sven Meier]

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