Re: DropDownChoice - choices type vs model type

[Zbynek Vavros]

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

[Tobias Soloschenko]

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

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

Re: DropDownChoice - choices type vs model type

[Sven Meier]

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

[Zbynek Vavros]

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

Re: receiving email from from p.davids@hea.jetzt when posting on users@wicket.apache.org

[Martin Grigorov]

I've just unsubscribed p.davids@hea.jetzt from both dev@ and users@

On Fri, Jun 21, 2019 at 4:37 PM Sven Meier  wrote:

> Hi,
>
> that's just an automatic reply from Patrick's mailbox.
>
> @Patrick check your subscription please
>
> Have fun
> Sven
>
>
> On 21.06.19 15:01, Francois Meillet wrote:
> > When I send an email to users@wicket.apache.org  users@wicket.apache.org> I receive this automatic email from
> p.davids@hea.jetzt 
> >
> > Guten Tag,
> > die E-Mailadresse des Empfängers hat sich geändert.
> > Gern leiten wir Ihre E-Mail weiter.
> > Bitte ändern Sie für zukünftige Mails die Empfängeradresse von
> @hea.jetzt in @teemer.de.
> >
> > Freundliche Grüße
> > ARZ.dent GmbH
> >
> >
> > In english with Google Translate :
> > the recipient's e-mail address has changed.
> > We are happy to forward your e-mail.
> > Please change the recipient address of @ hea.now to @ teemer.de for
> future mails.
> >
> > Wny do I get this ?
> > Thanks
> >
> >
> > François
> >
> >
> >
> >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>