Re: DropDownChoice - choices type vs model type
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 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 : > > > > 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 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 batches = Lists.newArrayList(); > >>> List names > >>> =batches.stream().map(Batch::getName).collect(Collectors.toList()); > >>> > >>> add(new DropDownChoice<>(" batchName ", names, new > >>> IChoiceRenderer() { > >>> @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 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-unsubscr...@wicket.apache.org > >> For additional commands, e-mail: users-h...@wicket.apache.org > >> > >> > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
Re: DropDownChoice - choices type vs model type
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 : > > 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 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 batches = Lists.newArrayList(); >>> List names >>> =batches.stream().map(Batch::getName).collect(Collectors.toList()); >>> >>> add(new DropDownChoice<>(" batchName ", names, new >>> IChoiceRenderer() { >>> @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 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-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: DropDownChoice - choices type vs model type
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 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 batches = Lists.newArrayList(); > > List names > > =batches.stream().map(Batch::getName).collect(Collectors.toList()); > > > > add(new DropDownChoice<>(" batchName ", names, new > > IChoiceRenderer() { > > @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 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-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
Re: DropDownChoice - choices type vs model type
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 batches = Lists.newArrayList(); List names =batches.stream().map(Batch::getName).collect(Collectors.toList()); add(new DropDownChoice<>(" batchName ", names, new IChoiceRenderer() { @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> 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-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
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 batches = Lists.newArrayList(); List names =batches.stream().map(Batch::getName).collect(Collectors.toList()); add(new DropDownChoice<>(" batchName ", names, new IChoiceRenderer() { @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> choices) { return batches.get(Integer.valueOf(id)).getName() } })); Surely there has to be a better way to do this! Zbynek