[jira] Commented: (WICKET-1335) Fixes for "first read" docs in distro
[ https://issues.apache.org/jira/browse/WICKET-1335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12567992#action_12567992 ] Frank Bille Jensen commented on WICKET-1335: I have applied the fixes to the README files. Will look at the quickstart page later today. > Fixes for "first read" docs in distro > - > > Key: WICKET-1335 > URL: https://issues.apache.org/jira/browse/WICKET-1335 > Project: Wicket > Issue Type: Improvement > Components: wicket >Affects Versions: 1.3.0-final >Reporter: Jacek Laskowski >Assignee: Frank Bille Jensen > > After downloaded 1.3 distro begun reading README. Here are a few comments on > it. > 1/ It reads: "The text is included in the file LICENSE.txt in the root of the > project.", but there's no LICENSE.txt, but LICENSE. > 2/ There's more directories than what's listed in "You will find the source > code here". > 3/ s/you want like is outlined/you want as outlined/ > 4/ s/outlined in the quickstart/outlined in the wicket-quickstart/ > 5/ s/use Maven/use Apache Maven (http://maven.apache.org)/ > 6/ s/uploads the source-jars and JavaDoc jars together with the final > jar/uploads the source and JavaDoc jars as well as the final jar/ > 7/ s/your local repository/your maven local repository/ > 8/ s/for use in other projects// > Went on reading apache-wicket\src\archetypes/README: > 1/ s/wicket-archetypes folder/archetypes directory/ > 2/ s/Wicket-archetypes is a collection/Wicket's archetypes directory is a > collection/ > 3/ s/these archetype/these archetypes/ > 4/ README file reads as if there're more archetypes, but there's only one > available. > And finished with http://wicket.apache.org/quickstart.html that warned about > NPE: > Caveats > At present, running mvn package or mvn install will result in a NPE from the > Surefire (testing) plugin as the generated pom.xml has no dependency on > either JUnit or TestNG, > It does no longer applies to Wicket 1.3 as I could run mvn clean install with > no troubles. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
svn commit: r620719 - in /wicket/trunk: README archetypes/README
Author: frankbille Date: Mon Feb 11 23:52:00 2008 New Revision: 620719 URL: http://svn.apache.org/viewvc?rev=620719&view=rev Log: WICKET-1335: README fixes Modified: wicket/trunk/README wicket/trunk/archetypes/README Modified: wicket/trunk/README URL: http://svn.apache.org/viewvc/wicket/trunk/README?rev=620719&r1=620718&r2=620719&view=diff == --- wicket/trunk/README (original) +++ wicket/trunk/README Mon Feb 11 23:52:00 2008 @@ -27,7 +27,7 @@ --- Wicket is distributed under the terms of the Apache Software Foundation -license, version 2.0. The text is included in the file LICENSE.txt in the root +license, version 2.0. The text is included in the file LICENSE in the root of the project. Java/Application server requirements @@ -50,8 +50,10 @@ - wicket - wicket-extensions - wicket-datetime + - wicket-ioc - wicket-spring - wicket-velocity + - wicket-quickstart - src/jdk-1.5 - wicket-examples - wicket-auth-roles @@ -122,7 +124,10 @@ Dependencies -The easiest way of getting the dependencies of your Wicket based projects right is to use Maven with your projects and include the wicket dependencies you want like is outlined in the quickstart. Maven will then take care of including the appropriate dependencies. +The easiest way of getting the dependencies of your Wicket based projects right +is to use Apache Maven (http://maven.apache.org) with your projects and include +the wicket dependencies you want is outlined in the wicket-quickstart. +Maven will then take care of including the appropriate dependencies. If you do not want to use maven, here is a break down of the dependencies you need. @@ -178,8 +183,8 @@ --- The Wicket distribution contains the final Wicket jar. You can use this -directly in your applications. The Wicket project also uploads the source-jars -and JavaDoc jars together with the final jar to the Maven repository used by +directly in your applications. The Wicket project also uploads the source +and JavaDoc jars as well as the final jar to the Maven repository used by the Maven build tool. So there is actually no specific need to build Wicket yourself from the distribution. @@ -192,7 +197,7 @@ - mvn install creates wicket-x.y.z.jar in target/ subdirectory and installs the file -into your local repository for use in other projects. +into your local Maven repository for use in other projects. Migrating from 1.2 -- Modified: wicket/trunk/archetypes/README URL: http://svn.apache.org/viewvc/wicket/trunk/archetypes/README?rev=620719&r1=620718&r2=620719&view=diff == --- wicket/trunk/archetypes/README (original) +++ wicket/trunk/archetypes/README Mon Feb 11 23:52:00 2008 @@ -1,9 +1,10 @@ Apache Wicket Archetypes -This is the readme file for the wicket-archetypes folder +This is the README file for the archetypes directory -Wicket-archetypes is a collection of maven project archetypes designed for wicket. +Wicket's archetypes directory is a collection of Apache Maven project +archetypes designed for Wicket. Contents @@ -13,7 +14,8 @@ Requirements -To install and use these archetype Maven2 needs to be present. +To install and use these archetypes Apache Maven (http://maven.apache.org) +needs to be present. Getting started @@ -52,4 +54,4 @@ >cd myproject >mvn eclipse:eclipse -DdownloadSources=true -Open Eclipse. Choose File/Import/Existing Project and point it to myproject directory \ No newline at end of file +Open Eclipse. Choose File/Import/Existing Project and point it to myproject directory
[jira] Created: (WICKET-1340) Bogus LocalizedImageResource#isStateless()
Bogus LocalizedImageResource#isStateless() -- Key: WICKET-1340 URL: https://issues.apache.org/jira/browse/WICKET-1340 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 1.3.1, 1.3.0-final Reporter: Marat Radchenko Attachments: ImageTest.java Image without resource/resource reference should be stateless. Bug is located in LocalizedImageResource#isStateless(), which should read "return resourceReference == null;" Test case is attached. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-1340) Bogus LocalizedImageResource#isStateless()
[ https://issues.apache.org/jira/browse/WICKET-1340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marat Radchenko updated WICKET-1340: Attachment: ImageTest.java > Bogus LocalizedImageResource#isStateless() > -- > > Key: WICKET-1340 > URL: https://issues.apache.org/jira/browse/WICKET-1340 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.3.0-final, 1.3.1 >Reporter: Marat Radchenko > Attachments: ImageTest.java > > > Image without resource/resource reference should be stateless. > Bug is located in LocalizedImageResource#isStateless(), which should read > "return resourceReference == null;" > Test case is attached. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1337) ListMultipleChoice doesn't work when entries are preselected
[
https://issues.apache.org/jira/browse/WICKET-1337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12567986#action_12567986
]
Thomas Jaeckle commented on WICKET-1337:
Thanks, that really works.
Sorry for the too hasty bug report.
> ListMultipleChoice doesn't work when entries are preselected
>
>
> Key: WICKET-1337
> URL: https://issues.apache.org/jira/browse/WICKET-1337
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.3.1
>Reporter: Thomas Jaeckle
>Assignee: Igor Vaynberg
>
> I tried to preselect all entries in a ListMultipleChoice:
> List priorityList = getPriorityList();
> lmcPriority = new ListMultipleChoice("selectContent", new Model(),
> priorityList);
> lmcPriority.setModelObject(priorityList);
> That works, but when I now start deselecting some items or I select just one
> item, the ListMultipleChoice has the wrong list.
> For the szenarios I did a "System.out.println(getModelObject());" at the end
> of ListMultipleChoice.updateModel()
> ---
> First szenario:
> This is my list of priorities:
> [very high, high, medium, low, very low]
> After I deselect (with Ctrl-Key pressed) "medium" I get:
> [very high, high, low, very low]
> After I deselect "high" I get:
> [very high, very low]
> After I deselect "very high" I get:
> [] (empty List)
> At this time "low" and "very low" are still selected.
> ---
> Second szenario:
> This is my list of priorities:
> [very high, high, medium, low, very low]
> I select only "medium":
> [medium]
> I select only "high":
> [] (empty List)
> I select only "low":
> [] (empty List)
> At this point I can select what I want, but the list never has entries.
> ---
> When I don't preselect all entries, everything works fine.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1331) getModelValue() in AbstractSingleSelectChoice and ListMultipleChoice can't handle complex list items type correctly
[
https://issues.apache.org/jira/browse/WICKET-1331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12567981#action_12567981
]
Sergiy Yevtushenko commented on WICKET-1331:
All of you are right, proposed change is incorrect and equals() is broken. The
need of such a ugly hack may mean that for my purposes I need a version of
DropDownChoice written from scratch, because existing one is inconvenient.
> getModelValue() in AbstractSingleSelectChoice and ListMultipleChoice can't
> handle complex list items type correctly
> ---
>
> Key: WICKET-1331
> URL: https://issues.apache.org/jira/browse/WICKET-1331
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.3.0-final, 1.3.1
> Environment: Suse 10.3, JRE 1.6 (1.6.0_04-b12), jetty 6.1.7
>Reporter: Sergiy Yevtushenko
>Assignee: Igor Vaynberg
> Attachments: testproject.zip
>
> Original Estimate: 0.5h
> Remaining Estimate: 0.5h
>
> AbstractSingleSelectChoice.getModelValue() implementation uses List.indexOf()
> to find the key and this causes problems if list of choices contains complex
> values rather than simple list of String instances. In this case indexOf()
> returns -1 and this can't be resolved by overriding equals() for list
> elements. This happens because internally AbstractList.indexOf() invokes
> equals() method of passed key value passing it list items as a parameter.
> Also, current implementation may pass key returned by getModelObject() to
> IChoiceRender, while it expects values from list of items. Correct
> implementation of this method may look so:
> -
> public String getModelValue()
> {
> // @@ Modified by SIY
> Object object = getModelObject();
> if (object != null)
> {
> // compare choice items with given keys and pass down
> // to IChoiceRenderer list item rather than key
> Iterator iter = getChoices().iterator();
> int i = 0;
> while (iter.hasNext())
> {
> Object obj = iter.next();
> if (obj != null && obj.equals(object))
> {
> object = obj;
> break;
> }
> i++;
> }
> if (i > getChoices().size())
> i = -1;
> return getChoiceRenderer().getIdValue(object, i);
> }
> return NO_SELECTION_VALUE;
> }
> ---
> Similar issues also present in ListMultipleChoice.getModelValue(), but they
> can't be resolved by overriding this method in subclass because this method
> declared final.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-1339) security flow session size continously increase
security flow session size continously increase Key: WICKET-1339 URL: https://issues.apache.org/jira/browse/WICKET-1339 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 1.3.1 Reporter: demir kiracoglu On examples page ( http://www.wicketstuff.org/wicket13/ ) when you open the inspector page and then refresh it, session size continously increase. I know that the models in this page are not loadable-detachable and it is an expected result that page size is large. But doesn't LeastRecentlyAccessedEvictionStrategy have to remove the last accessed pages from the pagemap? I checked the codes and it seems that it does. Is not this a security flow? A simple software making requests to a page like this can utilize all the memory resources. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1331) getModelValue() in AbstractSingleSelectChoice and ListMultipleChoice can't handle complex list items type correctly
[
https://issues.apache.org/jira/browse/WICKET-1331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12567856#action_12567856
]
Matej Knopp commented on WICKET-1331:
-
What you do is just wrong. There is a contract specified on the equals method
and you just violate it.
# public boolean equals(Object obj)
# {
# if (obj instanceof Long)
# return id.equals(obj);
#
Your equals method is not symmetric. I really don't see why we should clutter
wicket code with something like that just because you can't be bothered to
write a proper choice renderer.
> getModelValue() in AbstractSingleSelectChoice and ListMultipleChoice can't
> handle complex list items type correctly
> ---
>
> Key: WICKET-1331
> URL: https://issues.apache.org/jira/browse/WICKET-1331
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.3.0-final, 1.3.1
> Environment: Suse 10.3, JRE 1.6 (1.6.0_04-b12), jetty 6.1.7
>Reporter: Sergiy Yevtushenko
>Assignee: Igor Vaynberg
> Attachments: testproject.zip
>
> Original Estimate: 0.5h
> Remaining Estimate: 0.5h
>
> AbstractSingleSelectChoice.getModelValue() implementation uses List.indexOf()
> to find the key and this causes problems if list of choices contains complex
> values rather than simple list of String instances. In this case indexOf()
> returns -1 and this can't be resolved by overriding equals() for list
> elements. This happens because internally AbstractList.indexOf() invokes
> equals() method of passed key value passing it list items as a parameter.
> Also, current implementation may pass key returned by getModelObject() to
> IChoiceRender, while it expects values from list of items. Correct
> implementation of this method may look so:
> -
> public String getModelValue()
> {
> // @@ Modified by SIY
> Object object = getModelObject();
> if (object != null)
> {
> // compare choice items with given keys and pass down
> // to IChoiceRenderer list item rather than key
> Iterator iter = getChoices().iterator();
> int i = 0;
> while (iter.hasNext())
> {
> Object obj = iter.next();
> if (obj != null && obj.equals(object))
> {
> object = obj;
> break;
> }
> i++;
> }
> if (i > getChoices().size())
> i = -1;
> return getChoiceRenderer().getIdValue(object, i);
> }
> return NO_SELECTION_VALUE;
> }
> ---
> Similar issues also present in ListMultipleChoice.getModelValue(), but they
> can't be resolved by overriding this method in subclass because this method
> declared final.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (WICKET-1331) getModelValue() in AbstractSingleSelectChoice and ListMultipleChoice can't handle complex list items type correctly
[
https://issues.apache.org/jira/browse/WICKET-1331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12567854#action_12567854
]
ivaynberg edited comment on WICKET-1331 at 2/11/08 2:40 PM:
you are using the component in a manner we consider incorrect.
in 1.4 the component will be generified as:
DropDownChoice(String id, IModel model, IModel> choices,
IChoiceRenderer renderer)
how will your change work than??? last time i checked your ChoiceOption doesnt
not extend Long.
anyways, this is the last time i am replying here, as i have mentioned you are
free to start an email thread on our dev list, that is much better for
discussions.
also looking at your code, your implementation of ChoiceOption.equlas() is
horribly broken and would be considered as an ugly hack by any experienced
developer
one of key equals contracts is symmetry. that meas if a.equals(b) is true, then
so is b.equals(a)
in your case choiceoption.equals(long(5)) might be true, but never
5l.equals(choiceoption)
thus your equals implementation is flawed, i urge you to read Object.equals()
javadoc.
was (Author: ivaynberg):
you are using the component in a manner we consider incorrect.
in 1.4 the component will be generified as:
DropDownChoice(String id, IModel model, IModel> choices,
IChoiceRenderer renderer)
how will your change work than??? last time i checked your ChoiceOption doesnt
not extend Long.
anyways, this is the last time i am replying here, as i have mentioned you are
free to start an email thread on our dev list, that is much better for
discussions.
> getModelValue() in AbstractSingleSelectChoice and ListMultipleChoice can't
> handle complex list items type correctly
> ---
>
> Key: WICKET-1331
> URL: https://issues.apache.org/jira/browse/WICKET-1331
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.3.0-final, 1.3.1
> Environment: Suse 10.3, JRE 1.6 (1.6.0_04-b12), jetty 6.1.7
>Reporter: Sergiy Yevtushenko
>Assignee: Igor Vaynberg
> Attachments: testproject.zip
>
> Original Estimate: 0.5h
> Remaining Estimate: 0.5h
>
> AbstractSingleSelectChoice.getModelValue() implementation uses List.indexOf()
> to find the key and this causes problems if list of choices contains complex
> values rather than simple list of String instances. In this case indexOf()
> returns -1 and this can't be resolved by overriding equals() for list
> elements. This happens because internally AbstractList.indexOf() invokes
> equals() method of passed key value passing it list items as a parameter.
> Also, current implementation may pass key returned by getModelObject() to
> IChoiceRender, while it expects values from list of items. Correct
> implementation of this method may look so:
> -
> public String getModelValue()
> {
> // @@ Modified by SIY
> Object object = getModelObject();
> if (object != null)
> {
> // compare choice items with given keys and pass down
> // to IChoiceRenderer list item rather than key
> Iterator iter = getChoices().iterator();
> int i = 0;
> while (iter.hasNext())
> {
> Object obj = iter.next();
> if (obj != null && obj.equals(object))
> {
> object = obj;
> break;
> }
> i++;
> }
> if (i > getChoices().size())
> i = -1;
> return getChoiceRenderer().getIdValue(object, i);
> }
> return NO_SELECTION_VALUE;
> }
> ---
> Similar issues also present in ListMultipleChoice.getModelValue(), but they
> can't be resolved by overriding this method in subclass because this method
> declared final.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1331) getModelValue() in AbstractSingleSelectChoice and ListMultipleChoice can't handle complex list items type correctly
[
https://issues.apache.org/jira/browse/WICKET-1331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12567855#action_12567855
]
Johan Compagner commented on WICKET-1331:
-
this is useless, at the moment we generify everything you will see it moe
clearly. And generics will force you to do it right:
DropDownChoice(String id, IModel model, List choices,
IChoiceRendere renderer)
> getModelValue() in AbstractSingleSelectChoice and ListMultipleChoice can't
> handle complex list items type correctly
> ---
>
> Key: WICKET-1331
> URL: https://issues.apache.org/jira/browse/WICKET-1331
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.3.0-final, 1.3.1
> Environment: Suse 10.3, JRE 1.6 (1.6.0_04-b12), jetty 6.1.7
>Reporter: Sergiy Yevtushenko
>Assignee: Igor Vaynberg
> Attachments: testproject.zip
>
> Original Estimate: 0.5h
> Remaining Estimate: 0.5h
>
> AbstractSingleSelectChoice.getModelValue() implementation uses List.indexOf()
> to find the key and this causes problems if list of choices contains complex
> values rather than simple list of String instances. In this case indexOf()
> returns -1 and this can't be resolved by overriding equals() for list
> elements. This happens because internally AbstractList.indexOf() invokes
> equals() method of passed key value passing it list items as a parameter.
> Also, current implementation may pass key returned by getModelObject() to
> IChoiceRender, while it expects values from list of items. Correct
> implementation of this method may look so:
> -
> public String getModelValue()
> {
> // @@ Modified by SIY
> Object object = getModelObject();
> if (object != null)
> {
> // compare choice items with given keys and pass down
> // to IChoiceRenderer list item rather than key
> Iterator iter = getChoices().iterator();
> int i = 0;
> while (iter.hasNext())
> {
> Object obj = iter.next();
> if (obj != null && obj.equals(object))
> {
> object = obj;
> break;
> }
> i++;
> }
> if (i > getChoices().size())
> i = -1;
> return getChoiceRenderer().getIdValue(object, i);
> }
> return NO_SELECTION_VALUE;
> }
> ---
> Similar issues also present in ListMultipleChoice.getModelValue(), but they
> can't be resolved by overriding this method in subclass because this method
> declared final.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1331) getModelValue() in AbstractSingleSelectChoice and ListMultipleChoice can't handle complex list items type correctly
[
https://issues.apache.org/jira/browse/WICKET-1331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12567854#action_12567854
]
Igor Vaynberg commented on WICKET-1331:
---
you are using the component in a manner we consider incorrect.
in 1.4 the component will be generified as:
DropDownChoice(String id, IModel model, IModel> choices,
IChoiceRenderer renderer)
how will your change work than??? last time i checked your ChoiceOption doesnt
not extend Long.
anyways, this is the last time i am replying here, as i have mentioned you are
free to start an email thread on our dev list, that is much better for
discussions.
> getModelValue() in AbstractSingleSelectChoice and ListMultipleChoice can't
> handle complex list items type correctly
> ---
>
> Key: WICKET-1331
> URL: https://issues.apache.org/jira/browse/WICKET-1331
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.3.0-final, 1.3.1
> Environment: Suse 10.3, JRE 1.6 (1.6.0_04-b12), jetty 6.1.7
>Reporter: Sergiy Yevtushenko
>Assignee: Igor Vaynberg
> Attachments: testproject.zip
>
> Original Estimate: 0.5h
> Remaining Estimate: 0.5h
>
> AbstractSingleSelectChoice.getModelValue() implementation uses List.indexOf()
> to find the key and this causes problems if list of choices contains complex
> values rather than simple list of String instances. In this case indexOf()
> returns -1 and this can't be resolved by overriding equals() for list
> elements. This happens because internally AbstractList.indexOf() invokes
> equals() method of passed key value passing it list items as a parameter.
> Also, current implementation may pass key returned by getModelObject() to
> IChoiceRender, while it expects values from list of items. Correct
> implementation of this method may look so:
> -
> public String getModelValue()
> {
> // @@ Modified by SIY
> Object object = getModelObject();
> if (object != null)
> {
> // compare choice items with given keys and pass down
> // to IChoiceRenderer list item rather than key
> Iterator iter = getChoices().iterator();
> int i = 0;
> while (iter.hasNext())
> {
> Object obj = iter.next();
> if (obj != null && obj.equals(object))
> {
> object = obj;
> break;
> }
> i++;
> }
> if (i > getChoices().size())
> i = -1;
> return getChoiceRenderer().getIdValue(object, i);
> }
> return NO_SELECTION_VALUE;
> }
> ---
> Similar issues also present in ListMultipleChoice.getModelValue(), but they
> can't be resolved by overriding this method in subclass because this method
> declared final.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1331) getModelValue() in AbstractSingleSelectChoice and ListMultipleChoice can't handle complex list items type correctly
[
https://issues.apache.org/jira/browse/WICKET-1331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12567842#action_12567842
]
Sergiy Yevtushenko commented on WICKET-1331:
Initially I did as you suggesting - subclassed DropDownChoice. But then I hit
similar issue in ListMultipleChoice and found that getModelValue() is final
there. At present I'm ought to maintain local copy of Wicket sources.
And, actually, I'm not completely understand why you don't like proposed
change. It provides more flexibility and functionality for free, without
affecting existing applications or performance penalties.
> getModelValue() in AbstractSingleSelectChoice and ListMultipleChoice can't
> handle complex list items type correctly
> ---
>
> Key: WICKET-1331
> URL: https://issues.apache.org/jira/browse/WICKET-1331
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.3.0-final, 1.3.1
> Environment: Suse 10.3, JRE 1.6 (1.6.0_04-b12), jetty 6.1.7
>Reporter: Sergiy Yevtushenko
>Assignee: Igor Vaynberg
> Attachments: testproject.zip
>
> Original Estimate: 0.5h
> Remaining Estimate: 0.5h
>
> AbstractSingleSelectChoice.getModelValue() implementation uses List.indexOf()
> to find the key and this causes problems if list of choices contains complex
> values rather than simple list of String instances. In this case indexOf()
> returns -1 and this can't be resolved by overriding equals() for list
> elements. This happens because internally AbstractList.indexOf() invokes
> equals() method of passed key value passing it list items as a parameter.
> Also, current implementation may pass key returned by getModelObject() to
> IChoiceRender, while it expects values from list of items. Correct
> implementation of this method may look so:
> -
> public String getModelValue()
> {
> // @@ Modified by SIY
> Object object = getModelObject();
> if (object != null)
> {
> // compare choice items with given keys and pass down
> // to IChoiceRenderer list item rather than key
> Iterator iter = getChoices().iterator();
> int i = 0;
> while (iter.hasNext())
> {
> Object obj = iter.next();
> if (obj != null && obj.equals(object))
> {
> object = obj;
> break;
> }
> i++;
> }
> if (i > getChoices().size())
> i = -1;
> return getChoiceRenderer().getIdValue(object, i);
> }
> return NO_SELECTION_VALUE;
> }
> ---
> Similar issues also present in ListMultipleChoice.getModelValue(), but they
> can't be resolved by overriding this method in subclass because this method
> declared final.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1331) getModelValue() in AbstractSingleSelectChoice and ListMultipleChoice can't handle complex list items type correctly
[
https://issues.apache.org/jira/browse/WICKET-1331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12567834#action_12567834
]
Igor Vaynberg commented on WICKET-1331:
---
well, that is your opinion. my opinion is that the rendering of human-readable
values should be in the renderer. getmodelvalue() is not final, so you can
create your own subclasses that work the way you want - this is the power of
wicket. of course if you feel like your way is much better feel free to start a
thread on the dev list.
> getModelValue() in AbstractSingleSelectChoice and ListMultipleChoice can't
> handle complex list items type correctly
> ---
>
> Key: WICKET-1331
> URL: https://issues.apache.org/jira/browse/WICKET-1331
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.3.0-final, 1.3.1
> Environment: Suse 10.3, JRE 1.6 (1.6.0_04-b12), jetty 6.1.7
>Reporter: Sergiy Yevtushenko
>Assignee: Igor Vaynberg
> Attachments: testproject.zip
>
> Original Estimate: 0.5h
> Remaining Estimate: 0.5h
>
> AbstractSingleSelectChoice.getModelValue() implementation uses List.indexOf()
> to find the key and this causes problems if list of choices contains complex
> values rather than simple list of String instances. In this case indexOf()
> returns -1 and this can't be resolved by overriding equals() for list
> elements. This happens because internally AbstractList.indexOf() invokes
> equals() method of passed key value passing it list items as a parameter.
> Also, current implementation may pass key returned by getModelObject() to
> IChoiceRender, while it expects values from list of items. Correct
> implementation of this method may look so:
> -
> public String getModelValue()
> {
> // @@ Modified by SIY
> Object object = getModelObject();
> if (object != null)
> {
> // compare choice items with given keys and pass down
> // to IChoiceRenderer list item rather than key
> Iterator iter = getChoices().iterator();
> int i = 0;
> while (iter.hasNext())
> {
> Object obj = iter.next();
> if (obj != null && obj.equals(object))
> {
> object = obj;
> break;
> }
> i++;
> }
> if (i > getChoices().size())
> i = -1;
> return getChoiceRenderer().getIdValue(object, i);
> }
> return NO_SELECTION_VALUE;
> }
> ---
> Similar issues also present in ListMultipleChoice.getModelValue(), but they
> can't be resolved by overriding this method in subclass because this method
> declared final.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1331) getModelValue() in AbstractSingleSelectChoice and ListMultipleChoice can't handle complex list items type correctly
[
https://issues.apache.org/jira/browse/WICKET-1331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12567814#action_12567814
]
Sergiy Yevtushenko commented on WICKET-1331:
I'm in situation when model object contains values convenient for processing
and storing, while user should see more verbose, human readable choice items.
Also, I'm about to implement another similar case - model object contains
numbers from predefined set of non-sequential values while for user they are
presented as descriptive text strings. In all these situations it is convenient
to let DropDownChoice maintain and automatically handle conversion, especially
if to take into account that it already support almost all necessary
functionality. At present this will require custom ChoiceRenderer for each such
property, while it can be done is one piece of generic code.
> getModelValue() in AbstractSingleSelectChoice and ListMultipleChoice can't
> handle complex list items type correctly
> ---
>
> Key: WICKET-1331
> URL: https://issues.apache.org/jira/browse/WICKET-1331
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.3.0-final, 1.3.1
> Environment: Suse 10.3, JRE 1.6 (1.6.0_04-b12), jetty 6.1.7
>Reporter: Sergiy Yevtushenko
>Assignee: Igor Vaynberg
> Attachments: testproject.zip
>
> Original Estimate: 0.5h
> Remaining Estimate: 0.5h
>
> AbstractSingleSelectChoice.getModelValue() implementation uses List.indexOf()
> to find the key and this causes problems if list of choices contains complex
> values rather than simple list of String instances. In this case indexOf()
> returns -1 and this can't be resolved by overriding equals() for list
> elements. This happens because internally AbstractList.indexOf() invokes
> equals() method of passed key value passing it list items as a parameter.
> Also, current implementation may pass key returned by getModelObject() to
> IChoiceRender, while it expects values from list of items. Correct
> implementation of this method may look so:
> -
> public String getModelValue()
> {
> // @@ Modified by SIY
> Object object = getModelObject();
> if (object != null)
> {
> // compare choice items with given keys and pass down
> // to IChoiceRenderer list item rather than key
> Iterator iter = getChoices().iterator();
> int i = 0;
> while (iter.hasNext())
> {
> Object obj = iter.next();
> if (obj != null && obj.equals(object))
> {
> object = obj;
> break;
> }
> i++;
> }
> if (i > getChoices().size())
> i = -1;
> return getChoiceRenderer().getIdValue(object, i);
> }
> return NO_SELECTION_VALUE;
> }
> ---
> Similar issues also present in ListMultipleChoice.getModelValue(), but they
> can't be resolved by overriding this method in subclass because this method
> declared final.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1331) getModelValue() in AbstractSingleSelectChoice and ListMultipleChoice can't handle complex list items type correctly
[
https://issues.apache.org/jira/browse/WICKET-1331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12567791#action_12567791
]
Igor Vaynberg commented on WICKET-1331:
---
once again, you are using the dropdown choice incorrectly
your model object is of type Long, while your choice objects are ChoiceOption.
dropdown choice expects the collection of choices and the model object be of
the same type!
if you are in this situation - where your collection is a list of primitives,
then you should convert it to a user-facing string inside choicerenderer.
> getModelValue() in AbstractSingleSelectChoice and ListMultipleChoice can't
> handle complex list items type correctly
> ---
>
> Key: WICKET-1331
> URL: https://issues.apache.org/jira/browse/WICKET-1331
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.3.0-final, 1.3.1
> Environment: Suse 10.3, JRE 1.6 (1.6.0_04-b12), jetty 6.1.7
>Reporter: Sergiy Yevtushenko
>Assignee: Igor Vaynberg
> Attachments: testproject.zip
>
> Original Estimate: 0.5h
> Remaining Estimate: 0.5h
>
> AbstractSingleSelectChoice.getModelValue() implementation uses List.indexOf()
> to find the key and this causes problems if list of choices contains complex
> values rather than simple list of String instances. In this case indexOf()
> returns -1 and this can't be resolved by overriding equals() for list
> elements. This happens because internally AbstractList.indexOf() invokes
> equals() method of passed key value passing it list items as a parameter.
> Also, current implementation may pass key returned by getModelObject() to
> IChoiceRender, while it expects values from list of items. Correct
> implementation of this method may look so:
> -
> public String getModelValue()
> {
> // @@ Modified by SIY
> Object object = getModelObject();
> if (object != null)
> {
> // compare choice items with given keys and pass down
> // to IChoiceRenderer list item rather than key
> Iterator iter = getChoices().iterator();
> int i = 0;
> while (iter.hasNext())
> {
> Object obj = iter.next();
> if (obj != null && obj.equals(object))
> {
> object = obj;
> break;
> }
> i++;
> }
> if (i > getChoices().size())
> i = -1;
> return getChoiceRenderer().getIdValue(object, i);
> }
> return NO_SELECTION_VALUE;
> }
> ---
> Similar issues also present in ListMultipleChoice.getModelValue(), but they
> can't be resolved by overriding this method in subclass because this method
> declared final.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (WICKET-1338) enclosures on nested components within wicket:extends
[ https://issues.apache.org/jira/browse/WICKET-1338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Vaynberg reassigned WICKET-1338: - Assignee: Juergen Donnerstag > enclosures on nested components within wicket:extends > - > > Key: WICKET-1338 > URL: https://issues.apache.org/jira/browse/WICKET-1338 > Project: Wicket > Issue Type: Improvement > Components: wicket >Affects Versions: 1.3.0-final, 1.3.1 >Reporter: Michael Sparer >Assignee: Juergen Donnerstag >Priority: Minor > Attachments: enclosures.jar > > > Since 1.3.0-final the "hidden feature" of addressing components within an > enclosure by writing the path into the child attribute (e.g. > child="container:list") is not supported anymore if they occur within > wicket:extend tags. For further information, take a look at the mailinglist: > http://www.nabble.com/enclosures-on-nested-components-within-wicket%3Aextends-to15330837.html#a15330837 > > and/or at the attached quickstart -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1331) getModelValue() in AbstractSingleSelectChoice and ListMultipleChoice can't handle complex list items type correctly
[
https://issues.apache.org/jira/browse/WICKET-1331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12567787#action_12567787
]
Sergiy Yevtushenko commented on WICKET-1331:
As you may notice in test application, choice list contains complex items.
Also, updated getDisplayValue() works properly in this case, although
everything else remains unchanged. Just try step through both versions of
getDisplayValue() in debugger and compare values passed to choice renderer.
> getModelValue() in AbstractSingleSelectChoice and ListMultipleChoice can't
> handle complex list items type correctly
> ---
>
> Key: WICKET-1331
> URL: https://issues.apache.org/jira/browse/WICKET-1331
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.3.0-final, 1.3.1
> Environment: Suse 10.3, JRE 1.6 (1.6.0_04-b12), jetty 6.1.7
>Reporter: Sergiy Yevtushenko
>Assignee: Igor Vaynberg
> Attachments: testproject.zip
>
> Original Estimate: 0.5h
> Remaining Estimate: 0.5h
>
> AbstractSingleSelectChoice.getModelValue() implementation uses List.indexOf()
> to find the key and this causes problems if list of choices contains complex
> values rather than simple list of String instances. In this case indexOf()
> returns -1 and this can't be resolved by overriding equals() for list
> elements. This happens because internally AbstractList.indexOf() invokes
> equals() method of passed key value passing it list items as a parameter.
> Also, current implementation may pass key returned by getModelObject() to
> IChoiceRender, while it expects values from list of items. Correct
> implementation of this method may look so:
> -
> public String getModelValue()
> {
> // @@ Modified by SIY
> Object object = getModelObject();
> if (object != null)
> {
> // compare choice items with given keys and pass down
> // to IChoiceRenderer list item rather than key
> Iterator iter = getChoices().iterator();
> int i = 0;
> while (iter.hasNext())
> {
> Object obj = iter.next();
> if (obj != null && obj.equals(object))
> {
> object = obj;
> break;
> }
> i++;
> }
> if (i > getChoices().size())
> i = -1;
> return getChoiceRenderer().getIdValue(object, i);
> }
> return NO_SELECTION_VALUE;
> }
> ---
> Similar issues also present in ListMultipleChoice.getModelValue(), but they
> can't be resolved by overriding this method in subclass because this method
> declared final.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1331) getModelValue() in AbstractSingleSelectChoice and ListMultipleChoice can't handle complex list items type correctly
[
https://issues.apache.org/jira/browse/WICKET-1331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1256#action_1256
]
Igor Vaynberg commented on WICKET-1331:
---
but (1) is programmer error...you shouldnt use that choice renderer
implementation with primitives!
> getModelValue() in AbstractSingleSelectChoice and ListMultipleChoice can't
> handle complex list items type correctly
> ---
>
> Key: WICKET-1331
> URL: https://issues.apache.org/jira/browse/WICKET-1331
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.3.0-final, 1.3.1
> Environment: Suse 10.3, JRE 1.6 (1.6.0_04-b12), jetty 6.1.7
>Reporter: Sergiy Yevtushenko
>Assignee: Igor Vaynberg
> Attachments: testproject.zip
>
> Original Estimate: 0.5h
> Remaining Estimate: 0.5h
>
> AbstractSingleSelectChoice.getModelValue() implementation uses List.indexOf()
> to find the key and this causes problems if list of choices contains complex
> values rather than simple list of String instances. In this case indexOf()
> returns -1 and this can't be resolved by overriding equals() for list
> elements. This happens because internally AbstractList.indexOf() invokes
> equals() method of passed key value passing it list items as a parameter.
> Also, current implementation may pass key returned by getModelObject() to
> IChoiceRender, while it expects values from list of items. Correct
> implementation of this method may look so:
> -
> public String getModelValue()
> {
> // @@ Modified by SIY
> Object object = getModelObject();
> if (object != null)
> {
> // compare choice items with given keys and pass down
> // to IChoiceRenderer list item rather than key
> Iterator iter = getChoices().iterator();
> int i = 0;
> while (iter.hasNext())
> {
> Object obj = iter.next();
> if (obj != null && obj.equals(object))
> {
> object = obj;
> break;
> }
> i++;
> }
> if (i > getChoices().size())
> i = -1;
> return getChoiceRenderer().getIdValue(object, i);
> }
> return NO_SELECTION_VALUE;
> }
> ---
> Similar issues also present in ListMultipleChoice.getModelValue(), but they
> can't be resolved by overriding this method in subclass because this method
> declared final.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-1338) enclosures on nested components within wicket:extends
[ https://issues.apache.org/jira/browse/WICKET-1338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Sparer updated WICKET-1338: --- Attachment: enclosures.jar > enclosures on nested components within wicket:extends > - > > Key: WICKET-1338 > URL: https://issues.apache.org/jira/browse/WICKET-1338 > Project: Wicket > Issue Type: Improvement > Components: wicket >Affects Versions: 1.3.0-final, 1.3.1 >Reporter: Michael Sparer >Priority: Minor > Attachments: enclosures.jar > > > Since 1.3.0-final the "hidden feature" of addressing components within an > enclosure by writing the path into the child attribute (e.g. > child="container:list") is not supported anymore if they occur within > wicket:extend tags. For further information, take a look at the mailinglist: > http://www.nabble.com/enclosures-on-nested-components-within-wicket%3Aextends-to15330837.html#a15330837 > > and/or at the attached quickstart -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-1338) enclosures on nested components within wicket:extends
enclosures on nested components within wicket:extends - Key: WICKET-1338 URL: https://issues.apache.org/jira/browse/WICKET-1338 Project: Wicket Issue Type: Improvement Components: wicket Affects Versions: 1.3.1, 1.3.0-final Reporter: Michael Sparer Priority: Minor Attachments: enclosures.jar Since 1.3.0-final the "hidden feature" of addressing components within an enclosure by writing the path into the child attribute (e.g. child="container:list") is not supported anymore if they occur within wicket:extend tags. For further information, take a look at the mailinglist: http://www.nabble.com/enclosures-on-nested-components-within-wicket%3Aextends-to15330837.html#a15330837 and/or at the attached quickstart -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (WICKET-1331) getModelValue() in AbstractSingleSelectChoice and ListMultipleChoice can't handle complex list items type correctly
[
https://issues.apache.org/jira/browse/WICKET-1331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12567757#action_12567757
]
evsi edited comment on WICKET-1331 at 2/11/08 11:04 AM:
--
Sorry, I haven't mentioned it, but attached example does show both these
issues:
1) causes a trap "No get method defined for class: class java.lang.Long
expression: id" cited above (because ChoiceRenderer tries to resolve property
name for simple type)
2) can be seen if replace ChoiceRenderer with custom one (as you have
suggested) or just by stepping through getDisplayValue() in debugger - value
taken from model does not match any choice item (the List indexOf() is
responsible for this, as I've mentioned). Also, with updated getModelValue()
this issue disappears, so this is not a programmer error.
was (Author: evsi):
Sorry, I haven't mentioned it, but attached example does show both these
issues:
1) causes a trap "No get method defined for class: class java.lang.Long
expression: id" cited above (because ChoiceRenderer tries to resolve property
name for simple type)
2) can be seen if replace ChoiceRenderer with custom one (as you have
suggested) or just by stepping through getDisplayValue() in debugger - value
taken from model does not match any choice item (the List indexOf() is
responsible for this, as I've mentioned).
> getModelValue() in AbstractSingleSelectChoice and ListMultipleChoice can't
> handle complex list items type correctly
> ---
>
> Key: WICKET-1331
> URL: https://issues.apache.org/jira/browse/WICKET-1331
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.3.0-final, 1.3.1
> Environment: Suse 10.3, JRE 1.6 (1.6.0_04-b12), jetty 6.1.7
>Reporter: Sergiy Yevtushenko
>Assignee: Igor Vaynberg
> Attachments: testproject.zip
>
> Original Estimate: 0.5h
> Remaining Estimate: 0.5h
>
> AbstractSingleSelectChoice.getModelValue() implementation uses List.indexOf()
> to find the key and this causes problems if list of choices contains complex
> values rather than simple list of String instances. In this case indexOf()
> returns -1 and this can't be resolved by overriding equals() for list
> elements. This happens because internally AbstractList.indexOf() invokes
> equals() method of passed key value passing it list items as a parameter.
> Also, current implementation may pass key returned by getModelObject() to
> IChoiceRender, while it expects values from list of items. Correct
> implementation of this method may look so:
> -
> public String getModelValue()
> {
> // @@ Modified by SIY
> Object object = getModelObject();
> if (object != null)
> {
> // compare choice items with given keys and pass down
> // to IChoiceRenderer list item rather than key
> Iterator iter = getChoices().iterator();
> int i = 0;
> while (iter.hasNext())
> {
> Object obj = iter.next();
> if (obj != null && obj.equals(object))
> {
> object = obj;
> break;
> }
> i++;
> }
> if (i > getChoices().size())
> i = -1;
> return getChoiceRenderer().getIdValue(object, i);
> }
> return NO_SELECTION_VALUE;
> }
> ---
> Similar issues also present in ListMultipleChoice.getModelValue(), but they
> can't be resolved by overriding this method in subclass because this method
> declared final.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1331) getModelValue() in AbstractSingleSelectChoice and ListMultipleChoice can't handle complex list items type correctly
[
https://issues.apache.org/jira/browse/WICKET-1331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12567757#action_12567757
]
Sergiy Yevtushenko commented on WICKET-1331:
Sorry, I haven't mentioned it, but attached example does show both these
issues:
1) causes a trap "No get method defined for class: class java.lang.Long
expression: id" cited above (because ChoiceRenderer tries to resolve property
name for simple type)
2) can be seen if replace ChoiceRenderer with custom one (as you have
suggested) or just by stepping through getDisplayValue() in debugger - value
taken from model does not match any choice item (the List indexOf() is
responsible for this, as I've mentioned).
> getModelValue() in AbstractSingleSelectChoice and ListMultipleChoice can't
> handle complex list items type correctly
> ---
>
> Key: WICKET-1331
> URL: https://issues.apache.org/jira/browse/WICKET-1331
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.3.0-final, 1.3.1
> Environment: Suse 10.3, JRE 1.6 (1.6.0_04-b12), jetty 6.1.7
>Reporter: Sergiy Yevtushenko
>Assignee: Igor Vaynberg
> Attachments: testproject.zip
>
> Original Estimate: 0.5h
> Remaining Estimate: 0.5h
>
> AbstractSingleSelectChoice.getModelValue() implementation uses List.indexOf()
> to find the key and this causes problems if list of choices contains complex
> values rather than simple list of String instances. In this case indexOf()
> returns -1 and this can't be resolved by overriding equals() for list
> elements. This happens because internally AbstractList.indexOf() invokes
> equals() method of passed key value passing it list items as a parameter.
> Also, current implementation may pass key returned by getModelObject() to
> IChoiceRender, while it expects values from list of items. Correct
> implementation of this method may look so:
> -
> public String getModelValue()
> {
> // @@ Modified by SIY
> Object object = getModelObject();
> if (object != null)
> {
> // compare choice items with given keys and pass down
> // to IChoiceRenderer list item rather than key
> Iterator iter = getChoices().iterator();
> int i = 0;
> while (iter.hasNext())
> {
> Object obj = iter.next();
> if (obj != null && obj.equals(object))
> {
> object = obj;
> break;
> }
> i++;
> }
> if (i > getChoices().size())
> i = -1;
> return getChoiceRenderer().getIdValue(object, i);
> }
> return NO_SELECTION_VALUE;
> }
> ---
> Similar issues also present in ListMultipleChoice.getModelValue(), but they
> can't be resolved by overriding this method in subclass because this method
> declared final.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (WICKET-1337) ListMultipleChoice doesn't work when entries are preselected
[
https://issues.apache.org/jira/browse/WICKET-1337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Vaynberg resolved WICKET-1337.
---
Resolution: Invalid
Assignee: Igor Vaynberg
its because the list of available choices and the collection used to store the
selection are the same.
instead of lmcPriority.setModelObject(priorityList); try
lmcpriority.setmodelobject(new arraylist(prioritylist));
> ListMultipleChoice doesn't work when entries are preselected
>
>
> Key: WICKET-1337
> URL: https://issues.apache.org/jira/browse/WICKET-1337
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.3.1
>Reporter: Thomas Jaeckle
>Assignee: Igor Vaynberg
>
> I tried to preselect all entries in a ListMultipleChoice:
> List priorityList = getPriorityList();
> lmcPriority = new ListMultipleChoice("selectContent", new Model(),
> priorityList);
> lmcPriority.setModelObject(priorityList);
> That works, but when I now start deselecting some items or I select just one
> item, the ListMultipleChoice has the wrong list.
> For the szenarios I did a "System.out.println(getModelObject());" at the end
> of ListMultipleChoice.updateModel()
> ---
> First szenario:
> This is my list of priorities:
> [very high, high, medium, low, very low]
> After I deselect (with Ctrl-Key pressed) "medium" I get:
> [very high, high, low, very low]
> After I deselect "high" I get:
> [very high, very low]
> After I deselect "very high" I get:
> [] (empty List)
> At this time "low" and "very low" are still selected.
> ---
> Second szenario:
> This is my list of priorities:
> [very high, high, medium, low, very low]
> I select only "medium":
> [medium]
> I select only "high":
> [] (empty List)
> I select only "low":
> [] (empty List)
> At this point I can select what I want, but the list never has entries.
> ---
> When I don't preselect all entries, everything works fine.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1331) getModelValue() in AbstractSingleSelectChoice and ListMultipleChoice can't handle complex list items type correctly
[
https://issues.apache.org/jira/browse/WICKET-1331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12567735#action_12567735
]
Igor Vaynberg commented on WICKET-1331:
---
well, i would like to see the code snippet that demonstrates (1) and (2).
in fact (2) sounds like a programmer error
> getModelValue() in AbstractSingleSelectChoice and ListMultipleChoice can't
> handle complex list items type correctly
> ---
>
> Key: WICKET-1331
> URL: https://issues.apache.org/jira/browse/WICKET-1331
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.3.0-final, 1.3.1
> Environment: Suse 10.3, JRE 1.6 (1.6.0_04-b12), jetty 6.1.7
>Reporter: Sergiy Yevtushenko
>Assignee: Igor Vaynberg
> Attachments: testproject.zip
>
> Original Estimate: 0.5h
> Remaining Estimate: 0.5h
>
> AbstractSingleSelectChoice.getModelValue() implementation uses List.indexOf()
> to find the key and this causes problems if list of choices contains complex
> values rather than simple list of String instances. In this case indexOf()
> returns -1 and this can't be resolved by overriding equals() for list
> elements. This happens because internally AbstractList.indexOf() invokes
> equals() method of passed key value passing it list items as a parameter.
> Also, current implementation may pass key returned by getModelObject() to
> IChoiceRender, while it expects values from list of items. Correct
> implementation of this method may look so:
> -
> public String getModelValue()
> {
> // @@ Modified by SIY
> Object object = getModelObject();
> if (object != null)
> {
> // compare choice items with given keys and pass down
> // to IChoiceRenderer list item rather than key
> Iterator iter = getChoices().iterator();
> int i = 0;
> while (iter.hasNext())
> {
> Object obj = iter.next();
> if (obj != null && obj.equals(object))
> {
> object = obj;
> break;
> }
> i++;
> }
> if (i > getChoices().size())
> i = -1;
> return getChoiceRenderer().getIdValue(object, i);
> }
> return NO_SELECTION_VALUE;
> }
> ---
> Similar issues also present in ListMultipleChoice.getModelValue(), but they
> can't be resolved by overriding this method in subclass because this method
> declared final.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1331) getModelValue() in AbstractSingleSelectChoice and ListMultipleChoice can't handle complex list items type correctly
[
https://issues.apache.org/jira/browse/WICKET-1331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12567729#action_12567729
]
Sergiy Yevtushenko commented on WICKET-1331:
Initially I met the same issue with POJO which has two string members and
symptoms were the same - attempt to resolve property for simple type (that time
is was String). Also, I've tried to replace ChoiceRenderer with custom one.
This approach resolves a trap, but does not resolve two other issues:
1. under some circumstances IChoiceRenderer.getDisplayValue() can be invoked
with key (field model value) rather than choice list item (this happens when
key can't be found in choice list).
2. Initial value set incorrectly (for the same reason - selected item can't be
determined).
Proposed version of getModelValue() resolves these issue if choice list item
has proper equals() method.
> getModelValue() in AbstractSingleSelectChoice and ListMultipleChoice can't
> handle complex list items type correctly
> ---
>
> Key: WICKET-1331
> URL: https://issues.apache.org/jira/browse/WICKET-1331
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.3.0-final, 1.3.1
> Environment: Suse 10.3, JRE 1.6 (1.6.0_04-b12), jetty 6.1.7
>Reporter: Sergiy Yevtushenko
>Assignee: Igor Vaynberg
> Attachments: testproject.zip
>
> Original Estimate: 0.5h
> Remaining Estimate: 0.5h
>
> AbstractSingleSelectChoice.getModelValue() implementation uses List.indexOf()
> to find the key and this causes problems if list of choices contains complex
> values rather than simple list of String instances. In this case indexOf()
> returns -1 and this can't be resolved by overriding equals() for list
> elements. This happens because internally AbstractList.indexOf() invokes
> equals() method of passed key value passing it list items as a parameter.
> Also, current implementation may pass key returned by getModelObject() to
> IChoiceRender, while it expects values from list of items. Correct
> implementation of this method may look so:
> -
> public String getModelValue()
> {
> // @@ Modified by SIY
> Object object = getModelObject();
> if (object != null)
> {
> // compare choice items with given keys and pass down
> // to IChoiceRenderer list item rather than key
> Iterator iter = getChoices().iterator();
> int i = 0;
> while (iter.hasNext())
> {
> Object obj = iter.next();
> if (obj != null && obj.equals(object))
> {
> object = obj;
> break;
> }
> i++;
> }
> if (i > getChoices().size())
> i = -1;
> return getChoiceRenderer().getIdValue(object, i);
> }
> return NO_SELECTION_VALUE;
> }
> ---
> Similar issues also present in ListMultipleChoice.getModelValue(), but they
> can't be resolved by overriding this method in subclass because this method
> declared final.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (WICKET-1331) getModelValue() in AbstractSingleSelectChoice and ListMultipleChoice can't handle complex list items type correctly
[
https://issues.apache.org/jira/browse/WICKET-1331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12567729#action_12567729
]
evsi edited comment on WICKET-1331 at 2/11/08 10:03 AM:
--
Initially I met the same issue with POJO which had two string members and
symptoms were the same - attempt to resolve property for simple type (that time
is was String). Also, I've tried to replace ChoiceRenderer with custom one.
This approach resolves a trap, but does not resolve two other issues:
1. under some circumstances IChoiceRenderer.getDisplayValue() can be invoked
with key (field model value) rather than choice list item (this happens when
key can't be found in choice list).
2. Initial value set incorrectly (for the same reason - selected item can't be
determined).
Proposed version of getModelValue() resolves these issue if choice list item
has proper equals() method.
was (Author: evsi):
Initially I met the same issue with POJO which has two string members and
symptoms were the same - attempt to resolve property for simple type (that time
is was String). Also, I've tried to replace ChoiceRenderer with custom one.
This approach resolves a trap, but does not resolve two other issues:
1. under some circumstances IChoiceRenderer.getDisplayValue() can be invoked
with key (field model value) rather than choice list item (this happens when
key can't be found in choice list).
2. Initial value set incorrectly (for the same reason - selected item can't be
determined).
Proposed version of getModelValue() resolves these issue if choice list item
has proper equals() method.
> getModelValue() in AbstractSingleSelectChoice and ListMultipleChoice can't
> handle complex list items type correctly
> ---
>
> Key: WICKET-1331
> URL: https://issues.apache.org/jira/browse/WICKET-1331
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.3.0-final, 1.3.1
> Environment: Suse 10.3, JRE 1.6 (1.6.0_04-b12), jetty 6.1.7
>Reporter: Sergiy Yevtushenko
>Assignee: Igor Vaynberg
> Attachments: testproject.zip
>
> Original Estimate: 0.5h
> Remaining Estimate: 0.5h
>
> AbstractSingleSelectChoice.getModelValue() implementation uses List.indexOf()
> to find the key and this causes problems if list of choices contains complex
> values rather than simple list of String instances. In this case indexOf()
> returns -1 and this can't be resolved by overriding equals() for list
> elements. This happens because internally AbstractList.indexOf() invokes
> equals() method of passed key value passing it list items as a parameter.
> Also, current implementation may pass key returned by getModelObject() to
> IChoiceRender, while it expects values from list of items. Correct
> implementation of this method may look so:
> -
> public String getModelValue()
> {
> // @@ Modified by SIY
> Object object = getModelObject();
> if (object != null)
> {
> // compare choice items with given keys and pass down
> // to IChoiceRenderer list item rather than key
> Iterator iter = getChoices().iterator();
> int i = 0;
> while (iter.hasNext())
> {
> Object obj = iter.next();
> if (obj != null && obj.equals(object))
> {
> object = obj;
> break;
> }
> i++;
> }
> if (i > getChoices().size())
> i = -1;
> return getChoiceRenderer().getIdValue(object, i);
> }
> return NO_SELECTION_VALUE;
> }
> ---
> Similar issues also present in ListMultipleChoice.getModelValue(), but they
> can't be resolved by overriding this method in subclass because this method
> declared final.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1334) README in wicket-examples confusing
[ https://issues.apache.org/jira/browse/WICKET-1334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12567695#action_12567695 ] Jacek Laskowski commented on WICKET-1334: - Just to add to Martijn's comments: I'm a novice and have never worked with Wicket before. README didn't help a bit to understand how examples were organized and such. I have worked with Maven so I could figure out how to work it out. Believe me or not, but all files need some "redisign". > README in wicket-examples confusing > --- > > Key: WICKET-1334 > URL: https://issues.apache.org/jira/browse/WICKET-1334 > Project: Wicket > Issue Type: Task > Components: wicket-examples >Affects Versions: 1.3.1 >Reporter: Jacek Laskowski >Assignee: Frank Bille Jensen > Fix For: 1.3.2 > > > README in wicket-examples (in 1.3.1 distro) is completely unreadable and > confusing. Where can I find the war? What's the root? "copy it to the webapps > directory" is about Tomcat's webapp, isn't it? The only information I could > find there relevant is that mvn package will build a war. It's definitely too > less for inexperience users. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (WICKET-1166) add sanity check on form submit for request method
[ https://issues.apache.org/jira/browse/WICKET-1166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Vaynberg resolved WICKET-1166. --- Resolution: Fixed applied javadoc patch. no processing logic was changed > add sanity check on form submit for request method > -- > > Key: WICKET-1166 > URL: https://issues.apache.org/jira/browse/WICKET-1166 > Project: Wicket > Issue Type: Improvement > Components: wicket >Affects Versions: 1.3.0-rc1 > Environment: Safari 3 >Reporter: Nathan Hamblen >Assignee: Igor Vaynberg >Priority: Minor > Fix For: 1.3.2 > > Attachments: submit-method-javadoc.patch, submit-method.patch > > > When refreshing a frameset that includes an already POST submitted Wicket > form in a frame, using the redirect to render strategy, Safari erroneously > requests the form's original target by GET, rather than the location that was > eventually redirected to. Therefore none of the form values are available in > the request object and NPEs will occur trying to access them in places like > AbstractConverter.java:55. > Because Form allows for a particular request method to be specified, I think > it should also confirm that the expected method was used instead of waiting > for an NPE in validation. The outcome is the same, but the cause of the error > (the client) would be more evident in server logs, etc. Patch to come... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
svn commit: r620523 - /wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/markup/html/form/Form.java
Author: ivaynberg
Date: Mon Feb 11 08:38:25 2008
New Revision: 620523
URL: http://svn.apache.org/viewvc?rev=620523&view=rev
Log:
WICKET-1166
Modified:
wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/markup/html/form/Form.java
Modified:
wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/markup/html/form/Form.java
URL:
http://svn.apache.org/viewvc/wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/markup/html/form/Form.java?rev=620523&r1=620522&r2=620523&view=diff
==
---
wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/markup/html/form/Form.java
(original)
+++
wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/markup/html/form/Form.java
Mon Feb 11 08:38:25 2008
@@ -1368,10 +1368,15 @@
/**
-* Gets the method used to submit the form. Defaults to either what is
explicitly defined in the
-* markup or 'post'. Override this if you have a requirement to alter
this behavior.
+* Gets the HTTP submit method that will appear in form markup. If no
method is specified in
+* the template, "post" is the default. Note that the markup-declared
HTTP method may not
+* correspond to the one actually used to submit the form; in an Ajax
submit, for example,
+* JavaScript event handlers may submit the form with a "get" even when
the form method is
+* declared as "post." Therefore this method should not be considered a
guarantee of the
+* HTTP method used, but a value for the markup only.
+* Override if you have a requirement to alter this behavior.
*
-* @return the method used to submit the form.
+* @return the submit method specified in markup.
*/
protected String getMethod()
{
[jira] Commented: (WICKET-1331) getModelValue() in AbstractSingleSelectChoice and ListMultipleChoice can't handle complex list items type correctly
[
https://issues.apache.org/jira/browse/WICKET-1331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12567689#action_12567689
]
Igor Vaynberg commented on WICKET-1331:
---
form.add(new DropDownChoice("option", getList(), new ChoiceRenderer("name",
"id"))); is not a proper use of ddc if your choices are of type Long. you are
using an invalid choice renderer. this choice renderer expects to work on a
pojo that has a getId() and getMethod() defined. that is whats causing your
error - when the choice renderer tries to call getId() on a member of
getList(). instead try a choice renderer like this:
new ichoicerenderer() {
string getidvalue(Object o) { return ""+o; }
string getdisplayvalue(Object o) { return ""+o; }
}
> getModelValue() in AbstractSingleSelectChoice and ListMultipleChoice can't
> handle complex list items type correctly
> ---
>
> Key: WICKET-1331
> URL: https://issues.apache.org/jira/browse/WICKET-1331
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.3.0-final, 1.3.1
> Environment: Suse 10.3, JRE 1.6 (1.6.0_04-b12), jetty 6.1.7
>Reporter: Sergiy Yevtushenko
>Assignee: Igor Vaynberg
> Attachments: testproject.zip
>
> Original Estimate: 0.5h
> Remaining Estimate: 0.5h
>
> AbstractSingleSelectChoice.getModelValue() implementation uses List.indexOf()
> to find the key and this causes problems if list of choices contains complex
> values rather than simple list of String instances. In this case indexOf()
> returns -1 and this can't be resolved by overriding equals() for list
> elements. This happens because internally AbstractList.indexOf() invokes
> equals() method of passed key value passing it list items as a parameter.
> Also, current implementation may pass key returned by getModelObject() to
> IChoiceRender, while it expects values from list of items. Correct
> implementation of this method may look so:
> -
> public String getModelValue()
> {
> // @@ Modified by SIY
> Object object = getModelObject();
> if (object != null)
> {
> // compare choice items with given keys and pass down
> // to IChoiceRenderer list item rather than key
> Iterator iter = getChoices().iterator();
> int i = 0;
> while (iter.hasNext())
> {
> Object obj = iter.next();
> if (obj != null && obj.equals(object))
> {
> object = obj;
> break;
> }
> i++;
> }
> if (i > getChoices().size())
> i = -1;
> return getChoiceRenderer().getIdValue(object, i);
> }
> return NO_SELECTION_VALUE;
> }
> ---
> Similar issues also present in ListMultipleChoice.getModelValue(), but they
> can't be resolved by overriding this method in subclass because this method
> declared final.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1325) according to Ajax-Feedback-Problem-in-1.3 at nabble-forum-wicket-user
[ https://issues.apache.org/jira/browse/WICKET-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12567688#action_12567688 ] Igor Vaynberg commented on WICKET-1325: --- you are welcome > according to Ajax-Feedback-Problem-in-1.3 at nabble-forum-wicket-user > - > > Key: WICKET-1325 > URL: https://issues.apache.org/jira/browse/WICKET-1325 > Project: Wicket > Issue Type: Test >Affects Versions: 1.2.6, 1.3.0-final > Environment: MS XP, Java5, Eclipse3.3europe >Reporter: Santiago Aucejo >Assignee: Igor Vaynberg >Priority: Trivial > Attachments: ValidationTest.iamzip > > > As described in Ajax-Feedback-Problem-in-1.3 in the nabble forum > "wicket-user" there is a Problem with the validation, wich i had not been > able to solve. > The validation works fine in 1.2.6 but does not in 1.3 . -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-1166) add sanity check on form submit for request method
[ https://issues.apache.org/jira/browse/WICKET-1166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nathan Hamblen updated WICKET-1166: --- Attachment: submit-method-javadoc.patch I'm not sure where the formal requirements would be, but I do find the method's documentation misleading for the current behavior: "Gets the method used to submit the form." As I've said I think it's a reasonable solution to just update the javadocs, so, here's a patch that does that. In the longer run I still think it would be better to lock down the submit process a little more. The same reasons that that is difficult are the reasons I think it should be done: with ajax and nesting, forms have become a pretty fuzzy concept in Wicket. For a user looking at the API it's not clear what will happen under various scenarios. But, that's just my opinion. Feel free to close with or without this javadoc patch. > add sanity check on form submit for request method > -- > > Key: WICKET-1166 > URL: https://issues.apache.org/jira/browse/WICKET-1166 > Project: Wicket > Issue Type: Improvement > Components: wicket >Affects Versions: 1.3.0-rc1 > Environment: Safari 3 >Reporter: Nathan Hamblen >Assignee: Igor Vaynberg >Priority: Minor > Fix For: 1.3.2 > > Attachments: submit-method-javadoc.patch, submit-method.patch > > > When refreshing a frameset that includes an already POST submitted Wicket > form in a frame, using the redirect to render strategy, Safari erroneously > requests the form's original target by GET, rather than the location that was > eventually redirected to. Therefore none of the form values are available in > the request object and NPEs will occur trying to access them in places like > AbstractConverter.java:55. > Because Form allows for a particular request method to be specified, I think > it should also confirm that the expected method was used instead of waiting > for an NPE in validation. The outcome is the same, but the cause of the error > (the client) would be more evident in server logs, etc. Patch to come... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (WICKET-1166) add sanity check on form submit for request method
[ https://issues.apache.org/jira/browse/WICKET-1166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ate Douma reassigned WICKET-1166: - Assignee: Igor Vaynberg (was: Ate Douma) > add sanity check on form submit for request method > -- > > Key: WICKET-1166 > URL: https://issues.apache.org/jira/browse/WICKET-1166 > Project: Wicket > Issue Type: Improvement > Components: wicket >Affects Versions: 1.3.0-rc1 > Environment: Safari 3 >Reporter: Nathan Hamblen >Assignee: Igor Vaynberg >Priority: Minor > Fix For: 1.3.2 > > Attachments: submit-method.patch > > > When refreshing a frameset that includes an already POST submitted Wicket > form in a frame, using the redirect to render strategy, Safari erroneously > requests the form's original target by GET, rather than the location that was > eventually redirected to. Therefore none of the form values are available in > the request object and NPEs will occur trying to access them in places like > AbstractConverter.java:55. > Because Form allows for a particular request method to be specified, I think > it should also confirm that the expected method was used instead of waiting > for an NPE in validation. The outcome is the same, but the cause of the error > (the client) would be more evident in server logs, etc. Patch to come... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1166) add sanity check on form submit for request method
[ https://issues.apache.org/jira/browse/WICKET-1166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12567661#action_12567661 ] Ate Douma commented on WICKET-1166: --- I don't think this check on the method used is correct in this situation. As Johan said, its for generating markup and I don't think it should not (need to) be enforced during the submit. With regards to portlets, yeah: potentially there might be an issue too, at least for JSR-168 (Portlet API 1.0). The current 1.0 portlet spec doesn't formally support servlet access during processAction (when a form submit is processed), but through the Apache Portals Bridge ServletContext solution it actually is possible to do so and WicketPortlet uses it as such. Now, as a servlet context doesn't formally "exist" in Portlet API 1.0, it really depends on the Portal implementation how/what the getMethod() will return. Most likely simply the value as provided by the underlying servlet request, as in the case of Jetspeed-2 portal, but other portals *might* do it differently. Now, for the imminent Portlet API 2.0 (JSR-286, which finally has been submitted to the JCP for validation), this problem will be solved: as it then formally allows servlet access during processAction and getMethod() will return the original value. So, exactly as the current Apache Portlet Bridge and Jetspeed-2 are doing. To cut it short, most likely there won't be a problem with portlets and definitely not when using JSR-286. Still, I don't think this specific use-case (a bug in Safari) warrants such a check which is too strict and beyond the formal requirements in my view. > add sanity check on form submit for request method > -- > > Key: WICKET-1166 > URL: https://issues.apache.org/jira/browse/WICKET-1166 > Project: Wicket > Issue Type: Improvement > Components: wicket >Affects Versions: 1.3.0-rc1 > Environment: Safari 3 >Reporter: Nathan Hamblen >Assignee: Ate Douma >Priority: Minor > Fix For: 1.3.2 > > Attachments: submit-method.patch > > > When refreshing a frameset that includes an already POST submitted Wicket > form in a frame, using the redirect to render strategy, Safari erroneously > requests the form's original target by GET, rather than the location that was > eventually redirected to. Therefore none of the form values are available in > the request object and NPEs will occur trying to access them in places like > AbstractConverter.java:55. > Because Form allows for a particular request method to be specified, I think > it should also confirm that the expected method was used instead of waiting > for an NPE in validation. The outcome is the same, but the cause of the error > (the client) would be more evident in server logs, etc. Patch to come... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (WICKET-1334) README in wicket-examples confusing
[ https://issues.apache.org/jira/browse/WICKET-1334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martijn Dashorst closed WICKET-1334. Resolution: Fixed Fix Version/s: 1.3.2 Removed the readme, as the examples are no longer distributed separately. > README in wicket-examples confusing > --- > > Key: WICKET-1334 > URL: https://issues.apache.org/jira/browse/WICKET-1334 > Project: Wicket > Issue Type: Task > Components: wicket-examples >Affects Versions: 1.3.1 >Reporter: Jacek Laskowski >Assignee: Frank Bille Jensen > Fix For: 1.3.2 > > > README in wicket-examples (in 1.3.1 distro) is completely unreadable and > confusing. Where can I find the war? What's the root? "copy it to the webapps > directory" is about Tomcat's webapp, isn't it? The only information I could > find there relevant is that mvn package will build a war. It's definitely too > less for inexperience users. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
svn commit: r620491 - /wicket/trunk/jdk-1.5/wicket-examples/README.txt
Author: dashorst Date: Mon Feb 11 06:33:46 2008 New Revision: 620491 URL: http://svn.apache.org/viewvc?rev=620491&view=rev Log: WICKET-1334 Removed: wicket/trunk/jdk-1.5/wicket-examples/README.txt
[jira] Created: (WICKET-1337) ListMultipleChoice doesn't work when entries are preselected
ListMultipleChoice doesn't work when entries are preselected
Key: WICKET-1337
URL: https://issues.apache.org/jira/browse/WICKET-1337
Project: Wicket
Issue Type: Bug
Components: wicket
Affects Versions: 1.3.1
Reporter: Thomas Jaeckle
I tried to preselect all entries in a ListMultipleChoice:
List priorityList = getPriorityList();
lmcPriority = new ListMultipleChoice("selectContent", new Model(),
priorityList);
lmcPriority.setModelObject(priorityList);
That works, but when I now start deselecting some items or I select just one
item, the ListMultipleChoice has the wrong list.
For the szenarios I did a "System.out.println(getModelObject());" at the end of
ListMultipleChoice.updateModel()
---
First szenario:
This is my list of priorities:
[very high, high, medium, low, very low]
After I deselect (with Ctrl-Key pressed) "medium" I get:
[very high, high, low, very low]
After I deselect "high" I get:
[very high, very low]
After I deselect "very high" I get:
[] (empty List)
At this time "low" and "very low" are still selected.
---
Second szenario:
This is my list of priorities:
[very high, high, medium, low, very low]
I select only "medium":
[medium]
I select only "high":
[] (empty List)
I select only "low":
[] (empty List)
At this point I can select what I want, but the list never has entries.
---
When I don't preselect all entries, everything works fine.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-1331) getModelValue() in AbstractSingleSelectChoice and ListMultipleChoice can't handle complex list items type correctly
[
https://issues.apache.org/jira/browse/WICKET-1331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergiy Yevtushenko updated WICKET-1331:
---
Attachment: testproject.zip
Test project which exposes the issue
> getModelValue() in AbstractSingleSelectChoice and ListMultipleChoice can't
> handle complex list items type correctly
> ---
>
> Key: WICKET-1331
> URL: https://issues.apache.org/jira/browse/WICKET-1331
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.3.0-final, 1.3.1
> Environment: Suse 10.3, JRE 1.6 (1.6.0_04-b12), jetty 6.1.7
>Reporter: Sergiy Yevtushenko
>Assignee: Igor Vaynberg
> Attachments: testproject.zip
>
> Original Estimate: 0.5h
> Remaining Estimate: 0.5h
>
> AbstractSingleSelectChoice.getModelValue() implementation uses List.indexOf()
> to find the key and this causes problems if list of choices contains complex
> values rather than simple list of String instances. In this case indexOf()
> returns -1 and this can't be resolved by overriding equals() for list
> elements. This happens because internally AbstractList.indexOf() invokes
> equals() method of passed key value passing it list items as a parameter.
> Also, current implementation may pass key returned by getModelObject() to
> IChoiceRender, while it expects values from list of items. Correct
> implementation of this method may look so:
> -
> public String getModelValue()
> {
> // @@ Modified by SIY
> Object object = getModelObject();
> if (object != null)
> {
> // compare choice items with given keys and pass down
> // to IChoiceRenderer list item rather than key
> Iterator iter = getChoices().iterator();
> int i = 0;
> while (iter.hasNext())
> {
> Object obj = iter.next();
> if (obj != null && obj.equals(object))
> {
> object = obj;
> break;
> }
> i++;
> }
> if (i > getChoices().size())
> i = -1;
> return getChoiceRenderer().getIdValue(object, i);
> }
> return NO_SELECTION_VALUE;
> }
> ---
> Similar issues also present in ListMultipleChoice.getModelValue(), but they
> can't be resolved by overriding this method in subclass because this method
> declared final.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1331) getModelValue() in AbstractSingleSelectChoice and ListMultipleChoice can't handle complex list items type correctly
[
https://issues.apache.org/jira/browse/WICKET-1331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12567597#action_12567597
]
Sergiy Yevtushenko commented on WICKET-1331:
I've attached test project based on quickstart which exposes the issue -
attempt to access home page fails with following exception (relevant part):
org.apache.wicket.WicketRuntimeException: No get method defined for class:
class java.lang.Long expression: id
at
org.apache.wicket.util.lang.PropertyResolver.getGetAndSetter(PropertyResolver.java:433)
at
org.apache.wicket.util.lang.PropertyResolver.getObjectAndGetSetter(PropertyResolver.java:275)
at
org.apache.wicket.util.lang.PropertyResolver.getValue(PropertyResolver.java:84)
at
org.apache.wicket.markup.html.form.ChoiceRenderer.getIdValue(ChoiceRenderer.java:140)
at
org.apache.wicket.markup.html.form.AbstractSingleSelectChoice.getModelValue(AbstractSingleSelectChoice.java:144)
at
org.apache.wicket.markup.html.form.FormComponent.getValue(FormComponent.java:744)
at
org.apache.wicket.markup.html.form.AbstractChoice.onComponentTagBody(AbstractChoice.java:344)
...
If in HomePage.java make following changes:
...
// default AbstractSingleSelectChoice.getModelValue():
//form.add(new DropDownChoice("option", getList(), new
ChoiceRenderer("name", "id"))); <-
// Overridden AbstractSingleSelectChoice.getModelValue();
form.add(new ModifiedDropDownChoice("option", getList(), new
ChoiceRenderer("name", "id"))); //<-
...
then home page is rendered properly. Also, this test application seems expose
another issue which I didn't see before - attempt to submit for traps.
Debugging shows that in this case entire choice list item is passed without
conversion. I've not digged deeper.
> getModelValue() in AbstractSingleSelectChoice and ListMultipleChoice can't
> handle complex list items type correctly
> ---
>
> Key: WICKET-1331
> URL: https://issues.apache.org/jira/browse/WICKET-1331
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.3.0-final, 1.3.1
> Environment: Suse 10.3, JRE 1.6 (1.6.0_04-b12), jetty 6.1.7
>Reporter: Sergiy Yevtushenko
>Assignee: Igor Vaynberg
> Original Estimate: 0.5h
> Remaining Estimate: 0.5h
>
> AbstractSingleSelectChoice.getModelValue() implementation uses List.indexOf()
> to find the key and this causes problems if list of choices contains complex
> values rather than simple list of String instances. In this case indexOf()
> returns -1 and this can't be resolved by overriding equals() for list
> elements. This happens because internally AbstractList.indexOf() invokes
> equals() method of passed key value passing it list items as a parameter.
> Also, current implementation may pass key returned by getModelObject() to
> IChoiceRender, while it expects values from list of items. Correct
> implementation of this method may look so:
> -
> public String getModelValue()
> {
> // @@ Modified by SIY
> Object object = getModelObject();
> if (object != null)
> {
> // compare choice items with given keys and pass down
> // to IChoiceRenderer list item rather than key
> Iterator iter = getChoices().iterator();
> int i = 0;
> while (iter.hasNext())
> {
> Object obj = iter.next();
> if (obj != null && obj.equals(object))
> {
> object = obj;
> break;
> }
> i++;
> }
> if (i > getChoices().size())
> i = -1;
> return getChoiceRenderer().getIdValue(object, i);
> }
> return NO_SELECTION_VALUE;
> }
> ---
> Similar issues also present in ListMultipleChoice.getModelValue(), but they
> can't be resolved by overriding this method in subclass because this method
> declared final.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1334) README in wicket-examples confusing
[ https://issues.apache.org/jira/browse/WICKET-1334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12567591#action_12567591 ] Martijn Dashorst commented on WICKET-1334: -- Completely unreadable and confusing? WTF? You are the first one to have problems with it. > README in wicket-examples confusing > --- > > Key: WICKET-1334 > URL: https://issues.apache.org/jira/browse/WICKET-1334 > Project: Wicket > Issue Type: Task > Components: wicket-examples >Affects Versions: 1.3.1 >Reporter: Jacek Laskowski >Assignee: Frank Bille Jensen > > README in wicket-examples (in 1.3.1 distro) is completely unreadable and > confusing. Where can I find the war? What's the root? "copy it to the webapps > directory" is about Tomcat's webapp, isn't it? The only information I could > find there relevant is that mvn package will build a war. It's definitely too > less for inexperience users. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-279) Wicket-spring Fix for classloading in a clustered Weblogic 9.x
[ https://issues.apache.org/jira/browse/WICKET-279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12567583#action_12567583 ] Timo Rantalaiho commented on WICKET-279: Could this also be fixed in 1.2 (1.2.7 maybe)? This would fix some problems of deployin 1.2 applications to WLS cluster. > Wicket-spring Fix for classloading in a clustered Weblogic 9.x > --- > > Key: WICKET-279 > URL: https://issues.apache.org/jira/browse/WICKET-279 > Project: Wicket > Issue Type: Bug > Components: wicket-spring >Affects Versions: 1.2.3, 1.2.4, 1.2.5 > Environment: Weblogic 9.2 (clustered environment) on Solaris 10.0 >Reporter: Scott T Weaver >Assignee: Igor Vaynberg > Fix For: 1.3.0-beta1 > > Attachments: fix-wls-clustered-classloading.patch > > > This patch addresses an issue with classloading performed by > wicket.proxy.LazyInitProxyFactory within the context of a Weblogic Server 9.2 > clustered application environment (stack trace at the bottom of the email). > The long and the short of it is that > Thread.currentThread().getContextClassLoader() will fail to load the proxied > interface. The fix was quite simple: catch the IAE and attempt to load the > interface using the current classloader > (LazyInitProxyFactory.class.getClassLoader()). This works like a charm and I > have had in production for almost 3 months now with no issues whatsoever. > Stacktrace from WLS 9.2 > fai > led > java.lang.IllegalArgumentException: interface > com.ugs.it.partnersxpress.util.Or > derTrackingBeanFactory is not visible from class loader. > java.lang.IllegalArgumentException: interface > com.ugs.it.partnersxpress.util.Ord > erTrackingBeanFactory is not visible from class loader > at weblogic.rjvm.ResponseImpl.unmarshalReturn(ResponseImpl.java:195) > at > weblogic.rmi.internal.BasicRemoteRef.invoke(BasicRemoteRef.java:224) > at > weblogic.cluster.replication.ReplicationManager_920_WLStub.update(Unk > nown Source) > at > weblogic.cluster.replication.ReplicationManager.updateSecondary(Repli > cationManager.java:525) > at > weblogic.servlet.internal.session.ReplicatedSessionData.syncSession(R > eplicatedSessionData.java:516) > Truncated. see log file for complete stacktrace > java.lang.IllegalArgumentException: interface > com.ugs.it.partnersxpress.util.Ord > erTrackingBeanFactory is not visible from class loader > at java.lang.reflect.Proxy.getProxyClass(Proxy.java:345) > at java.lang.reflect.Proxy.newProxyInstance(Proxy.java:564) > at > wicket.proxy.LazyInitProxyFactory.createProxy(LazyInitProxyFactory.ja > va:124) > at > wicket.proxy.LazyInitProxyFactory$ProxyReplacement.readResolve(LazyIn > itProxyFactory.java:206) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > Truncated. see log file for complete stacktrace > > > fai > led > java.lang.IllegalArgumentException: interface > com.ugs.it.partnersxpress.util.Or > derTrackingBeanFactory is not visible from class loader. > java.lang.IllegalArgumentException: interface > com.ugs.it.partnersxpress.util.Ord > erTrackingBeanFactory is not visible from class loader > at weblogic.rjvm.ResponseImpl.unmarshalReturn(ResponseImpl.java:195) > at > weblogic.rmi.internal.BasicRemoteRef.invoke(BasicRemoteRef.java:224) > at > weblogic.cluster.replication.ReplicationManager_920_WLStub.update(Unk > nown Source) > at > weblogic.cluster.replication.ReplicationManager.updateSecondary(Repli > cationManager.java:525) > at > weblogic.servlet.internal.session.ReplicatedSessionData.syncSession(R > eplicatedSessionData.java:516) > Truncated. see log file for complete stacktrace > java.lang.IllegalArgumentException: interface > com.ugs.it.partnersxpress.util.Ord > erTrackingBeanFactory is not visible from class loader > at java.lang.reflect.Proxy.getProxyClass(Proxy.java:345) > at java.lang.reflect.Proxy.newProxyInstance(Proxy.java:564) > at > wicket.proxy.LazyInitProxyFactory.createProxy(LazyInitProxyFactory.ja > va:124) > at > wicket.proxy.LazyInitProxyFactory$ProxyReplacement.readResolve(LazyIn > itProxyFactory.java:206) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > Truncated. see log file for complete stacktrace > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1325) according to Ajax-Feedback-Problem-in-1.3 at nabble-forum-wicket-user
[ https://issues.apache.org/jira/browse/WICKET-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12567546#action_12567546 ] Santiago Aucejo commented on WICKET-1325: - Thank you. Now it works (the Wicket way)! Thank you for the time you spent on that. > according to Ajax-Feedback-Problem-in-1.3 at nabble-forum-wicket-user > - > > Key: WICKET-1325 > URL: https://issues.apache.org/jira/browse/WICKET-1325 > Project: Wicket > Issue Type: Test >Affects Versions: 1.2.6, 1.3.0-final > Environment: MS XP, Java5, Eclipse3.3europe >Reporter: Santiago Aucejo >Assignee: Igor Vaynberg >Priority: Trivial > Attachments: ValidationTest.iamzip > > > As described in Ajax-Feedback-Problem-in-1.3 in the nabble forum > "wicket-user" there is a Problem with the validation, wich i had not been > able to solve. > The validation works fine in 1.2.6 but does not in 1.3 . -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
