You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Zbynek Vavros <zb...@gmail.com> on 2019/07/01 12:45:13 UTC
DropDownChoice - choices type vs model type
Hi,
I don't have any specific use-case for this but I'm interested on how to do
this properly.
There is a DropDownChoice that displays list of Batches.
Now the display option should be "id" and "name" concated together and
the DropDownChoice selection model will be only the name.
Batch is simple entity/DTO with Long id and String name, something like:
public class Batch implements Serializable {
private Long id;
private String name;
}
DropDownChoice is added to form that has CompoundPropertyModel for example
like this:
public class ResultDto implement Serializable {
private String batchName;
}
the only solution I can think of is custom IChoiceRenderer but looks nasty
List<Batch> batches = Lists.newArrayList();
List<String> names
=batches.stream().map(Batch::getName).collect(Collectors.toList());
add(new DropDownChoice<>(" batchName ", names, new
IChoiceRenderer<String>() {
@Override
public Object getDisplayValue(String name) {
Batch batch1 = batches.stream().filter(batch ->
name.equalsIgnoreCase(batch.getName())).findFirst().get();
return batch1.getId() + " - " + batch1.getName();
}
@Override
public String getIdValue(String object, int index) {
return String.valueOf(index);
}
@Override
public String getObject(String id, IModel<? extends List<?
extends String>> choices) {
return batches.get(Integer.valueOf(id)).getName()
}
}));
Surely there has to be a better way to do this!
Zbynek
Re: DropDownChoice - choices type vs model type
Posted by Zbynek Vavros <zb...@gmail.com>.
Hey,
well " why not place in the JAXB annotations into the same class" - first
after that the entity ends with gazilion of annotations on every field.
Second, not sure how JAXB helps with stuff like jackson marshalling.
Completely agreeing with dozer!!! :)
Zbynek
On Mon, Jul 1, 2019 at 9:27 PM Tobias Soloschenko
<to...@googlemail.com.invalid> wrote:
> Hi,
>
> just my 5 Cent but I hate conversion methods to transform JPA objects to
> DTO - why not place in the JAXB annotations into the same class - this
> prevents a lot of code and please no DozerBeanMapper ;-)
>
> kind regards
>
> Tobias
>
> > Am 01.07.2019 um 21:19 schrieb Zbynek Vavros <zb...@gmail.com>:
> >
> > I don't want DTO - entity relation, the idea here is to make clear
> > separation of JPA entities and DTOs that can be send over REST/RMI
> > call/serialized.
> >
> > So you don't think there is some "wickety " magic to make this less
> painful?
> > Own class is sure thing, if nothing else than for tests...
> >
> > Zbynek
> >
> >
> >
> >> On Mon, Jul 1, 2019 at 7:22 PM Sven Meier <sv...@meiers.net> wrote:
> >>
> >> Hi,
> >>
> >> preferably your dto would hold a batch instance instead of the name
> only.
> >>
> >> In your case you have to do the mapping somewhere, the renderer is a
> >> good place for that.
> >> Move it into its own class file so it won't hurt so much :P.
> >>
> >> Have fun
> >> Sven
> >>
> >>
> >>> On 01.07.19 14:45, Zbynek Vavros wrote:
> >>> Hi,
> >>>
> >>> I don't have any specific use-case for this but I'm interested on how
> to
> >> do
> >>> this properly.
> >>>
> >>> There is a DropDownChoice that displays list of Batches.
> >>> Now the display option should be "id" and "name" concated together and
> >>> the DropDownChoice selection model will be only the name.
> >>>
> >>> Batch is simple entity/DTO with Long id and String name, something
> like:
> >>>
> >>> public class Batch implements Serializable {
> >>> private Long id;
> >>> private String name;
> >>> }
> >>>
> >>> DropDownChoice is added to form that has CompoundPropertyModel for
> >> example
> >>> like this:
> >>>
> >>> public class ResultDto implement Serializable {
> >>> private String batchName;
> >>> }
> >>>
> >>> the only solution I can think of is custom IChoiceRenderer but looks
> >> nasty
> >>>
> >>> List<Batch> batches = Lists.newArrayList();
> >>> List<String> names
> >>> =batches.stream().map(Batch::getName).collect(Collectors.toList());
> >>>
> >>> add(new DropDownChoice<>(" batchName ", names, new
> >>> IChoiceRenderer<String>() {
> >>> @Override
> >>> public Object getDisplayValue(String name) {
> >>>
> >>> Batch batch1 = batches.stream().filter(batch ->
> >>> name.equalsIgnoreCase(batch.getName())).findFirst().get();
> >>>
> >>> return batch1.getId() + " - " + batch1.getName();
> >>> }
> >>>
> >>> @Override
> >>> public String getIdValue(String object, int index) {
> >>> return String.valueOf(index);
> >>> }
> >>>
> >>> @Override
> >>> public String getObject(String id, IModel<? extends List<?
> >>> extends String>> choices) {
> >>> return batches.get(Integer.valueOf(id)).getName()
> >>> }
> >>> }));
> >>>
> >>> Surely there has to be a better way to do this!
> >>>
> >>> Zbynek
> >>>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: DropDownChoice - choices type vs model type
Posted by Tobias Soloschenko <to...@googlemail.com.INVALID>.
Hi,
just my 5 Cent but I hate conversion methods to transform JPA objects to DTO - why not place in the JAXB annotations into the same class - this prevents a lot of code and please no DozerBeanMapper ;-)
kind regards
Tobias
> Am 01.07.2019 um 21:19 schrieb Zbynek Vavros <zb...@gmail.com>:
>
> I don't want DTO - entity relation, the idea here is to make clear
> separation of JPA entities and DTOs that can be send over REST/RMI
> call/serialized.
>
> So you don't think there is some "wickety " magic to make this less painful?
> Own class is sure thing, if nothing else than for tests...
>
> Zbynek
>
>
>
>> On Mon, Jul 1, 2019 at 7:22 PM Sven Meier <sv...@meiers.net> wrote:
>>
>> Hi,
>>
>> preferably your dto would hold a batch instance instead of the name only.
>>
>> In your case you have to do the mapping somewhere, the renderer is a
>> good place for that.
>> Move it into its own class file so it won't hurt so much :P.
>>
>> Have fun
>> Sven
>>
>>
>>> On 01.07.19 14:45, Zbynek Vavros wrote:
>>> Hi,
>>>
>>> I don't have any specific use-case for this but I'm interested on how to
>> do
>>> this properly.
>>>
>>> There is a DropDownChoice that displays list of Batches.
>>> Now the display option should be "id" and "name" concated together and
>>> the DropDownChoice selection model will be only the name.
>>>
>>> Batch is simple entity/DTO with Long id and String name, something like:
>>>
>>> public class Batch implements Serializable {
>>> private Long id;
>>> private String name;
>>> }
>>>
>>> DropDownChoice is added to form that has CompoundPropertyModel for
>> example
>>> like this:
>>>
>>> public class ResultDto implement Serializable {
>>> private String batchName;
>>> }
>>>
>>> the only solution I can think of is custom IChoiceRenderer but looks
>> nasty
>>>
>>> List<Batch> batches = Lists.newArrayList();
>>> List<String> names
>>> =batches.stream().map(Batch::getName).collect(Collectors.toList());
>>>
>>> add(new DropDownChoice<>(" batchName ", names, new
>>> IChoiceRenderer<String>() {
>>> @Override
>>> public Object getDisplayValue(String name) {
>>>
>>> Batch batch1 = batches.stream().filter(batch ->
>>> name.equalsIgnoreCase(batch.getName())).findFirst().get();
>>>
>>> return batch1.getId() + " - " + batch1.getName();
>>> }
>>>
>>> @Override
>>> public String getIdValue(String object, int index) {
>>> return String.valueOf(index);
>>> }
>>>
>>> @Override
>>> public String getObject(String id, IModel<? extends List<?
>>> extends String>> choices) {
>>> return batches.get(Integer.valueOf(id)).getName()
>>> }
>>> }));
>>>
>>> Surely there has to be a better way to do this!
>>>
>>> Zbynek
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: DropDownChoice - choices type vs model type
Posted by Zbynek Vavros <zb...@gmail.com>.
I don't want DTO - entity relation, the idea here is to make clear
separation of JPA entities and DTOs that can be send over REST/RMI
call/serialized.
So you don't think there is some "wickety " magic to make this less painful?
Own class is sure thing, if nothing else than for tests...
Zbynek
On Mon, Jul 1, 2019 at 7:22 PM Sven Meier <sv...@meiers.net> wrote:
> Hi,
>
> preferably your dto would hold a batch instance instead of the name only.
>
> In your case you have to do the mapping somewhere, the renderer is a
> good place for that.
> Move it into its own class file so it won't hurt so much :P.
>
> Have fun
> Sven
>
>
> On 01.07.19 14:45, Zbynek Vavros wrote:
> > Hi,
> >
> > I don't have any specific use-case for this but I'm interested on how to
> do
> > this properly.
> >
> > There is a DropDownChoice that displays list of Batches.
> > Now the display option should be "id" and "name" concated together and
> > the DropDownChoice selection model will be only the name.
> >
> > Batch is simple entity/DTO with Long id and String name, something like:
> >
> > public class Batch implements Serializable {
> > private Long id;
> > private String name;
> > }
> >
> > DropDownChoice is added to form that has CompoundPropertyModel for
> example
> > like this:
> >
> > public class ResultDto implement Serializable {
> > private String batchName;
> > }
> >
> > the only solution I can think of is custom IChoiceRenderer but looks
> nasty
> >
> > List<Batch> batches = Lists.newArrayList();
> > List<String> names
> > =batches.stream().map(Batch::getName).collect(Collectors.toList());
> >
> > add(new DropDownChoice<>(" batchName ", names, new
> > IChoiceRenderer<String>() {
> > @Override
> > public Object getDisplayValue(String name) {
> >
> > Batch batch1 = batches.stream().filter(batch ->
> > name.equalsIgnoreCase(batch.getName())).findFirst().get();
> >
> > return batch1.getId() + " - " + batch1.getName();
> > }
> >
> > @Override
> > public String getIdValue(String object, int index) {
> > return String.valueOf(index);
> > }
> >
> > @Override
> > public String getObject(String id, IModel<? extends List<?
> > extends String>> choices) {
> > return batches.get(Integer.valueOf(id)).getName()
> > }
> > }));
> >
> > Surely there has to be a better way to do this!
> >
> > Zbynek
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: DropDownChoice - choices type vs model type
Posted by Sven Meier <sv...@meiers.net>.
Hi,
preferably your dto would hold a batch instance instead of the name only.
In your case you have to do the mapping somewhere, the renderer is a
good place for that.
Move it into its own class file so it won't hurt so much :P.
Have fun
Sven
On 01.07.19 14:45, Zbynek Vavros wrote:
> Hi,
>
> I don't have any specific use-case for this but I'm interested on how to do
> this properly.
>
> There is a DropDownChoice that displays list of Batches.
> Now the display option should be "id" and "name" concated together and
> the DropDownChoice selection model will be only the name.
>
> Batch is simple entity/DTO with Long id and String name, something like:
>
> public class Batch implements Serializable {
> private Long id;
> private String name;
> }
>
> DropDownChoice is added to form that has CompoundPropertyModel for example
> like this:
>
> public class ResultDto implement Serializable {
> private String batchName;
> }
>
> the only solution I can think of is custom IChoiceRenderer but looks nasty
>
> List<Batch> batches = Lists.newArrayList();
> List<String> names
> =batches.stream().map(Batch::getName).collect(Collectors.toList());
>
> add(new DropDownChoice<>(" batchName ", names, new
> IChoiceRenderer<String>() {
> @Override
> public Object getDisplayValue(String name) {
>
> Batch batch1 = batches.stream().filter(batch ->
> name.equalsIgnoreCase(batch.getName())).findFirst().get();
>
> return batch1.getId() + " - " + batch1.getName();
> }
>
> @Override
> public String getIdValue(String object, int index) {
> return String.valueOf(index);
> }
>
> @Override
> public String getObject(String id, IModel<? extends List<?
> extends String>> choices) {
> return batches.get(Integer.valueOf(id)).getName()
> }
> }));
>
> Surely there has to be a better way to do this!
>
> Zbynek
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org