You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@wicket.apache.org by "Fabian T. (JIRA)" <ji...@apache.org> on 2017/06/23 14:36:00 UTC

[jira] [Comment Edited] (WICKET-6410) ChoiceRenderer getObject always calls IModel#getObject when id is null

    [ https://issues.apache.org/jira/browse/WICKET-6410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16060967#comment-16060967 ] 

Fabian T. edited comment on WICKET-6410 at 6/23/17 2:35 PM:
------------------------------------------------------------

Hello Martin,

Thx for your reply.
Indeed id is just null when null values are allowed in the choice. Sorry I forgot to mention this.

Let me try to explain it with the screenshot and some code:

{code:java}
final IModel<List<ABC>> list = new AbstractReadOnlyModel<List<ABC>>() {
	@Override
	public List<ABC> getObject() {
		List<ABC> list = some dao with to much SQL. Just used to fill the dropdown with some initial data.
		return list;
	}
};

final DropDownChoice<ABC> choice = new DropDownChoice<ABC>(some wicket id, someModel.<ABC>bind("abc"), list);
{code}

No magic here. The problem occurs after pressing submit (still no selected element in this dropdown). Please have a look on the screenshot. As you can see it’s just a simple submit, Wicket runs the validators and tries to bind the selected value with the model object. 

On the top, the breakpoint @ VeranstaltungenPage… line 1122: this is the getObject method with the bigger sql.

3 lines deeper in the stacktracke, we are in the ChoiceRenderer class, line 161 (List<? extends T> _choices = choices.getObject();)

Since the user didn’t select anything in the dropdown (id = null), we’re going the leave the ChoiceRenderer# getObject with null anyway. So the call on IModel#getObject isn’t necessary here.

So my question, why do we need to call IModel#getObject of our dropdown? 

Why not just check the id and if it’s null or empty just return null?
if (StringUtils.isBlank(id)) {
	return null;
}

Since I’m not a very experienced wicket dev, I’m maybe missing something somewhere :-)



was (Author: ribosome):
Hello Martin,

Thx for your reply.
Indeed id is just null when null values are allowed in the choice. Sorry I forgot to mention this.

Let me try to explain it with the screenshot and some code:

{code:java}
final IModel<List<ABC>> list = new AbstractReadOnlyModel<List<ABC>>() {
	@Override
	public List<ABC> getObject() {
		List<ABC> list = some dao with to much SQL. Just used to fill the dropdown with some initial data.
		return list;
	}
};

final DropDownChoice<ABC> choice = new DropDownChoice<ABC>(some wicket id, someModel.<ABC>bind("abc"), list);
{code}

No magic here. The problem occurs after pressing submit (still no selected element in this dropdown). Please have a look on the screenshot. As you can see it’s just a simple submit, Wicket runs the validators and tries to bind the selected value with the model object. 

On the top, the breakpoint @ VeranstaltungenPage… line 1122: this is the getObject method with the bigger sql.

3 lines deeper in the stacktracke, we are in the ChoiceRenderer class, line 161 (List<? extends T> _choices = choices.getObject();)

Since the user didn’t select anything in the dropdown (id = null), we’re going the leave the ChoiceRenderer# getObject with null anyway. So the call on IModel#getObject isn’t necessary here.

So my question, why do we need to call IModel#getObject of our dropdown? 

Why not just check the id and if it’s null or empty just return null?
if (StringUtils.isBlank(id)) {
	return null;
}

Since I’m not a very experience wicket dev, I’m maybe missing something somewhere :-)


> ChoiceRenderer getObject always calls IModel#getObject when id is null
> ----------------------------------------------------------------------
>
>                 Key: WICKET-6410
>                 URL: https://issues.apache.org/jira/browse/WICKET-6410
>             Project: Wicket
>          Issue Type: Bug
>          Components: wicket
>    Affects Versions: 7.1.0
>            Reporter: Fabian T.
>            Priority: Trivial
>         Attachments: debug_Screenshot.png
>
>
> {code:java}
> @Override
> 	public T getObject(String id, IModel<? extends List<? extends T>> choices)
> 	{
> 		List<? extends T> _choices = choices.getObject();
> 		for (int index = 0; index < _choices.size(); index++)
> 		{
> 			// Get next choice
> 			final T choice = _choices.get(index);
> 			if (getIdValue(choice, index).equals(id))
> 			{
> 				return choice;
> 			}
> 		}
> 		return null;
> 	}
> }
> {code}
> This Methode always calls „choices.getObject();”, even if the id is null or empty.
> In our project we got some bigger SQL Statements behind some getObject methods of different dropDownChoices. Avoiding to call getObject when the id is null or empty increases the performance.
> Feel free to correct me if I mess up something else with this fix.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)