[jira] Resolved: (WICKET-2848) Rename yahoo-dom-event folder to something else
[ https://issues.apache.org/jira/browse/WICKET-2848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerolf Seitz resolved WICKET-2848. -- Assignee: Gerolf Seitz Fix Version/s: 1.4.11 1.5-M2 Resolution: Fixed renamed the folder to yahoodomevent since urlFor in 1.5 doesn't append a trailing '/' to a ResourceReference with an empty name, the missing '/' gets appended explicitly in DatePicker.java > Rename yahoo-dom-event folder to something else > --- > > Key: WICKET-2848 > URL: https://issues.apache.org/jira/browse/WICKET-2848 > Project: Wicket > Issue Type: Bug > Components: wicket-datetime >Reporter: David Leangen >Assignee: Gerolf Seitz >Priority: Minor > Fix For: 1.4.11, 1.5-M2 > > > When trying to use Wicket in OSGi under Equinox, the name of this directory > is causing import/export problems. > I am using a local patch with a different name, and it works just fine. > Would be very nice if this file could either be moved or we rename the > yahoo-dom-event (to something like yahoodomevent). -- 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-2771) Please support "isPrimary" for @SpringBean
[
https://issues.apache.org/jira/browse/WICKET-2771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12872891#action_12872891
]
Gerolf Seitz edited comment on WICKET-2771 at 5/28/10 8:13 PM:
---
see WICKET-2900
was (Author: seitz):
It would be great, if you could open a new jira issue for that.
thanks.
> Please support "isPrimary" for @SpringBean
> --
>
> Key: WICKET-2771
> URL: https://issues.apache.org/jira/browse/WICKET-2771
> Project: Wicket
> Issue Type: Improvement
> Components: wicket-spring
>Reporter: Kathrin Baumgartner
>Assignee: Juergen Donnerstag
> Fix For: 1.4.8, 1.5-M1
>
>
> Our application must be adaptable for customer needs. We therefore need to be
> able to inject customer specific services. Since all our services are
> autowired, we could solve this by using the "primary" attribute.
> Our propsal is to patch SpringBeanLocator:
> private final String getBeanNameOfClass(ApplicationContext ctx, Class< ? >
> clazz) {
> // get the list of all possible matching beans
> List names = new
> ArrayList(Arrays.asList(BeanFactoryUtils
> .beanNamesForTypeIncludingAncestors(ctx, clazz)));
> Iterator it = names.iterator();
> // filter out beans that are not condidates for autowiring
> while (it.hasNext()) {
> final String possibility = it.next();
> if (BeanFactoryUtils.isFactoryDereference(possibility) ||
> possibility.startsWith("scopedTarget.")) {
> it.remove();
> }
> }
> if (names.isEmpty()) {
> throw new IllegalStateException("bean of type [" +
> clazz.getName() + "] not found");
> } else if (names.size() > 1) {
> / add this
> ///
> for (String name : names){
> BeanDefinition beanDef =
> ((AbstractApplicationContext)ctx).getBeanFactory().getBeanDefinition(name);
> if(((AbstractBeanDefinition)beanDef).isPrimary()){
> return name;
> }
> }
>
> //
> // found no match
> StringBuilder msg = new StringBuilder();
> msg.append("more then one bean of type [");
> msg.append(clazz.getName());
> msg.append("] found, you have to specify the name of the
> bean ");
> msg.append("(@SpringBean(name=\"foo\")) in order to resolve
> this conflict. ");
> msg.append("Matched beans: ");
> msg.append(Strings.join(",", names.toArray(new String[0])));
> throw new IllegalStateException(msg.toString());
> }
> else{
> return names.get(0);
> }
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (WICKET-2900) "isPrimary" check is not applied to beans in parent contexts
[ https://issues.apache.org/jira/browse/WICKET-2900?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerolf Seitz resolved WICKET-2900. -- Resolution: Fixed > "isPrimary" check is not applied to beans in parent contexts > > > Key: WICKET-2900 > URL: https://issues.apache.org/jira/browse/WICKET-2900 > Project: Wicket > Issue Type: Bug > Components: wicket-spring >Affects Versions: 1.4.9 >Reporter: Gerolf Seitz >Assignee: Gerolf Seitz >Priority: Minor > Fix For: 1.4.10, 1.5-M1 > > > see this comment in WICKET-2771: > https://issues.apache.org/jira/browse/WICKET-2771?focusedCommentId=12872246&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_12872246 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-2900) "isPrimary" check is not applied to beans in parent contexts
[ https://issues.apache.org/jira/browse/WICKET-2900?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerolf Seitz updated WICKET-2900: - Fix Version/s: 1.4.10 > "isPrimary" check is not applied to beans in parent contexts > > > Key: WICKET-2900 > URL: https://issues.apache.org/jira/browse/WICKET-2900 > Project: Wicket > Issue Type: Bug > Components: wicket-spring >Affects Versions: 1.4.9 >Reporter: Gerolf Seitz >Assignee: Gerolf Seitz >Priority: Minor > Fix For: 1.4.10, 1.5-M1 > > > see this comment in WICKET-2771: > https://issues.apache.org/jira/browse/WICKET-2771?focusedCommentId=12872246&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_12872246 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-2901) Always the first bean with primary=true is returned, even if there are more than one primary beans
[ https://issues.apache.org/jira/browse/WICKET-2901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerolf Seitz updated WICKET-2901: - Fix Version/s: 1.4.10 > Always the first bean with primary=true is returned, even if there are more > than one primary beans > -- > > Key: WICKET-2901 > URL: https://issues.apache.org/jira/browse/WICKET-2901 > Project: Wicket > Issue Type: Bug > Components: wicket-spring >Affects Versions: 1.4.9 >Reporter: Gerolf Seitz >Assignee: Gerolf Seitz > Fix For: 1.4.10, 1.5-M1 > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (WICKET-2901) Always the first bean with primary=true is returned, even if there are more than one primary beans
[ https://issues.apache.org/jira/browse/WICKET-2901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerolf Seitz resolved WICKET-2901. -- Resolution: Fixed > Always the first bean with primary=true is returned, even if there are more > than one primary beans > -- > > Key: WICKET-2901 > URL: https://issues.apache.org/jira/browse/WICKET-2901 > Project: Wicket > Issue Type: Bug > Components: wicket-spring >Affects Versions: 1.4.9 >Reporter: Gerolf Seitz >Assignee: Gerolf Seitz > Fix For: 1.4.10, 1.5-M1 > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-2901) Always the first bean with primary=true is returned, even if there are more than one primary beans
Always the first bean with primary=true is returned, even if there are more than one primary beans -- Key: WICKET-2901 URL: https://issues.apache.org/jira/browse/WICKET-2901 Project: Wicket Issue Type: Bug Components: wicket-spring Affects Versions: 1.4.9 Reporter: Gerolf Seitz Assignee: Gerolf Seitz Fix For: 1.5-M1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-2900) "isPrimary" check is not applied to beans in parent contexts
"isPrimary" check is not applied to beans in parent contexts Key: WICKET-2900 URL: https://issues.apache.org/jira/browse/WICKET-2900 Project: Wicket Issue Type: Bug Components: wicket-spring Affects Versions: 1.4.9 Reporter: Gerolf Seitz Assignee: Gerolf Seitz Priority: Minor Fix For: 1.5-M1 see this comment in WICKET-2771: https://issues.apache.org/jira/browse/WICKET-2771?focusedCommentId=12872246&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_12872246 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-2771) Please support "isPrimary" for @SpringBean
[
https://issues.apache.org/jira/browse/WICKET-2771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12872891#action_12872891
]
Gerolf Seitz commented on WICKET-2771:
--
It would be great, if you could open a new jira issue for that.
thanks.
> Please support "isPrimary" for @SpringBean
> --
>
> Key: WICKET-2771
> URL: https://issues.apache.org/jira/browse/WICKET-2771
> Project: Wicket
> Issue Type: Improvement
> Components: wicket-spring
>Reporter: Kathrin Baumgartner
>Assignee: Juergen Donnerstag
> Fix For: 1.4.8, 1.5-M1
>
>
> Our application must be adaptable for customer needs. We therefore need to be
> able to inject customer specific services. Since all our services are
> autowired, we could solve this by using the "primary" attribute.
> Our propsal is to patch SpringBeanLocator:
> private final String getBeanNameOfClass(ApplicationContext ctx, Class< ? >
> clazz) {
> // get the list of all possible matching beans
> List names = new
> ArrayList(Arrays.asList(BeanFactoryUtils
> .beanNamesForTypeIncludingAncestors(ctx, clazz)));
> Iterator it = names.iterator();
> // filter out beans that are not condidates for autowiring
> while (it.hasNext()) {
> final String possibility = it.next();
> if (BeanFactoryUtils.isFactoryDereference(possibility) ||
> possibility.startsWith("scopedTarget.")) {
> it.remove();
> }
> }
> if (names.isEmpty()) {
> throw new IllegalStateException("bean of type [" +
> clazz.getName() + "] not found");
> } else if (names.size() > 1) {
> / add this
> ///
> for (String name : names){
> BeanDefinition beanDef =
> ((AbstractApplicationContext)ctx).getBeanFactory().getBeanDefinition(name);
> if(((AbstractBeanDefinition)beanDef).isPrimary()){
> return name;
> }
> }
>
> //
> // found no match
> StringBuilder msg = new StringBuilder();
> msg.append("more then one bean of type [");
> msg.append(clazz.getName());
> msg.append("] found, you have to specify the name of the
> bean ");
> msg.append("(@SpringBean(name=\"foo\")) in order to resolve
> this conflict. ");
> msg.append("Matched beans: ");
> msg.append(Strings.join(",", names.toArray(new String[0])));
> throw new IllegalStateException(msg.toString());
> }
> else{
> return names.get(0);
> }
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-2771) Please support "isPrimary" for @SpringBean
[
https://issues.apache.org/jira/browse/WICKET-2771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12871399#action_12871399
]
Gerolf Seitz commented on WICKET-2771:
--
I applied the changes made to SpringBeanLocator also to
AnnotProxyFieldValueFactory (in both 1.4.x and trunk), as the
SpringComponentInjector uses AnnotProxyFieldValueFactory instead of
SpringBeanLocator.
> Please support "isPrimary" for @SpringBean
> --
>
> Key: WICKET-2771
> URL: https://issues.apache.org/jira/browse/WICKET-2771
> Project: Wicket
> Issue Type: Improvement
> Components: wicket-spring
>Reporter: Kathrin Baumgartner
>Assignee: Juergen Donnerstag
> Fix For: 1.4.8, 1.5-M1
>
>
> Our application must be adaptable for customer needs. We therefore need to be
> able to inject customer specific services. Since all our services are
> autowired, we could solve this by using the "primary" attribute.
> Our propsal is to patch SpringBeanLocator:
> private final String getBeanNameOfClass(ApplicationContext ctx, Class< ? >
> clazz) {
> // get the list of all possible matching beans
> List names = new
> ArrayList(Arrays.asList(BeanFactoryUtils
> .beanNamesForTypeIncludingAncestors(ctx, clazz)));
> Iterator it = names.iterator();
> // filter out beans that are not condidates for autowiring
> while (it.hasNext()) {
> final String possibility = it.next();
> if (BeanFactoryUtils.isFactoryDereference(possibility) ||
> possibility.startsWith("scopedTarget.")) {
> it.remove();
> }
> }
> if (names.isEmpty()) {
> throw new IllegalStateException("bean of type [" +
> clazz.getName() + "] not found");
> } else if (names.size() > 1) {
> / add this
> ///
> for (String name : names){
> BeanDefinition beanDef =
> ((AbstractApplicationContext)ctx).getBeanFactory().getBeanDefinition(name);
> if(((AbstractBeanDefinition)beanDef).isPrimary()){
> return name;
> }
> }
>
> //
> // found no match
> StringBuilder msg = new StringBuilder();
> msg.append("more then one bean of type [");
> msg.append(clazz.getName());
> msg.append("] found, you have to specify the name of the
> bean ");
> msg.append("(@SpringBean(name=\"foo\")) in order to resolve
> this conflict. ");
> msg.append("Matched beans: ");
> msg.append(Strings.join(",", names.toArray(new String[0])));
> throw new IllegalStateException(msg.toString());
> }
> else{
> return names.get(0);
> }
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (WICKET-2365) Please support "autowire-candidate" attribute of a bean when injecting via @SpringBean
[ https://issues.apache.org/jira/browse/WICKET-2365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerolf Seitz resolved WICKET-2365. -- Assignee: Gerolf Seitz Resolution: Fixed fixed. > Please support "autowire-candidate" attribute of a bean when injecting via > @SpringBean > -- > > Key: WICKET-2365 > URL: https://issues.apache.org/jira/browse/WICKET-2365 > Project: Wicket > Issue Type: Improvement > Components: wicket-spring >Reporter: Ben Hutchison >Assignee: Gerolf Seitz >Priority: Minor > Fix For: 1.5-M1 > > > Currently, when injecting Spring autowired dependencies via @SpringBean, > Wicket's Spring integration does not take account of the optional > "autowire-candidate" attribute of a bean. This attribute tells spring not to > consider a bean during autowiring. > Here's our use case where we discovered this limitation. Our app uses 2 > databases, a default database used by 95% of the code, and a reporting > database used by the reports component. As a result we have 2 > SessionFactories in our context, and this breaks @SpringBean injection. > It would be nice to cater for the 95% of code that doesn't use the reporting > database, and use explicit names only for the other 5%. This seems to require > the Wicket-Spring integration to understand the "autowire-candidate=false" > attribute. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (WICKET-2860) Wrong name for swiss Application.properties
[ https://issues.apache.org/jira/browse/WICKET-2860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerolf Seitz resolved WICKET-2860. -- Assignee: Gerolf Seitz Fix Version/s: 1.4.9 1.5-M1 Resolution: Fixed Fixed. > Wrong name for swiss Application.properties > --- > > Key: WICKET-2860 > URL: https://issues.apache.org/jira/browse/WICKET-2860 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.4.8 >Reporter: Minas Manthos >Assignee: Gerolf Seitz >Priority: Trivial > Fix For: 1.4.9, 1.5-M1 > > > A 'Application_ch.properties' was generated due fixing Issue: WICKET-743 but > the correct language-extension for German/Swiss is '_de_CH' and not '_ch' > (witch stands for Chamorro). > Fix: rename 'Application_ch.properties' to 'Application_de_CH.properties'. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (WICKET-2870) Fix hungarian translation for Wizard
[ https://issues.apache.org/jira/browse/WICKET-2870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerolf Seitz resolved WICKET-2870. -- Assignee: Gerolf Seitz Fix Version/s: 1.4.9 1.5-M1 Resolution: Fixed Fixed. Thanks for the patch. > Fix hungarian translation for Wizard > > > Key: WICKET-2870 > URL: https://issues.apache.org/jira/browse/WICKET-2870 > Project: Wicket > Issue Type: Improvement > Components: wicket-extensions >Affects Versions: 1.4.8 >Reporter: Major Peter >Assignee: Gerolf Seitz > Fix For: 1.4.9, 1.5-M1 > > Attachments: wizard.patch > > Original Estimate: 0.08h > Remaining Estimate: 0.08h > > The current Wizard_hu.properties contains spelling errors... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (WICKET-2009) Update Quickstart to use archetype:generate goal instead of archetype:create
[ https://issues.apache.org/jira/browse/WICKET-2009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerolf Seitz resolved WICKET-2009. -- Fix Version/s: 1.5-M1 Resolution: Fixed I converted the archetype to the new Maven Archetype 2.x format. (See specification at [0]) Basically the same was done here [1] with source code available here [2]. This article made me curious about the new format and the end result is (surprise, surprise) pretty much the same ;) [0] http://maven.apache.org/archetype/maven-archetype-plugin/specification/archetype-metadata.html [1] http://www.theserverside.com/news/thread.tss?thread_id=60139 [2] http://github.com/mulesoft/mulesoft-maven-archetypes > Update Quickstart to use archetype:generate goal instead of archetype:create > > > Key: WICKET-2009 > URL: https://issues.apache.org/jira/browse/WICKET-2009 > Project: Wicket > Issue Type: Improvement > Components: wicket-quickstart > Environment: All >Reporter: Martin Grigorov >Assignee: Gerolf Seitz >Priority: Trivial > Fix For: 1.5-M1 > > > Running > mvn archetype:create -DarchetypeGroupId=org.apache.wicket > -DarchetypeArtifactId=wicket-archetype-quickstart -DarchetypeVersion=1.3.5 > -DgroupId=com.mycompany -DartifactId=myproject > dumps this warning: > [WARNING] This goal is deprecated. Please use mvn archetype:generate instead > Running > mvn archetype:generate -DarchetypeGroupId=org.apache.wicket > -DarchetypeArtifactId=wicket-archetype-quickstart -DarchetypeVersion=1.3.5 > -DgroupId=com.mycompany -DartifactId=myproject > generates the project but still produces this weird info: > [INFO] Using following parameters for creating *Old*Archetype: > wicket-archetype-quickstart:1.3.5 > I have no idea what 'OldArchetype' should means. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (WICKET-2009) Update Quickstart to use archetype:generate goal instead of archetype:create
[ https://issues.apache.org/jira/browse/WICKET-2009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerolf Seitz reassigned WICKET-2009: Assignee: Gerolf Seitz > Update Quickstart to use archetype:generate goal instead of archetype:create > > > Key: WICKET-2009 > URL: https://issues.apache.org/jira/browse/WICKET-2009 > Project: Wicket > Issue Type: Improvement > Components: wicket-quickstart > Environment: All >Reporter: Martin Grigorov >Assignee: Gerolf Seitz >Priority: Trivial > > Running > mvn archetype:create -DarchetypeGroupId=org.apache.wicket > -DarchetypeArtifactId=wicket-archetype-quickstart -DarchetypeVersion=1.3.5 > -DgroupId=com.mycompany -DartifactId=myproject > dumps this warning: > [WARNING] This goal is deprecated. Please use mvn archetype:generate instead > Running > mvn archetype:generate -DarchetypeGroupId=org.apache.wicket > -DarchetypeArtifactId=wicket-archetype-quickstart -DarchetypeVersion=1.3.5 > -DgroupId=com.mycompany -DartifactId=myproject > generates the project but still produces this weird info: > [INFO] Using following parameters for creating *Old*Archetype: > wicket-archetype-quickstart:1.3.5 > I have no idea what 'OldArchetype' should means. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (WICKET-2818) Wicket site's Component reference links to comp ref 1.3 instead of 1.4
[ https://issues.apache.org/jira/browse/WICKET-2818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerolf Seitz resolved WICKET-2818. -- Resolution: Fixed I changed the link on the left side and two more links to wicketstuff.org/wicket13 and ../wicket13/compref to the respective wicket14 links. along with that, i uploaded the aggregated javadocs for the 1.4.7 and 1.3.7 releases > Wicket site's Component reference links to comp ref 1.3 instead of 1.4 > -- > > Key: WICKET-2818 > URL: https://issues.apache.org/jira/browse/WICKET-2818 > Project: Wicket > Issue Type: Improvement > Components: site >Reporter: Joseph Pachod >Assignee: Gerolf Seitz >Priority: Minor > > On http://wicket.apache.org/, the link for "Components", in the left menu > bar, leads to http://wicketstuff.org/wicket13/compref/, whereas we are on > wicket 1.4 and http://wicketstuff.org/wicket14/compref/ also exists. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (WICKET-2158) AutoComplete onfocus behavior only working on last autocomplete field
[
https://issues.apache.org/jira/browse/WICKET-2158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gerolf Seitz resolved WICKET-2158.
--
Resolution: Fixed
Fix Version/s: 1.4.0
resolving this issue as fixed, as of revision 791516 (before the 1.4.0 release)
committed by jcompagner ("forgotton declaration of var objonfocus;")
> AutoComplete onfocus behavior only working on last autocomplete field
> -
>
> Key: WICKET-2158
> URL: https://issues.apache.org/jira/browse/WICKET-2158
> Project: Wicket
> Issue Type: Bug
> Components: wicket-extensions
>Affects Versions: 1.4-RC2
>Reporter: Peter Alfred Østergaard
> Fix For: 1.4.0
>
>
> 1.4rc2 wicket-autocomplete.js have some changes in onfocus behavior that seem
> to be working only for the last autocomplete field.
> It could be cause by a global "objonfocus" in Wicket.AutoComplete
> Initialiaze. The objonfocus seems to be missing in "pointers of the browser
> events".
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-2005) pb to access to this on event onchange on the AutoCompleteTextField
[
https://issues.apache.org/jira/browse/WICKET-2005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12660909#action_12660909
]
Gerolf Seitz commented on WICKET-2005:
--
thx olivier,
unfortunately, one of my raid5 drives crashed and my computer is still
rebuilding the raid.
it takes 5-10 minutes for eclipse to just start, so i'll have to postpone this
until my computer is ready for action again.
> pb to access to this on event onchange on the AutoCompleteTextField
> ---
>
> Key: WICKET-2005
> URL: https://issues.apache.org/jira/browse/WICKET-2005
> Project: Wicket
> Issue Type: Bug
> Components: wicket-extensions
>Affects Versions: 1.4-RC1
> Environment: Windows XP, Firefox 3.0, IE7, safari 3.0
>Reporter: Olivier Dutrieux
> Attachments: screenshot-1.jpg, src.zip, wicket-autocomplete.js
>
>
> I would like create a component that extends AjaxEditableLabel with replace
> TextField with AjaxEditableAutoComplete.
> And I discovert a problem in the wicket-autocomplete.js when the event
> onchange is rewriting (line 83) :
> 83// WICKET-1280
> 84objonchangeoriginal=obj.onchange;
> 85obj.onchange=function(event){
> 86if(mouseactive==1)return false;
> 87if(typeof
> objonchangeoriginal=="function")objonchangeoriginal();
> 88}
> 89objonchange=obj.onchange;
> the problem is that the objonchangeoriginal function can't access to the this
> object, and it's necessary because I change the onchange event on
> AjaxEditableAutoComplete in case I extends AjaxEditableLabel with this :
> editor.add(new EditorAjaxBehavior() {
> private static final long serialVersionUID = 1L;
> @Override
> protected void onComponentTag(ComponentTag tag) {
> super.onComponentTag(tag);
> final String saveCall = "{wicketAjaxGet('" +
> getCallbackUrl() + "&save=true&'+this.name+'='+wicketEncode(this.value));
> return true;}";
> tag.put("onchange", saveCall);
> }
> });
> then the best way to solve the problem is to change the invocation of
> objonchangeoriginal function with that :
> 83// WICKET-1280
> 84objonchangeoriginal=obj.onchange;
> 85obj.onchange=function(event){
> 86if(mouseactive==1)return false;
> 87if(typeof
> objonchangeoriginal=="function")objonchangeoriginal.apply(this, [event]);
> 88}
> 89objonchange=obj.onchange;
> all invocation of function need to be change this with new invocation on the
> wicket-autocomplete.js file
> You find on attach file a simple example that's show the problem. And my
> version of wicket-autocomplete.js that solve the problem.
> Duto
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (WICKET-1649) Manifests use incorrect Dynamic-ImportPackage header
[ https://issues.apache.org/jira/browse/WICKET-1649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerolf Seitz resolved WICKET-1649. -- Resolution: Fixed Fix Version/s: 1.4-M2 1.3.4 fixed. thanks > Manifests use incorrect Dynamic-ImportPackage header > > > Key: WICKET-1649 > URL: https://issues.apache.org/jira/browse/WICKET-1649 > Project: Wicket > Issue Type: Bug >Reporter: Andy Wilkinson >Assignee: Gerolf Seitz > Fix For: 1.3.4, 1.4-M2 > > > The OSGi bundle manifests in the Wicket JARs are using the wrong dynamic > import package header. They currently use the header Dynamic-ImportPackage, > the header should be DynamicImport-Package. The current manifests cause a > number of classloading problems with Wicket when running in an OSGi > environment. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-1649) Manifests use incorrect Dynamic-ImportPackage header
[ https://issues.apache.org/jira/browse/WICKET-1649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerolf Seitz updated WICKET-1649: - Affects Version/s: (was: 1.4-M2) > Manifests use incorrect Dynamic-ImportPackage header > > > Key: WICKET-1649 > URL: https://issues.apache.org/jira/browse/WICKET-1649 > Project: Wicket > Issue Type: Bug >Reporter: Andy Wilkinson >Assignee: Gerolf Seitz > > The OSGi bundle manifests in the Wicket JARs are using the wrong dynamic > import package header. They currently use the header Dynamic-ImportPackage, > the header should be DynamicImport-Package. The current manifests cause a > number of classloading problems with Wicket when running in an OSGi > environment. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (WICKET-1645) Syntactic errors in the manifest OSGi headers
[ https://issues.apache.org/jira/browse/WICKET-1645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerolf Seitz resolved WICKET-1645. -- Resolution: Fixed Fix Version/s: 1.4-M2 1.3.4 the "yahoo-dom-event" folder is no longer in the Import-/Export-Package header. also see http://markmail.org/message/ghsnpspirv57vtin > Syntactic errors in the manifest OSGi headers > - > > Key: WICKET-1645 > URL: https://issues.apache.org/jira/browse/WICKET-1645 > Project: Wicket > Issue Type: Bug > Components: wicket-datetime >Affects Versions: 1.4-M2 >Reporter: Jawher Moussa >Assignee: Gerolf Seitz > Fix For: 1.3.4, 1.4-M2 > > > Hello, > Not exactly sure about the error location, but upon deployment on a OSGi > container (SpringSource Application Context, based on Equinox), I get the > following trace: > [2008-05-19 19:39:26.041] fs-watcherThe bundle > '/home/djo/Java/servers/springsource-ap-1.0.0.beta3/repository/bundles/usr/wicket-datetime-1.4-m2.jar' > could not be provisioned is its manifest is malformed. The error encountered > whilst parsing the manifest was: The manifest identified by Name 'Wicket > Date/Time', Symbolic Name 'org.apache.wicket.wicket-datetime', and Version > '1.4.0.m2' has the following errors [org.antlr.runtime.NoViableAltException > on 'Package Header [Import]' at Char: > 768,org.antlr.runtime.NoViableAltException on 'Package Header [Export]' at > Char: 101] -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-1645) Syntactic errors in the manifest OSGi headers
[ https://issues.apache.org/jira/browse/WICKET-1645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerolf Seitz updated WICKET-1645: - Fix Version/s: (was: 1.4-M2) 1.4-M3 > Syntactic errors in the manifest OSGi headers > - > > Key: WICKET-1645 > URL: https://issues.apache.org/jira/browse/WICKET-1645 > Project: Wicket > Issue Type: Bug > Components: wicket-datetime >Affects Versions: 1.4-M2 >Reporter: Jawher Moussa >Assignee: Gerolf Seitz > Fix For: 1.3.4, 1.4-M3 > > > Hello, > Not exactly sure about the error location, but upon deployment on a OSGi > container (SpringSource Application Context, based on Equinox), I get the > following trace: > [2008-05-19 19:39:26.041] fs-watcherThe bundle > '/home/djo/Java/servers/springsource-ap-1.0.0.beta3/repository/bundles/usr/wicket-datetime-1.4-m2.jar' > could not be provisioned is its manifest is malformed. The error encountered > whilst parsing the manifest was: The manifest identified by Name 'Wicket > Date/Time', Symbolic Name 'org.apache.wicket.wicket-datetime', and Version > '1.4.0.m2' has the following errors [org.antlr.runtime.NoViableAltException > on 'Package Header [Import]' at Char: > 768,org.antlr.runtime.NoViableAltException on 'Package Header [Export]' at > Char: 101] -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1645) Syntactic errors in the manifest OSGi headers
[ https://issues.apache.org/jira/browse/WICKET-1645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12598237#action_12598237 ] Gerolf Seitz commented on WICKET-1645: -- the latest snapshots can be found in our maven repository: http://wicketstuff.org/maven/repository the specific wicket-datetime.jar for 1.4-SNAPSHOT is here: http://wicketstuff.org/maven/repository/org/apache/wicket/wicket-datetime/1.4-SNAPSHOT/wicket-datetime-1.4-20080520.074737-86.jar > Syntactic errors in the manifest OSGi headers > - > > Key: WICKET-1645 > URL: https://issues.apache.org/jira/browse/WICKET-1645 > Project: Wicket > Issue Type: Bug > Components: wicket-datetime >Affects Versions: 1.4-M2 >Reporter: Jawher Moussa >Assignee: Gerolf Seitz > > Hello, > Not exactly sure about the error location, but upon deployment on a OSGi > container (SpringSource Application Context, based on Equinox), I get the > following trace: > [2008-05-19 19:39:26.041] fs-watcherThe bundle > '/home/djo/Java/servers/springsource-ap-1.0.0.beta3/repository/bundles/usr/wicket-datetime-1.4-m2.jar' > could not be provisioned is its manifest is malformed. The error encountered > whilst parsing the manifest was: The manifest identified by Name 'Wicket > Date/Time', Symbolic Name 'org.apache.wicket.wicket-datetime', and Version > '1.4.0.m2' has the following errors [org.antlr.runtime.NoViableAltException > on 'Package Header [Import]' at Char: > 768,org.antlr.runtime.NoViableAltException on 'Package Header [Export]' at > Char: 101] -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1645) Syntactic errors in the manifest OSGi headers
[ https://issues.apache.org/jira/browse/WICKET-1645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12598189#action_12598189 ] Gerolf Seitz commented on WICKET-1645: -- Jawher, could you try again with latest trunk? > Syntactic errors in the manifest OSGi headers > - > > Key: WICKET-1645 > URL: https://issues.apache.org/jira/browse/WICKET-1645 > Project: Wicket > Issue Type: Bug > Components: wicket-datetime >Affects Versions: 1.4-M2 >Reporter: Jawher Moussa >Assignee: Gerolf Seitz > > Hello, > Not exactly sure about the error location, but upon deployment on a OSGi > container (SpringSource Application Context, based on Equinox), I get the > following trace: > [2008-05-19 19:39:26.041] fs-watcherThe bundle > '/home/djo/Java/servers/springsource-ap-1.0.0.beta3/repository/bundles/usr/wicket-datetime-1.4-m2.jar' > could not be provisioned is its manifest is malformed. The error encountered > whilst parsing the manifest was: The manifest identified by Name 'Wicket > Date/Time', Symbolic Name 'org.apache.wicket.wicket-datetime', and Version > '1.4.0.m2' has the following errors [org.antlr.runtime.NoViableAltException > on 'Package Header [Import]' at Char: > 768,org.antlr.runtime.NoViableAltException on 'Package Header [Export]' at > Char: 101] -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1645) Syntactic errors in the manifest OSGi headers
[ https://issues.apache.org/jira/browse/WICKET-1645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12598101#action_12598101 ] Gerolf Seitz commented on WICKET-1645: -- i think this is because we have a folder (not package) called "yahoo-dom-event" and in the osgi manifest, this is in the import and export package header. > Syntactic errors in the manifest OSGi headers > - > > Key: WICKET-1645 > URL: https://issues.apache.org/jira/browse/WICKET-1645 > Project: Wicket > Issue Type: Bug > Components: wicket-datetime >Affects Versions: 1.4-M2 >Reporter: Jawher Moussa >Assignee: Gerolf Seitz > > Hello, > Not exactly sure about the error location, but upon deployment on a OSGi > container (SpringSource Application Context, based on Equinox), I get the > following trace: > [2008-05-19 19:39:26.041] fs-watcherThe bundle > '/home/djo/Java/servers/springsource-ap-1.0.0.beta3/repository/bundles/usr/wicket-datetime-1.4-m2.jar' > could not be provisioned is its manifest is malformed. The error encountered > whilst parsing the manifest was: The manifest identified by Name 'Wicket > Date/Time', Symbolic Name 'org.apache.wicket.wicket-datetime', and Version > '1.4.0.m2' has the following errors [org.antlr.runtime.NoViableAltException > on 'Package Header [Import]' at Char: > 768,org.antlr.runtime.NoViableAltException on 'Package Header [Export]' at > Char: 101] -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (WICKET-1428) AutoLinkResolver and Parent-Relative (../) Links
[ https://issues.apache.org/jira/browse/WICKET-1428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerolf Seitz resolved WICKET-1428. -- Resolution: Fixed Fix Version/s: 1.3.4 thanks > AutoLinkResolver and Parent-Relative (../) Links > > > Key: WICKET-1428 > URL: https://issues.apache.org/jira/browse/WICKET-1428 > Project: Wicket > Issue Type: New Feature > Components: wicket >Affects Versions: 1.3.2 >Reporter: James Carman >Assignee: Gerolf Seitz > Fix For: 1.3.4, 1.4-M3 > > Attachments: > wicket-1428-patch-with-test-cases-for-wicket-1.3.x.patch, > wicket-1428-patch-with-test-cases-for-wicket-1.4.x.patch, WICKET-1428.patch, > wicket-link-outside-of-package.zip > > > Suppose I have a package structure like this: > com.mycompany.myproject > --- module1 > --- page > - Page1.html > --- module2 > --- page > - Page2.html > If I want to autolink from Page1.html to Page2.html, it would look like: > > Click Here! > > This is not working, however. The AutoLinkResolver spits out a warning > message: > "WARN - AutoLinkResolver - Did not find corresponding java class: > .module2.page.Page2" -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (WICKET-1540) Use new URI in URLValidator
[ https://issues.apache.org/jira/browse/WICKET-1540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerolf Seitz resolved WICKET-1540. -- Resolution: Duplicate see WICKET-1539 > Use new URI in URLValidator > --- > > Key: WICKET-1540 > URL: https://issues.apache.org/jira/browse/WICKET-1540 > Project: Wicket > Issue Type: Improvement > Components: wicket >Reporter: Daniel Kaplan >Priority: Trivial > > URLValidator can use new URI(input) to validate urls. -- 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-1632) IE bug causes wicket problems when id auto generation is active
[
https://issues.apache.org/jira/browse/WICKET-1632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12597759#action_12597759
]
seitz edited comment on WICKET-1632 at 5/17/08 2:53 PM:
---
IDs are now generated with the prefix "id"
was (Author: seitz):
IDs are now genereated with the prefix "id"
> IE bug causes wicket problems when id auto generation is active
> ---
>
> Key: WICKET-1632
> URL: https://issues.apache.org/jira/browse/WICKET-1632
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Environment: Internet Explorer (Verified on version 6.0)
> Verified in wicket 1.3.3
>Reporter: Tom Desmet
>Assignee: Igor Vaynberg
> Fix For: 1.3.4
>
>
> http://www.nabble.com/IE-bug-causes-wicket-problems-when-id-auto-generation-is-active-td17231936.html
> There seems to be a bug in Internet Explorer in the following scenario ...
>
>
>
>
>
> var form = document.getElementById('ic');
> alert(form.getAttribute('id'));
>
>
>
> If an image on a form has an id that has as id content the text "id", then
> something strange happens in IE.
> You get an [object] instead of the actual id content. This can happen when
> the wicket automatic id generation is used.
> Could there be a workaround included within wicket to avoid this bug?
> (We have spent quite some time to debug this issue, so if wicket can include
> a workaround, it can save others the same debugging work)
> Thank you very much.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (WICKET-1632) IE bug causes wicket problems when id auto generation is active
[
https://issues.apache.org/jira/browse/WICKET-1632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gerolf Seitz resolved WICKET-1632.
--
Resolution: Fixed
Fix Version/s: 1.3.4
Assignee: Igor Vaynberg
IDs are now genereated with the prefix "id"
> IE bug causes wicket problems when id auto generation is active
> ---
>
> Key: WICKET-1632
> URL: https://issues.apache.org/jira/browse/WICKET-1632
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Environment: Internet Explorer (Verified on version 6.0)
> Verified in wicket 1.3.3
>Reporter: Tom Desmet
>Assignee: Igor Vaynberg
> Fix For: 1.3.4
>
>
> http://www.nabble.com/IE-bug-causes-wicket-problems-when-id-auto-generation-is-active-td17231936.html
> There seems to be a bug in Internet Explorer in the following scenario ...
>
>
>
>
>
> var form = document.getElementById('ic');
> alert(form.getAttribute('id'));
>
>
>
> If an image on a form has an id that has as id content the text "id", then
> something strange happens in IE.
> You get an [object] instead of the actual id content. This can happen when
> the wicket automatic id generation is used.
> Could there be a workaround included within wicket to avoid this bug?
> (We have spent quite some time to debug this issue, so if wicket can include
> a workaround, it can save others the same debugging work)
> Thank you very much.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-1541) PopupSettings' windowName fixes for IE
[
https://issues.apache.org/jira/browse/WICKET-1541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gerolf Seitz updated WICKET-1541:
-
Fix Version/s: 1.4-M2
1.3.4
Assignee: Gerolf Seitz
Issue Type: Bug (was: Improvement)
Affects Version/s: (was: 1.3.2)
1.3.3
1.4-M1
> PopupSettings' windowName fixes for IE
> --
>
> Key: WICKET-1541
> URL: https://issues.apache.org/jira/browse/WICKET-1541
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.3.3, 1.4-M1
> Environment: Internet Explorer 6/7
>Reporter: Martin Grigorov
>Assignee: Gerolf Seitz
>Priority: Trivial
> Fix For: 1.3.4, 1.4-M2
>
> Attachments: popups.tgz
>
>
> In o.a.w.markup.html.link.PopupSettings.java there is a fix for IE at line
> 177:
> // Fix for IE bug.
> windowTitle = windowTitle.replace(':', '_');
> This fix should either be improved/extended or it would be good if the
> javadocs for 'pageMap' state that IE supports only alphanumeric characters
> and underscore in the windowTitle.
> Attached quickstart shows the problem in IE: a pageMap/windowTitle with a
> dash leads to "Illegal argument" JavaScript error.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (WICKET-1541) PopupSettings' windowName fixes for IE
[
https://issues.apache.org/jira/browse/WICKET-1541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gerolf Seitz resolved WICKET-1541.
--
Resolution: Fixed
from now on, all non-word characters [^0-9A-Za-z_] in the window title will be
replaced with the underscore character '_'
> PopupSettings' windowName fixes for IE
> --
>
> Key: WICKET-1541
> URL: https://issues.apache.org/jira/browse/WICKET-1541
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.3.3, 1.4-M1
> Environment: Internet Explorer 6/7
>Reporter: Martin Grigorov
>Assignee: Gerolf Seitz
>Priority: Trivial
> Fix For: 1.3.4, 1.4-M2
>
> Attachments: popups.tgz
>
>
> In o.a.w.markup.html.link.PopupSettings.java there is a fix for IE at line
> 177:
> // Fix for IE bug.
> windowTitle = windowTitle.replace(':', '_');
> This fix should either be improved/extended or it would be good if the
> javadocs for 'pageMap' state that IE supports only alphanumeric characters
> and underscore in the windowTitle.
> Attached quickstart shows the problem in IE: a pageMap/windowTitle with a
> dash leads to "Illegal argument" JavaScript error.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (WICKET-1639) Popup Settings Link JavaScript Error
[
https://issues.apache.org/jira/browse/WICKET-1639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gerolf Seitz resolved WICKET-1639.
--
Resolution: Duplicate
see WICKET-1541
> Popup Settings Link JavaScript Error
>
>
> Key: WICKET-1639
> URL: https://issues.apache.org/jira/browse/WICKET-1639
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.3.2
> Environment: Windows XP Professional SP2, Tomcat 6.0, Enternet
> Explorer 7.0, Wicket 1.3.2
>Reporter: fallout
>Assignee: Gerolf Seitz
>Priority: Trivial
>
> I have a JavaScript error message in the left bottom corner of a IE' parent
> window when I click a PopupSettings link.
> Code for this PopupSettings link is:
> final Link viewGroupProfileUsersLink = new Link("numberOfUsersLink") {
> @Override
> public void onClick()
> {
>setResponsePage(new GroupProfileUserList(groupProfile));
> }
> };
>
> PopupSettings popupSettings = new
> PopupSettings(PopupSettings.SCROLLBARS);
>
> popupSettings.setWidth(Integer.valueOf(getString("popup.window.width")));
>
> popupSettings.setHeight(Integer.valueOf(getString("popup.window.height")));
> popupSettings.setWindowName(groupProfile.getName());
>
> viewGroupProfileUsersLink.setPopupSettings(popupSettings);
> item.add(viewGroupProfileUsersLink);
> The JavaScript error message is: 'Invalid argument'.
> Is it a wicket problem or I am doing something wrong.
> Thank you.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (WICKET-1560) MarkupFragmentFinder fails on transparent resolvers within Repeaters
[
https://issues.apache.org/jira/browse/WICKET-1560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gerolf Seitz resolved WICKET-1560.
--
Resolution: Fixed
Fix Version/s: 1.4-M2
Assignee: Gerolf Seitz
see thread: http://markmail.org/message/4yvcnp5xrmngd7c2
> MarkupFragmentFinder fails on transparent resolvers within Repeaters
>
>
> Key: WICKET-1560
> URL: https://issues.apache.org/jira/browse/WICKET-1560
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.3.3, 1.4-M1
> Environment: Any
>Reporter: Jan Kriesten
>Assignee: Gerolf Seitz
>Priority: Critical
> Fix For: 1.3.4, 1.4-M2
>
>
> I extended the AjaxDataTable to be able to add Rows to certain states of the
> rows. However, MarkupFragmentFinder fails to resolve the code under this
> condition since it compares with the wrong components in this case:
> Markup:
>
>wicket:id="cell">[cell]
>
>
> 'row' is the transparent resolver in this case to maintain the hierarchy
> needed by the DataTable. MarkupFragmentFinder fails in the case of adding a
> cell to an AjaxRequestTarget.
> Fix:
> Everything works as expected, when MarkupFragmentFinder checks for the parent
> being an AbstractRepeater and in the case compares the parent.id with the
> supplied id (code provided by Gerolf):
> if (elem instanceof ComponentTag)
> {
> ComponentTag tag = (ComponentTag)elem;
> String id = tag.getId();
> if ((id != null) && id.equals(component.getId()))
> {
> // Ok, found it
> return markupStream;
> }
> else
> {
> Component parent = component.getParent();
> if (parent instanceof AbstractRepeater && id != null &&
> id.equals(parent.getId()))
> {
> return markupStream;
> }
> }
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-1560) MarkupFragmentFinder fails on transparent resolvers within Repeaters
[
https://issues.apache.org/jira/browse/WICKET-1560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gerolf Seitz updated WICKET-1560:
-
Affects Version/s: 1.4-M1
> MarkupFragmentFinder fails on transparent resolvers within Repeaters
>
>
> Key: WICKET-1560
> URL: https://issues.apache.org/jira/browse/WICKET-1560
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.3.3, 1.4-M1
> Environment: Any
>Reporter: Jan Kriesten
>Assignee: Gerolf Seitz
>Priority: Critical
> Fix For: 1.3.4, 1.4-M2
>
>
> I extended the AjaxDataTable to be able to add Rows to certain states of the
> rows. However, MarkupFragmentFinder fails to resolve the code under this
> condition since it compares with the wrong components in this case:
> Markup:
>
>wicket:id="cell">[cell]
>
>
> 'row' is the transparent resolver in this case to maintain the hierarchy
> needed by the DataTable. MarkupFragmentFinder fails in the case of adding a
> cell to an AjaxRequestTarget.
> Fix:
> Everything works as expected, when MarkupFragmentFinder checks for the parent
> being an AbstractRepeater and in the case compares the parent.id with the
> supplied id (code provided by Gerolf):
> if (elem instanceof ComponentTag)
> {
> ComponentTag tag = (ComponentTag)elem;
> String id = tag.getId();
> if ((id != null) && id.equals(component.getId()))
> {
> // Ok, found it
> return markupStream;
> }
> else
> {
> Component parent = component.getParent();
> if (parent instanceof AbstractRepeater && id != null &&
> id.equals(parent.getId()))
> {
> return markupStream;
> }
> }
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-1641) provide OSGi metadata
[ https://issues.apache.org/jira/browse/WICKET-1641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerolf Seitz updated WICKET-1641: - Fix Version/s: 1.4-M2 1.3.4 Affects Version/s: 1.3.3 > provide OSGi metadata > - > > Key: WICKET-1641 > URL: https://issues.apache.org/jira/browse/WICKET-1641 > Project: Wicket > Issue Type: New Feature > Components: wicket, wicket-auth-roles, wicket-datetime, > wicket-examples, wicket-extensions, wicket-guice, wicket-jmx, wicket-portlet, > wicket-quickstart, wicket-spring >Affects Versions: 1.3.3, 1.4-M1 >Reporter: Gerolf Seitz >Assignee: Gerolf Seitz >Priority: Minor > Fix For: 1.3.4, 1.4-M2 > > Attachments: Wicket_OSGi_Patch.txt > > > since OSGi is pretty hyped lately, it would be good to provide OSGi metadata > in our releases. > we could/should use the maven-bundle-plugin for that. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (WICKET-1641) provide OSGi metadata
[ https://issues.apache.org/jira/browse/WICKET-1641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerolf Seitz resolved WICKET-1641. -- Resolution: Fixed again, thanks for the patch, Stuart > provide OSGi metadata > - > > Key: WICKET-1641 > URL: https://issues.apache.org/jira/browse/WICKET-1641 > Project: Wicket > Issue Type: New Feature > Components: wicket, wicket-auth-roles, wicket-datetime, > wicket-examples, wicket-extensions, wicket-guice, wicket-jmx, wicket-portlet, > wicket-quickstart, wicket-spring >Affects Versions: 1.3.3, 1.4-M1 >Reporter: Gerolf Seitz >Assignee: Gerolf Seitz >Priority: Minor > Fix For: 1.3.4, 1.4-M2 > > Attachments: Wicket_OSGi_Patch.txt > > > since OSGi is pretty hyped lately, it would be good to provide OSGi metadata > in our releases. > we could/should use the maven-bundle-plugin for that. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-1641) provide OSGi metadata
[ https://issues.apache.org/jira/browse/WICKET-1641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerolf Seitz updated WICKET-1641: - Attachment: Wicket_OSGi_Patch.txt patch provided by Stuart McCulloch on [EMAIL PROTECTED] also see thread: http://markmail.org/message/xecwwcybavldwyse > provide OSGi metadata > - > > Key: WICKET-1641 > URL: https://issues.apache.org/jira/browse/WICKET-1641 > Project: Wicket > Issue Type: New Feature > Components: wicket, wicket-auth-roles, wicket-datetime, > wicket-examples, wicket-extensions, wicket-guice, wicket-jmx, wicket-portlet, > wicket-quickstart, wicket-spring >Affects Versions: 1.4-M1 >Reporter: Gerolf Seitz >Assignee: Gerolf Seitz >Priority: Minor > Attachments: Wicket_OSGi_Patch.txt > > > since OSGi is pretty hyped lately, it would be good to provide OSGi metadata > in our releases. > we could/should use the maven-bundle-plugin for that. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-1641) provide OSGi metadata
provide OSGi metadata - Key: WICKET-1641 URL: https://issues.apache.org/jira/browse/WICKET-1641 Project: Wicket Issue Type: New Feature Components: wicket, wicket-auth-roles, wicket-datetime, wicket-examples, wicket-extensions, wicket-guice, wicket-jmx, wicket-portlet, wicket-quickstart, wicket-spring Affects Versions: 1.4-M1 Reporter: Gerolf Seitz Assignee: Gerolf Seitz Priority: Minor since OSGi is pretty hyped lately, it would be good to provide OSGi metadata in our releases. we could/should use the maven-bundle-plugin for that. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1639) Popup Settings Link JavaScript Error
[
https://issues.apache.org/jira/browse/WICKET-1639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12597659#action_12597659
]
Gerolf Seitz commented on WICKET-1639:
--
i tried to reproduce it with the code you provided, but it didn't fail.
can you provide a quickstart that reproduces the error?
> Popup Settings Link JavaScript Error
>
>
> Key: WICKET-1639
> URL: https://issues.apache.org/jira/browse/WICKET-1639
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.3.2
> Environment: Windows XP Professional SP2, Tomcat 6.0, Enternet
> Explorer 7.0, Wicket 1.3.2
>Reporter: fallout
>Assignee: Gerolf Seitz
>Priority: Trivial
>
> I have a JavaScript error message in the left bottom corner of a IE' parent
> window when I click a PopupSettings link.
> Code for this PopupSettings link is:
> final Link viewGroupProfileUsersLink = new Link("numberOfUsersLink") {
> @Override
> public void onClick()
> {
>setResponsePage(new GroupProfileUserList(groupProfile));
> }
> };
>
> PopupSettings popupSettings = new
> PopupSettings(PopupSettings.SCROLLBARS);
>
> popupSettings.setWidth(Integer.valueOf(getString("popup.window.width")));
>
> popupSettings.setHeight(Integer.valueOf(getString("popup.window.height")));
> popupSettings.setWindowName(groupProfile.getName());
>
> viewGroupProfileUsersLink.setPopupSettings(popupSettings);
> item.add(viewGroupProfileUsersLink);
> The JavaScript error message is: 'Invalid argument'.
> Is it a wicket problem or I am doing something wrong.
> Thank you.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1639) Popup Settings Link JavaScript Error
[
https://issues.apache.org/jira/browse/WICKET-1639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12597651#action_12597651
]
Gerolf Seitz commented on WICKET-1639:
--
can you please try it with the latest 1.3 release: 1.3.3?
> Popup Settings Link JavaScript Error
>
>
> Key: WICKET-1639
> URL: https://issues.apache.org/jira/browse/WICKET-1639
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.3.2
> Environment: Windows XP Professional SP2, Tomcat 6.0, Enternet
> Explorer 7.0, Wicket 1.3.2
>Reporter: fallout
>Assignee: Gerolf Seitz
>Priority: Trivial
>
> I have a JavaScript error message in the left bottom corner of a IE' parent
> window when I click a PopupSettings link.
> Code for this PopupSettings link is:
> final Link viewGroupProfileUsersLink = new Link("numberOfUsersLink") {
> @Override
> public void onClick()
> {
>setResponsePage(new GroupProfileUserList(groupProfile));
> }
> };
>
> PopupSettings popupSettings = new
> PopupSettings(PopupSettings.SCROLLBARS);
>
> popupSettings.setWidth(Integer.valueOf(getString("popup.window.width")));
>
> popupSettings.setHeight(Integer.valueOf(getString("popup.window.height")));
> popupSettings.setWindowName(groupProfile.getName());
>
> viewGroupProfileUsersLink.setPopupSettings(popupSettings);
> item.add(viewGroupProfileUsersLink);
> The JavaScript error message is: 'Invalid argument'.
> Is it a wicket problem or I am doing something wrong.
> Thank you.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1324) AutoCompleteTextField does not return the pojo which was selected by the user
[ https://issues.apache.org/jira/browse/WICKET-1324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12596900#action_12596900 ] Gerolf Seitz commented on WICKET-1324: -- just saw an interesting (maybe annoying) feature of a jquery autocomplete. http://jquery.bassistance.de/autocomplete/demo/ try the one with "Multiple Cities". if a string is entered where there is no match, the textbox is cleared. > AutoCompleteTextField does not return the pojo which was selected by the user > - > > Key: WICKET-1324 > URL: https://issues.apache.org/jira/browse/WICKET-1324 > Project: Wicket > Issue Type: Improvement > Components: wicket-extensions >Affects Versions: 1.3.0-final > Environment: any >Reporter: Sam Barnum >Assignee: Igor Vaynberg > > getModelObject() returns the selected > String, not the POJO object which the string is rendered from. I've gotten > around this by saving the last query string sent > via AJAX. When the user makes a selection, I iterate over the > options for that query string one more time, and take the POJO whose > rendered string matches the user-selected text. > getModelObject() should probably return the java object. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1605) onclick is null or not an object in IE6, IE7; Form.appendDefaultButtonField
[
https://issues.apache.org/jira/browse/WICKET-1605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12596214#action_12596214
]
Gerolf Seitz commented on WICKET-1605:
--
Martin, I tried a couple of settings but somehow i could not reproduce the
error.
can you provide a quickstart for this? thx.
> onclick is null or not an object in IE6, IE7; Form.appendDefaultButtonField
> ---
>
> Key: WICKET-1605
> URL: https://issues.apache.org/jira/browse/WICKET-1605
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.3.3, 1.4-M1
> Environment: Windows XP Professional, glassfish, Internet Explorer 6
> and Internet Explorer 7
>Reporter: Martin Müller
>Assignee: Gerolf Seitz
>Priority: Minor
> Original Estimate: 0.25h
> Remaining Estimate: 0.25h
>
> JavaScript error when radio button has focus and return key is pressed:
> IE6 and IE7 report a script error ("'onclick' is null or not an object"),
> which IMHO may be fixed in method
> - protected void
> org.apache.wicket.markup.html.form.Form.appendDefaultButtonField(final
> MarkupStream markupStream, final ComponentTag openTag)
> on line:
> buffer.append("'); if (typeof(b.onclick) != 'undefined') { var r =
> b.onclick.bind(b)(); if (r != false) b.click(); } else { b.click(); };
> return false;\" ");
> It works for me replacing this line by:
> buffer.append("'); if ((b.onclick != null) && (typeof(b.onclick) !=
> 'undefined')) { var r = b.onclick.bind(b)(); if (r != false) b.click(); }
> else { b.click(); }; return false;\" ");
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1605) onclick is null or not an object in IE6, IE7; Form.appendDefaultButtonField
[
https://issues.apache.org/jira/browse/WICKET-1605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12595943#action_12595943
]
Gerolf Seitz commented on WICKET-1605:
--
the generated javascript in appendDefaultButtonField depends on wicket-ajax,
but does not automatically include it in the page.
also, the defaultSubmittingComponent has to call setOutputMarkupId(true) to
make it work. this is not documented and imho implementation detail.
what should we do about those issues?
1) wicket-ajax.js dependency:
Wicket.$ -> document.getElementById
.bind -> yet another definition of the bind method? :/
2) automatically call setOutputMarkupId(true) for the
defaultSubmittingComponent in the method setDefaultSubmittingComponent
wdyt?
> onclick is null or not an object in IE6, IE7; Form.appendDefaultButtonField
> ---
>
> Key: WICKET-1605
> URL: https://issues.apache.org/jira/browse/WICKET-1605
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.3.3, 1.4-M1
> Environment: Windows XP Professional, glassfish, Internet Explorer 6
> and Internet Explorer 7
>Reporter: Martin Müller
>Assignee: Gerolf Seitz
>Priority: Minor
> Original Estimate: 0.25h
> Remaining Estimate: 0.25h
>
> JavaScript error when radio button has focus and return key is pressed:
> IE6 and IE7 report a script error ("'onclick' is null or not an object"),
> which IMHO may be fixed in method
> - protected void
> org.apache.wicket.markup.html.form.Form.appendDefaultButtonField(final
> MarkupStream markupStream, final ComponentTag openTag)
> on line:
> buffer.append("'); if (typeof(b.onclick) != 'undefined') { var r =
> b.onclick.bind(b)(); if (r != false) b.click(); } else { b.click(); };
> return false;\" ");
> It works for me replacing this line by:
> buffer.append("'); if ((b.onclick != null) && (typeof(b.onclick) !=
> 'undefined')) { var r = b.onclick.bind(b)(); if (r != false) b.click(); }
> else { b.click(); }; return false;\" ");
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (WICKET-1608) make AutoCompleteBehavior's configuration more flexible
[ https://issues.apache.org/jira/browse/WICKET-1608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerolf Seitz resolved WICKET-1608. -- Resolution: Fixed i deprecated constructors of AutoCompleteTextField with the preselect parameter in 1.4.x > make AutoCompleteBehavior's configuration more flexible > --- > > Key: WICKET-1608 > URL: https://issues.apache.org/jira/browse/WICKET-1608 > Project: Wicket > Issue Type: Improvement > Components: wicket-extensions >Affects Versions: 1.3.3, 1.4-M1 >Reporter: Gerolf Seitz >Assignee: Gerolf Seitz >Priority: Minor > Fix For: 1.3.4, 1.4-M2 > > > add AutoCompleteSettings which encapsulates all needed configuration options, > so we don't need hundreds of constructors just to have every combination of > configuration options available. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (WICKET-1595) AutoCompleteTextField: Scrolling down the Choice Menu Only When the Bottom of the Menu Is Reached
[
https://issues.apache.org/jira/browse/WICKET-1595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gerolf Seitz resolved WICKET-1595.
--
Resolution: Fixed
Fix Version/s: 1.4-M2
1.3.4
Assignee: Gerolf Seitz
fixed. use an AutoCompleteTextField constructor with an AutoCompleteSettings
parameter to also set the maximum height of the autocomplete list
> AutoCompleteTextField: Scrolling down the Choice Menu Only When the Bottom of
> the Menu Is Reached
> -
>
> Key: WICKET-1595
> URL: https://issues.apache.org/jira/browse/WICKET-1595
> Project: Wicket
> Issue Type: Improvement
> Components: wicket-extensions
>Affects Versions: 1.3.3
>Reporter: Andy Chu
>Assignee: Gerolf Seitz
> Fix For: 1.3.4, 1.4-M2
>
>
> Currently, the AutoCompleteTextField will scroll the selected item to the top
> of the choice menu by the following code in the render method:
> if(selected==i) {
> classNames.push('selected');
> node.scrollIntoView(true);
> }
> However, I think it should be more user-friendly if the choice menu is only
> scrolled down for *one-item* when the bottom of the current menu is reached.
> Please refer to:
> http://www.dhtmlgoodies.com/scripts/ajax-dynamic-list/ajax-dynamic-list.html.
> This can be implemented by the following modification:
> if(selected==i) {
> classNames.push('selected');
> if (node.offsetTop >= element.offsetHeight) {
> element.scrollTop = node.offsetTop -
> element.offsetHeight + node.offsetHeight + 2 ;
> }
> if (node.offsetTop < element.offsetHeight) {
> element.scrollTop = 0;
> }
> }
> }
> Hope this feature can be added.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1608) make AutoCompleteBehavior's configuration more flexible
[ https://issues.apache.org/jira/browse/WICKET-1608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12595756#action_12595756 ] Gerolf Seitz commented on WICKET-1608: -- now that we have AutoCompleteSettings, how about deprecating all AutoCompleteTextField constructors with a "boolean preselect" parameter? is this also okay for 1.3.4? wdyt? > make AutoCompleteBehavior's configuration more flexible > --- > > Key: WICKET-1608 > URL: https://issues.apache.org/jira/browse/WICKET-1608 > Project: Wicket > Issue Type: Improvement > Components: wicket-extensions >Affects Versions: 1.3.3, 1.4-M1 >Reporter: Gerolf Seitz >Assignee: Gerolf Seitz >Priority: Minor > Fix For: 1.3.4, 1.4-M2 > > > add AutoCompleteSettings which encapsulates all needed configuration options, > so we don't need hundreds of constructors just to have every combination of > configuration options available. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (WICKET-1562) Autocomplete should display the selection list even if the input field is empty
[ https://issues.apache.org/jira/browse/WICKET-1562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerolf Seitz resolved WICKET-1562. -- Resolution: Fixed Fix Version/s: 1.4-M2 1.3.4 fixed. use an AutoCompleteTextField constructor with an AutoCompleteSettings parameter > Autocomplete should display the selection list even if the input field is > empty > --- > > Key: WICKET-1562 > URL: https://issues.apache.org/jira/browse/WICKET-1562 > Project: Wicket > Issue Type: Wish > Components: wicket-extensions >Reporter: Gabriel Erzse >Assignee: Gerolf Seitz > Fix For: 1.3.4, 1.4-M2 > > > If you use autocomplete on a text field, when the input field is empty, the > selection list is never displayed. However one could send a non-empty list of > values when the input field is empty. For example one could send the complete > list with all possible values. Later, as the user starts typing in the field, > the list would get narrowed down. > So it would be nice if the selection list is displayed even if the input > field is empty. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-1608) make AutoCompleteBehavior's configuration more flexible
make AutoCompleteBehavior's configuration more flexible --- Key: WICKET-1608 URL: https://issues.apache.org/jira/browse/WICKET-1608 Project: Wicket Issue Type: Improvement Components: wicket-extensions Affects Versions: 1.4-M1, 1.3.3 Reporter: Gerolf Seitz Assignee: Gerolf Seitz Priority: Minor Fix For: 1.3.4, 1.4-M2 add AutoCompleteSettings which encapsulates all needed configuration options, so we don't need hundreds of constructors just to have every combination of configuration options available. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (WICKET-1604) Autocomplete component scrolls page to bottom when any item is selected
[ https://issues.apache.org/jira/browse/WICKET-1604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerolf Seitz resolved WICKET-1604. -- Resolution: Duplicate Fix Version/s: (was: 1.3.4) see WICKET-1595 for 1.3.4 and 1.4-M2 > Autocomplete component scrolls page to bottom when any item is selected > --- > > Key: WICKET-1604 > URL: https://issues.apache.org/jira/browse/WICKET-1604 > Project: Wicket > Issue Type: Bug > Components: wicket-extensions >Affects Versions: 1.3.3 > Environment: Kubuntu + Firefox, but I also test it in Windows Vista >Reporter: Lluis Turro >Priority: Critical > > This happens only when web page height is bigger than screen height. When > typing into the input field everything works properly, choices are shown > smoothly and page does not scroll. Now, if you try selecting a choice by > pressing KEY DOWN or move the mouse pointer to the drop down list, the page > scrolls up. > This sudden page movement is annoying and makes autocomplete component > completely unusable for large pages. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1329) AutoCompleteTextField's suggestion list *disappeared* when it is used inside a ModalWindow
[ https://issues.apache.org/jira/browse/WICKET-1329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12595358#action_12595358 ] Gerolf Seitz commented on WICKET-1329: -- Erik, why do you think so? afaik, the z-index is independent from the position. so we need both fixes. > AutoCompleteTextField's suggestion list *disappeared* when it is used inside > a ModalWindow > -- > > Key: WICKET-1329 > URL: https://issues.apache.org/jira/browse/WICKET-1329 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.3.0-final >Reporter: Andy Chu >Assignee: Gerolf Seitz > Fix For: 1.3.3 > > > When an AutoCompleteTextField is used in panel showed inside a ModalWindow, > the dropdown list for suggestions will be disappeared. The reason is that the > z-index of a normal ModalWindow is 2 while the z-index of the dropdown > list is 1. And there is no way to set this parameter programatically. > Therefore, the dropdown list is masked by the ModalWindow. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (WICKET-1594) AutoCompleteTextField Throwing Out a TypeError in IE6/IE7
[ https://issues.apache.org/jira/browse/WICKET-1594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerolf Seitz resolved WICKET-1594. -- Resolution: Duplicate see WICKET-1504, fixed in 1.3.4 adn 1.4-M1 > AutoCompleteTextField Throwing Out a TypeError in IE6/IE7 > - > > Key: WICKET-1594 > URL: https://issues.apache.org/jira/browse/WICKET-1594 > Project: Wicket > Issue Type: Bug > Components: wicket-extensions >Affects Versions: 1.3.3 > Environment: IE6/IE7 >Reporter: Andy Chu > > Wicket 1.3.3. fixed many bugs of AutoCompleteTextField. However, it may > induce some new problems: > I create a very simple page only containing an AutoCompleteTextField and > visit the page using IE6/IE7/FF. I found that IE will prompt me a javascript > TypeError but FF doesn't . > The TypeError is thrown by the following statement in the showAutoComplete > method when zIndex is assigned to "auto": > menu.style.zIndex = index=="auto"?index:Number(index)+1; > I guess IE may not allow us to assign "auto" to zIndex but in FF. However if > I change the statement into the following one, everything works fine. > menu.style.zIndex = index=="auto"?0:Number(index)+1; > Because I do not completely understand wicket-autocomplete.js, I can not > make sure if this modification will bring up another bug. Hope can get the > answer from here. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (WICKET-1590) AjaxEditableChoiceLabel ignores ChoiceRenderer in newLabel(...)
[ https://issues.apache.org/jira/browse/WICKET-1590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerolf Seitz resolved WICKET-1590. -- Resolution: Fixed Fix Version/s: (was: 1.3.3) (was: 1.4-M1) 1.4-M2 1.3.4 Assignee: Gerolf Seitz i ended up wrapping the model parameter in an AbstractReadOnlyModel which uses the renderer if available > AjaxEditableChoiceLabel ignores ChoiceRenderer in newLabel(...) > --- > > Key: WICKET-1590 > URL: https://issues.apache.org/jira/browse/WICKET-1590 > Project: Wicket > Issue Type: Improvement > Components: wicket-extensions >Affects Versions: 1.3.3, 1.4-M1 >Reporter: Alexander Keul >Assignee: Gerolf Seitz >Priority: Minor > Fix For: 1.3.4, 1.4-M2 > > Attachments: patch-1.3.x.txt, patch.txt > > > AjaxEditableChoiceLabel doesn't take any ChoiceRenderer passed in the > constructor into account when creating the Label. I believe it defaults to > the toString() of the modelObject, which isn't exactly optimal. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (WICKET-1588) Generics for Quickstart archetype
[ https://issues.apache.org/jira/browse/WICKET-1588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerolf Seitz resolved WICKET-1588. -- Resolution: Fixed Fix Version/s: 1.4-M2 Assignee: Gerolf Seitz thanks > Generics for Quickstart archetype > - > > Key: WICKET-1588 > URL: https://issues.apache.org/jira/browse/WICKET-1588 > Project: Wicket > Issue Type: Improvement > Components: wicket-quickstart >Affects Versions: 1.4-M1 > Environment: Any >Reporter: Martin Grigorov >Assignee: Gerolf Seitz >Priority: Trivial > Fix For: 1.4-M2 > > Attachments: wicket-1588.patch > > > JDK5+ goodies for wicket-archetype-quickstart skeleton classes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (WICKET-1571) Add a simple boolean datepicker.contributeDependencies() that a user can then override and return false.
[ https://issues.apache.org/jira/browse/WICKET-1571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerolf Seitz reassigned WICKET-1571: Assignee: Gerolf Seitz > Add a simple boolean datepicker.contributeDependencies() that a user can then > override and return false. > > > Key: WICKET-1571 > URL: https://issues.apache.org/jira/browse/WICKET-1571 > Project: Wicket > Issue Type: Improvement > Components: wicket-datetime >Reporter: Vitaly Tsaplin >Assignee: Gerolf Seitz >Priority: Minor > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1561) Quickstart Build Failure: "No mojo descriptors found in plugin"
[ https://issues.apache.org/jira/browse/WICKET-1561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12591644#action_12591644 ] Gerolf Seitz commented on WICKET-1561: -- i don't see it in our parent pom.xml which version should we lock down? > Quickstart Build Failure: "No mojo descriptors found in plugin" > --- > > Key: WICKET-1561 > URL: https://issues.apache.org/jira/browse/WICKET-1561 > Project: Wicket > Issue Type: Bug > Components: wicket-quickstart >Affects Versions: 1.4-M1 > Environment: Maven version: 2.0.8 > Java version: 1.5.0_14 > OS name: "windows vista" version: "6.0" arch: "x86" Family: "windows" >Reporter: James Carman > Attachments: archetype-patch.patch > > > The artifact type should be changed to "maven-archetype" to fix this issue > (patch attached). See: > http://jira.codehaus.org/browse/MPLUGIN-102 > Here's my build output: > [INFO] Scanning for projects... > [INFO] > > [INFO] Building Wicket Quickstart Archetype > [INFO]task-segment: [install] > [INFO] > > [INFO] [plugin:descriptor] > [INFO] Using 2 extractors. > [INFO] Applying extractor for language: java > [INFO] Extractor for language: java found 0 mojo descriptors. > [INFO] Applying extractor for language: bsh > [INFO] Extractor for language: bsh found 0 mojo descriptors. > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Error extracting plugin descriptor: 'No mojo descriptors found in > plugin. > ' > [INFO] > > [INFO] For more information, run Maven with the -e switch > [INFO] > > [INFO] Total time: 2 seconds > [INFO] Finished at: Wed Apr 23 07:51:19 EDT 2008 > [INFO] Final Memory: 9M/18M > [INFO] > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1561) Quickstart Build Failure: "No mojo descriptors found in plugin"
[ https://issues.apache.org/jira/browse/WICKET-1561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12591623#action_12591623 ] Gerolf Seitz commented on WICKET-1561: -- well, i can't even do "mvn install" for the archetype: [INFO] Scanning for projects... [INFO] [INFO] Building Wicket Quickstart Archetype [INFO]task-segment: [install] [INFO] [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Cannot find lifecycle mapping for packaging: 'maven-archetype'. Component descriptor cannot be found in the component repository: org.apache.maven.lifecycle.mapping.LifecycleMappingmaven-archetype. [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: < 1 second [INFO] Finished at: Wed Apr 23 14:15:45 CEST 2008 [INFO] Final Memory: 1M/4M [INFO] do i have to update some maven plugins for this to work (or clean my local repo)? when it is set to "maven-plugin", it does work. > Quickstart Build Failure: "No mojo descriptors found in plugin" > --- > > Key: WICKET-1561 > URL: https://issues.apache.org/jira/browse/WICKET-1561 > Project: Wicket > Issue Type: Bug > Components: wicket-quickstart >Affects Versions: 1.4-M1 > Environment: Maven version: 2.0.8 > Java version: 1.5.0_14 > OS name: "windows vista" version: "6.0" arch: "x86" Family: "windows" >Reporter: James Carman > Attachments: archetype-patch.patch > > > The artifact type should be changed to "maven-archetype" to fix this issue > (patch attached). See: > http://jira.codehaus.org/browse/MPLUGIN-102 > Here's my build output: > [INFO] Scanning for projects... > [INFO] > > [INFO] Building Wicket Quickstart Archetype > [INFO]task-segment: [install] > [INFO] > > [INFO] [plugin:descriptor] > [INFO] Using 2 extractors. > [INFO] Applying extractor for language: java > [INFO] Extractor for language: java found 0 mojo descriptors. > [INFO] Applying extractor for language: bsh > [INFO] Extractor for language: bsh found 0 mojo descriptors. > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Error extracting plugin descriptor: 'No mojo descriptors found in > plugin. > ' > [INFO] > > [INFO] For more information, run Maven with the -e switch > [INFO] > > [INFO] Total time: 2 seconds > [INFO] Finished at: Wed Apr 23 07:51:19 EDT 2008 > [INFO] Final Memory: 9M/18M > [INFO] > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-1175) IDataProvider-Overflow with size()
[ https://issues.apache.org/jira/browse/WICKET-1175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerolf Seitz updated WICKET-1175: - Fix Version/s: (was: 1.4-M2) 1.5-M1 > IDataProvider-Overflow with size() > -- > > Key: WICKET-1175 > URL: https://issues.apache.org/jira/browse/WICKET-1175 > Project: Wicket > Issue Type: Improvement > Components: wicket >Affects Versions: 1.3.0-rc1 > Environment: any >Reporter: Jan Kriesten >Assignee: Igor Vaynberg > Fix For: 1.5-M1 > > > Hi, > I get an Integer-overflow with my Dataprovider (yeah, there are a couple of > entries in the database). Is there a reason why size() and iterator( first, > count ) are limited to Integer? > Regards, --- Jan. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1497) viewport height not correctly calculated on IE7
[ https://issues.apache.org/jira/browse/WICKET-1497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12588844#action_12588844 ] Gerolf Seitz commented on WICKET-1497: -- can you describe what you do to get the popup to be positioned incorrectly? i can't seem to get WicketDateTime.getViewportHeight() to return 'undefined'. also, the changelogs of YAHOO.util.Dom don't mentioned that getViewportHeight was fixed. > viewport height not correctly calculated on IE7 > --- > > Key: WICKET-1497 > URL: https://issues.apache.org/jira/browse/WICKET-1497 > Project: Wicket > Issue Type: Bug > Components: wicket-datetime >Affects Versions: 1.3.3 >Reporter: Arnout Engelen > > I noticed the vertical positioning of the popup isn't corrected properly > under IE7. > Digging in the code, I found that Wicket.DateTime.getViewportHeight() returns > 'undefined' under IE7. This is a hack to work around an old problem in the > standard YAHOO.util.Dom.getViewportHeight();. > It seems the hack is now broken, and the standard > YAHOO.util.Dom.getViewportHeight(); has since been fixed: after replacing > Wicket.DateTime.getViewportHeight() with YAHOO.util.Dom.getViewportHeight(); > it now works fine under both IE and FF again. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (WICKET-1504) AutoCompleteTextField - javascript error "type mismatch" in line 227 in IE
[ https://issues.apache.org/jira/browse/WICKET-1504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerolf Seitz resolved WICKET-1504. -- Resolution: Fixed Fix Version/s: 1.4-M1 1.3.4 fixed > AutoCompleteTextField - javascript error "type mismatch" in line 227 in IE > -- > > Key: WICKET-1504 > URL: https://issues.apache.org/jira/browse/WICKET-1504 > Project: Wicket > Issue Type: Bug > Components: wicket-extensions >Affects Versions: 1.3.3 > Environment: IE 6.0 >Reporter: Niels Bo >Assignee: Gerolf Seitz > Fix For: 1.3.4, 1.4-M1 > > > I just swithed from 1.3.2 to 1.3.3 and that resultet in a javascript error > "type mismatch" in line 227, > wich is this line in wicket-autocomplete.js: > menu.style.zIndex=index=="auto"?index:Number(index)+1; > Only in IE (6.0) - firefox 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-1519) wicket:component : header-contributions don't work atm
[ https://issues.apache.org/jira/browse/WICKET-1519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12587810#action_12587810 ] Gerolf Seitz commented on WICKET-1519: -- afaics, by the time the tag is processed, the header is already rendered. so there would be no chance for the component to contribute to the header. > wicket:component : header-contributions don't work atm > -- > > Key: WICKET-1519 > URL: https://issues.apache.org/jira/browse/WICKET-1519 > Project: Wicket > Issue Type: Improvement > Components: wicket >Affects Versions: 1.3.3 >Reporter: Jan Kriesten > > Currently, components embedded thru templates using the wicket:component-tag > seem to be ignored when it comes to header contributions. E.g. > AjaxTimerBehavior don't work. > It would be nice if wicket:component could be enhanced in that respect. > Best regards, --- Jan. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (WICKET-1496) DataTable.html does not validate (HTML 4.01/XHTML-Strict)
[ https://issues.apache.org/jira/browse/WICKET-1496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerolf Seitz resolved WICKET-1496. -- Resolution: Fixed Fix Version/s: 1.4-M1 1.3.4 fixed. thanks. > DataTable.html does not validate (HTML 4.01/XHTML-Strict) > - > > Key: WICKET-1496 > URL: https://issues.apache.org/jira/browse/WICKET-1496 > Project: Wicket > Issue Type: Bug > Components: wicket-extensions >Affects Versions: 1.3.3 >Reporter: Kaspar Fischer >Assignee: Gerolf Seitz >Priority: Trivial > Fix For: 1.3.4, 1.4-M1 > > > According to http://www.w3.org/TR/html401/struct/tables.html#h-11.2.3, > .. must come before the start of . The has not changed > for XHTML. > Proposed fix: just move up after and before . -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (WICKET-1468) Add downloadSources option to quickstart page
[ https://issues.apache.org/jira/browse/WICKET-1468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerolf Seitz resolved WICKET-1468. -- Resolution: Fixed Fix Version/s: (was: 1.3.4) 1.3.3 added the eclipse-plugin configuration to the pom.xml in archetype-resources > Add downloadSources option to quickstart page > - > > Key: WICKET-1468 > URL: https://issues.apache.org/jira/browse/WICKET-1468 > Project: Wicket > Issue Type: Improvement > Components: site >Affects Versions: 1.3.2 >Reporter: Igor Vaynberg >Assignee: Gerolf Seitz > Fix For: 1.3.3 > > > would be cool to have a checkbox or a radio[yes/no] that will control > -DdownloadSources=true param at http://wicket.apache.org/quickstart.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (WICKET-1499) AjaxEditableMultiLineLabel + race condition /
[
https://issues.apache.org/jira/browse/WICKET-1499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gerolf Seitz resolved WICKET-1499.
--
Resolution: Fixed
Fix Version/s: 1.4-M1
1.3.4
fixed. thx.
> AjaxEditableMultiLineLabel + race condition /
> --
>
> Key: WICKET-1499
> URL: https://issues.apache.org/jira/browse/WICKET-1499
> Project: Wicket
> Issue Type: Bug
> Components: wicket-extensions
>Affects Versions: 1.3.3
>Reporter: Jan Kriesten
>Assignee: Gerolf Seitz
> Fix For: 1.3.4, 1.4-M1
>
>
> There are two issues concerning AjaxEditableMultiLineLabel:
> a) Race condition cancel editing
> Using 'Esc' to cancel editing might lead to two events to be fired: first
> onKeypress is executed - which leads to bluring the component in Opera. This
> results in the onblur-event firing and the input is submitted!
> Changing the code in onComponentTag to
> protected void onComponentTag(ComponentTag tag)
> {
> super.onComponentTag(tag);
> final String saveCall = "{wicketAjaxGet('" +
> getCallbackUrl() +
>
> "&save=true&'+this.name+'='+wicketEncode(this.value)); return false;}";
>
> final String cancelCall = "{wicketAjaxGet('"
> + getCallbackUrl() +
> "&save=false'); this.onblur='';
> return false;}";
>
> final String keypress = "var
> kc=wicketKeyCode(event); if (kc==27) " + cancelCall +
> "; ";
>
> tag.put("onblur", saveCall);
> tag.put("onkeypress", keypress);
> }
> stops onblur being fired.
> This might also apply for AjaxEditableLabel - though I haven't seen this
> happening there yet.
> b) Displaying defaultNullLabel on empty String Model:
> Should behave like AjaxEditableLabel, i.e.:
> protected void onComponentTagBody(MarkupStream markupStream,
> ComponentTag openTag)
> {
> Object modelObject = getModelObject();
> if (modelObject == null || "".equals(modelObject))
> {
> replaceComponentTagBody(markupStream, openTag,
> defaultNullLabel());
> }
> else
> {
> super.onComponentTagBody(markupStream, openTag);
> }
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (WICKET-1504) AutoCompleteTextField - javascript error "type mismatch" in line 227 in IE
[ https://issues.apache.org/jira/browse/WICKET-1504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerolf Seitz reassigned WICKET-1504: Assignee: Gerolf Seitz > AutoCompleteTextField - javascript error "type mismatch" in line 227 in IE > -- > > Key: WICKET-1504 > URL: https://issues.apache.org/jira/browse/WICKET-1504 > Project: Wicket > Issue Type: Bug > Components: wicket-extensions >Affects Versions: 1.3.3 > Environment: IE 6.0 >Reporter: Niels Bo >Assignee: Gerolf Seitz > > I just swithed from 1.3.2 to 1.3.3 and that resultet in a javascript error > "type mismatch" in line 227, > wich is this line in wicket-autocomplete.js: > menu.style.zIndex=index=="auto"?index:Number(index)+1; > Only in IE (6.0) - firefox works fine. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (WICKET-1493) The migration from wicket 1.2 to wicket 1.3.2
[ https://issues.apache.org/jira/browse/WICKET-1493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerolf Seitz closed WICKET-1493. Resolution: Invalid please ask questions like these on the mailinglist [EMAIL PROTECTED] use jira only to report actual bugs, feature requests, improvements > The migration from wicket 1.2 to wicket 1.3.2 > - > > Key: WICKET-1493 > URL: https://issues.apache.org/jira/browse/WICKET-1493 > Project: Wicket > Issue Type: Bug >Reporter: fallout > > Hi. > I have some problems with migration from wicket 1.2 to wicket 1.3. > Tell me please what I can use instead of the IExceptionResponseStrategy > interface? > What I can call instead of the IPageMap.lastAccessedEntry() method? > What I can call instead of the Request.getContextPath() method? > Thanks. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (WICKET-1498) The migration from wicket 1.2 to wicket 1.3
[ https://issues.apache.org/jira/browse/WICKET-1498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerolf Seitz closed WICKET-1498. Resolution: Invalid please ask questions like these on the mailinglist [EMAIL PROTECTED] use jira only to report actual bugs, feature requests, improvements > The migration from wicket 1.2 to wicket 1.3 > --- > > Key: WICKET-1498 > URL: https://issues.apache.org/jira/browse/WICKET-1498 > Project: Wicket > Issue Type: Task > Components: wicket >Affects Versions: 1.3.2 >Reporter: fallout > > Hi. > I have some problems with migration from wicket 1.2 to wicket 1.3. > These problems are not described into the migration guide. > Tell me please what I can use instead of the IExceptionResponseStrategy > interface in wicket 1.3.2? > What I can call instead of the IPageMap.lastAccessedEntry() method in wicket > 1.3.2? > What I can call instead of the Request.getContextPath() method in wicket > 1.3.2? > Thanks. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1500) WebMarkupContainer multiplicated markup when using AjaxLink
[ https://issues.apache.org/jira/browse/WICKET-1500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12587110#action_12587110 ] Gerolf Seitz commented on WICKET-1500: -- if the markup is like: Header A it works as expected. > WebMarkupContainer multiplicated markup when using AjaxLink > --- > > Key: WICKET-1500 > URL: https://issues.apache.org/jira/browse/WICKET-1500 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.3.1, 1.3.3 >Reporter: Daniel Stoch >Assignee: Matej Knopp > Attachments: ajax-container-test.zip > > > There is a strange behaviour when I'm trying refresh WebMarkupContainer > component using AjaxLink. I have attached quickstart-app > (ajax-container-test.zip) where you can see this problem. There is a simple > HomePage with one WebMarkupContainer and one AjaxLink. This > WebMarkupContainer is refreshed upon AjaxLink click. > For the first time page is rendered as follows: > Header A > Ajax request > When I click "Ajax request" link the onClick metod is called to refresh > container component (which is WebMarkupContainer). But instead of refreshing > (repainting) of "container" markup (... markup), > it is dupliacted below the original paragraph. Each click on this ajax link > causes this paragraph multiplication and after eg. 4 clicks the page looks > like: > Header A > Header A > Header A > Header A > Header A > Ajax request -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1500) WebMarkupContainer multiplicated markup when using AjaxLink
[ https://issues.apache.org/jira/browse/WICKET-1500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12587107#action_12587107 ] Gerolf Seitz commented on WICKET-1500: -- i see that your markup is like: Header A isn't that considered invalid html? also see http://htmlhelp.com/reference/html40/block/h1.html > WebMarkupContainer multiplicated markup when using AjaxLink > --- > > Key: WICKET-1500 > URL: https://issues.apache.org/jira/browse/WICKET-1500 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.3.1, 1.3.3 >Reporter: Daniel Stoch >Assignee: Matej Knopp > Attachments: ajax-container-test.zip > > > There is a strange behaviour when I'm trying refresh WebMarkupContainer > component using AjaxLink. I have attached quickstart-app > (ajax-container-test.zip) where you can see this problem. There is a simple > HomePage with one WebMarkupContainer and one AjaxLink. This > WebMarkupContainer is refreshed upon AjaxLink click. > For the first time page is rendered as follows: > Header A > Ajax request > When I click "Ajax request" link the onClick metod is called to refresh > container component (which is WebMarkupContainer). But instead of refreshing > (repainting) of "container" markup (... markup), > it is dupliacted below the original paragraph. Each click on this ajax link > causes this paragraph multiplication and after eg. 4 clicks the page looks > like: > Header A > Header A > Header A > Header A > Header A > Ajax request -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1476) Referencing Page may cause StackOverflowError
[ https://issues.apache.org/jira/browse/WICKET-1476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12586134#action_12586134 ] Gerolf Seitz commented on WICKET-1476: -- Johan, seems like I uploaded a wrong export of the project. sorry for this. the new quickstart ends up in a StackOverflowError on my machine (Vistax64, JDK1.6.0_04-32bit) 1) go to http://localhost:8080/first (which redirects to first.0) 2) manually enter the address http://localhost:8080/second (-> second.1) 3) manually enter http://localhost:8080/first.0 in the address bar (don't use the back button) 4) StackOverflowError > Referencing Page may cause StackOverflowError > - > > Key: WICKET-1476 > URL: https://issues.apache.org/jira/browse/WICKET-1476 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.3.2 >Reporter: Gerolf Seitz >Assignee: Johan Compagner > Attachments: StackOverflowBug.zip > > > scenario: > + 2 pages. each page stores itself in the session in the constructor ( -> > last accessed instance of a page is stored in session (which ultimately is > rather bad in the first place)) > + have a final reference to session in page's constructor > + access page 1 mounted as "first" (-> pageId=0) > + access page 2 mounted as "second" several times so that new pages are > created until page1 gets serialized > + access the serialized page 1 via "/first.0" > + StackOverflowError -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-1476) Referencing Page may cause StackOverflowError
[ https://issues.apache.org/jira/browse/WICKET-1476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerolf Seitz updated WICKET-1476: - Attachment: StackOverflowBug.zip > Referencing Page may cause StackOverflowError > - > > Key: WICKET-1476 > URL: https://issues.apache.org/jira/browse/WICKET-1476 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.3.2 >Reporter: Gerolf Seitz >Assignee: Johan Compagner > Attachments: StackOverflowBug.zip > > > scenario: > + 2 pages. each page stores itself in the session in the constructor ( -> > last accessed instance of a page is stored in session (which ultimately is > rather bad in the first place)) > + have a final reference to session in page's constructor > + access page 1 mounted as "first" (-> pageId=0) > + access page 2 mounted as "second" several times so that new pages are > created until page1 gets serialized > + access the serialized page 1 via "/first.0" > + StackOverflowError -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-1476) Referencing Page may cause StackOverflowError
[ https://issues.apache.org/jira/browse/WICKET-1476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerolf Seitz updated WICKET-1476: - Attachment: (was: StackOverflowBug.zip) > Referencing Page may cause StackOverflowError > - > > Key: WICKET-1476 > URL: https://issues.apache.org/jira/browse/WICKET-1476 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.3.2 >Reporter: Gerolf Seitz >Assignee: Johan Compagner > Attachments: StackOverflowBug.zip > > > scenario: > + 2 pages. each page stores itself in the session in the constructor ( -> > last accessed instance of a page is stored in session (which ultimately is > rather bad in the first place)) > + have a final reference to session in page's constructor > + access page 1 mounted as "first" (-> pageId=0) > + access page 2 mounted as "second" several times so that new pages are > created until page1 gets serialized > + access the serialized page 1 via "/first.0" > + StackOverflowError -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1480) wicket-ajax.js: Permission denied to set property XULElement.selectedIndex
[ https://issues.apache.org/jira/browse/WICKET-1480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12585529#action_12585529 ] Gerolf Seitz commented on WICKET-1480: -- seems to an issue with firebug. affects ff2.0.0.13 and ff3b5 see http://groups.google.com/group/mozilla.dev.extensions/browse_thread/thread/ac2702b1ff005955/bba3055cc237b585 > wicket-ajax.js: Permission denied to set property XULElement.selectedIndex > -- > > Key: WICKET-1480 > URL: https://issues.apache.org/jira/browse/WICKET-1480 > Project: Wicket > Issue Type: Bug >Affects Versions: 1.3.3 >Reporter: Martijn Dashorst > > In firefox (2.0.0.13) I got this message > [Exception... "'Permission denied to set property XULElement.selectedIndex' > when calling method: [nsIAutoCompletePopup::selectedIndex]" nsresult: > "0x8057001e (NS_ERROR_XPC_JS_THREW_STRING)" location: "JS frame :: > http://localhost:8080/vocus/app/resources/org.apache.wicket.ajax.WicketAjaxReference/wicket-ajax.js > :: anonymous :: line 1212" data: no] > [Break on this error] eval(text); > Possibly firebug is a culprit here -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1476) Referencing Page may cause StackOverflowError
[ https://issues.apache.org/jira/browse/WICKET-1476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12585145#action_12585145 ] Gerolf Seitz commented on WICKET-1476: -- agreed, it still causes the StackOverFlowError. there may be other ways to hold on to a reference to a page. this is just meant as an example (maybe a bad one) to reproduce and possibly fix the error. we can also decide not to encourage such "mistakes" by keeping the flooded stack... > Referencing Page may cause StackOverflowError > - > > Key: WICKET-1476 > URL: https://issues.apache.org/jira/browse/WICKET-1476 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.3.2 >Reporter: Gerolf Seitz > Attachments: StackOverflowBug.zip > > > scenario: > + 2 pages. each page stores itself in the session in the constructor ( -> > last accessed instance of a page is stored in session (which ultimately is > rather bad in the first place)) > + have a final reference to session in page's constructor > + access page 1 mounted as "first" (-> pageId=0) > + access page 2 mounted as "second" several times so that new pages are > created until page1 gets serialized > + access the serialized page 1 via "/first.0" > + StackOverflowError -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-1476) Referencing Page may cause StackOverflowError
Referencing Page may cause StackOverflowError - Key: WICKET-1476 URL: https://issues.apache.org/jira/browse/WICKET-1476 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 1.3.2 Reporter: Gerolf Seitz Attachments: StackOverflowBug.zip scenario: + 2 pages. each page stores itself in the session in the constructor ( -> last accessed instance of a page is stored in session (which ultimately is rather bad in the first place)) + have a final reference to session in page's constructor + access page 1 mounted as "first" (-> pageId=0) + access page 2 mounted as "second" several times so that new pages are created until page1 gets serialized + access the serialized page 1 via "/first.0" + StackOverflowError -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-1476) Referencing Page may cause StackOverflowError
[ https://issues.apache.org/jira/browse/WICKET-1476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerolf Seitz updated WICKET-1476: - Attachment: StackOverflowBug.zip try attached quickstart to reproduce the error > Referencing Page may cause StackOverflowError > - > > Key: WICKET-1476 > URL: https://issues.apache.org/jira/browse/WICKET-1476 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.3.2 >Reporter: Gerolf Seitz > Attachments: StackOverflowBug.zip > > > scenario: > + 2 pages. each page stores itself in the session in the constructor ( -> > last accessed instance of a page is stored in session (which ultimately is > rather bad in the first place)) > + have a final reference to session in page's constructor > + access page 1 mounted as "first" (-> pageId=0) > + access page 2 mounted as "second" several times so that new pages are > created until page1 gets serialized > + access the serialized page 1 via "/first.0" > + StackOverflowError -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1468) Add downloadSources option to quickstart page
[ https://issues.apache.org/jira/browse/WICKET-1468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12584437#action_12584437 ] Gerolf Seitz commented on WICKET-1468: -- when the archetype is created, no dependent artifacts are resolved. do you mean the checkbox should trigger a parameter which in turn is used by our archetype? we could also just have this as default in the created pom.xml > Add downloadSources option to quickstart page > - > > Key: WICKET-1468 > URL: https://issues.apache.org/jira/browse/WICKET-1468 > Project: Wicket > Issue Type: Improvement > Components: site >Affects Versions: 1.3.2 >Reporter: Igor Vaynberg >Assignee: Gerolf Seitz > Fix For: 1.3.3 > > > would be cool to have a checkbox or a radio[yes/no] that will control > -DdownloadSources=true param at http://wicket.apache.org/quickstart.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (WICKET-1472) JavaDoc enhancements in FileUpload API
[ https://issues.apache.org/jira/browse/WICKET-1472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerolf Seitz resolved WICKET-1472. -- Resolution: Fixed applied. thanks > JavaDoc enhancements in FileUpload API > -- > > Key: WICKET-1472 > URL: https://issues.apache.org/jira/browse/WICKET-1472 > Project: Wicket > Issue Type: Improvement > Components: wicket >Affects Versions: 1.3.2, 1.3.3 >Reporter: Rüdiger Schulz >Assignee: Gerolf Seitz >Priority: Minor > Fix For: 1.3.3 > > Attachments: FileUploadField.diff > > > I discovered a small error in FileUploadField API, and have a clarification > for FileUpload. Will provide patch. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1329) AutoCompleteTextField's suggestion list *disappeared* when it is used inside a ModalWindow
[ https://issues.apache.org/jira/browse/WICKET-1329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12583837#action_12583837 ] Gerolf Seitz commented on WICKET-1329: -- i changed it so that the autocomplete menu detects the zIndex of its offsetParent and sets its own zIndex to that value + 1. > AutoCompleteTextField's suggestion list *disappeared* when it is used inside > a ModalWindow > -- > > Key: WICKET-1329 > URL: https://issues.apache.org/jira/browse/WICKET-1329 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.3.0-final >Reporter: Andy Chu >Assignee: Gerolf Seitz > Fix For: 1.3.3 > > > When an AutoCompleteTextField is used in panel showed inside a ModalWindow, > the dropdown list for suggestions will be disappeared. The reason is that the > z-index of a normal ModalWindow is 2 while the z-index of the dropdown > list is 1. And there is no way to set this parameter programatically. > Therefore, the dropdown list is masked by the ModalWindow. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1458) Changing tag name and expanding open-close to open-body-close prints old tag name
[
https://issues.apache.org/jira/browse/WICKET-1458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12583337#action_12583337
]
Gerolf Seitz commented on WICKET-1458:
--
Jürgen, do you want to throw an exception in general or just for this specific
situation (changing name and type)?
because we need the ability to change tagnames eg. for nested forms.
> Changing tag name and expanding open-close to open-body-close prints old tag
> name
> -
>
> Key: WICKET-1458
> URL: https://issues.apache.org/jira/browse/WICKET-1458
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.3.2
>Reporter: John Patterson
>Assignee: Juergen Donnerstag
> Fix For: 1.3.3
>
> Attachments: WICKET-1458.patch
>
>
> I do this:
> @Override
> protected void
> onComponentTag(ComponentTag tag)
> {
> tag.setName("select");
> if (tag.isOpenClose())
> {
>
> tag.setType(XmlTag.OPEN);
> }
> super.onComponentTag(tag);
> }
> and the close tag that is generated is not a "select" but the old "input"
> This can be fixed in Component line 2485:
> // Close the manually
> opened panel tag.
>
> getResponse().write(openTag.syntheticCloseTagString());
> could be changed to
> // Close the manually
> opened panel tag.
>
> getResponse().write(tag.syntheticCloseTagString());
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-1458) Changing tag name and expanding open-close to open-body-close prints old tag name
[
https://issues.apache.org/jira/browse/WICKET-1458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gerolf Seitz updated WICKET-1458:
-
Attachment: WICKET-1458.patch
patch that fixes the issue.
Jürgen, could you take a look at this please?
you're way more familiar with markup processing.
> Changing tag name and expanding open-close to open-body-close prints old tag
> name
> -
>
> Key: WICKET-1458
> URL: https://issues.apache.org/jira/browse/WICKET-1458
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.3.2
>Reporter: John Patterson
>Assignee: Gerolf Seitz
> Fix For: 1.3.3
>
> Attachments: WICKET-1458.patch
>
>
> I do this:
> @Override
> protected void
> onComponentTag(ComponentTag tag)
> {
> tag.setName("select");
> if (tag.isOpenClose())
> {
>
> tag.setType(XmlTag.OPEN);
> }
> super.onComponentTag(tag);
> }
> and the close tag that is generated is not a "select" but the old "input"
> This can be fixed in Component line 2485:
> // Close the manually
> opened panel tag.
>
> getResponse().write(openTag.syntheticCloseTagString());
> could be changed to
> // Close the manually
> opened panel tag.
>
> getResponse().write(tag.syntheticCloseTagString());
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-1458) Changing tag name and expanding open-close to open-body-close prints old tag name
[
https://issues.apache.org/jira/browse/WICKET-1458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gerolf Seitz updated WICKET-1458:
-
Assignee: Juergen Donnerstag (was: Gerolf Seitz)
> Changing tag name and expanding open-close to open-body-close prints old tag
> name
> -
>
> Key: WICKET-1458
> URL: https://issues.apache.org/jira/browse/WICKET-1458
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.3.2
>Reporter: John Patterson
>Assignee: Juergen Donnerstag
> Fix For: 1.3.3
>
> Attachments: WICKET-1458.patch
>
>
> I do this:
> @Override
> protected void
> onComponentTag(ComponentTag tag)
> {
> tag.setName("select");
> if (tag.isOpenClose())
> {
>
> tag.setType(XmlTag.OPEN);
> }
> super.onComponentTag(tag);
> }
> and the close tag that is generated is not a "select" but the old "input"
> This can be fixed in Component line 2485:
> // Close the manually
> opened panel tag.
>
> getResponse().write(openTag.syntheticCloseTagString());
> could be changed to
> // Close the manually
> opened panel tag.
>
> getResponse().write(tag.syntheticCloseTagString());
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1301) DatePicker behind ModalWindow on FireFox
[
https://issues.apache.org/jira/browse/WICKET-1301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12583078#action_12583078
]
Gerolf Seitz commented on WICKET-1301:
--
the following seems to fix the problem:
div.wicket-modal div.w_bottom_1 {
width: 100%;
overflow: hidden;
cursor: n-resize;
>> position: absolute;
>> z-index: -1;
}
i'm not sure though if this breaks the layout somehow.
> DatePicker behind ModalWindow on FireFox
>
>
> Key: WICKET-1301
> URL: https://issues.apache.org/jira/browse/WICKET-1301
> Project: Wicket
> Issue Type: Bug
> Components: wicket-extensions
>Affects Versions: 1.3.0-final
> Environment: Windows XP / FireFox 2.0
>Reporter: André Winkler
>Assignee: Matej Knopp
> Attachments: screenshot.JPG
>
>
> The DatePicker (org.apache.wicket.extensions.yui.calendar) in my ModalWindow
> is behind the ModalWindow border. This effect occures only on the FireFox
> Browser, not under the Internet Explorer.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (WICKET-1457) modalwindow with panel doesn't resize properly on IE
[ https://issues.apache.org/jira/browse/WICKET-1457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerolf Seitz resolved WICKET-1457. -- Resolution: Fixed > modalwindow with panel doesn't resize properly on IE > > > Key: WICKET-1457 > URL: https://issues.apache.org/jira/browse/WICKET-1457 > Project: Wicket > Issue Type: Bug > Components: wicket-extensions >Reporter: Gerolf Seitz >Assignee: Gerolf Seitz >Priority: Minor > Fix For: 1.3.3 > > Attachments: modal-window-resize-glitch.jpg > > > see attached screenshot. > fix: add _overflow:auto to div.wicket-modal div.w_content_2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-1457) modalwindow with panel doesn't resize properly on IE
[ https://issues.apache.org/jira/browse/WICKET-1457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerolf Seitz updated WICKET-1457: - Attachment: modal-window-resize-glitch.jpg > modalwindow with panel doesn't resize properly on IE > > > Key: WICKET-1457 > URL: https://issues.apache.org/jira/browse/WICKET-1457 > Project: Wicket > Issue Type: Bug > Components: wicket-extensions >Reporter: Gerolf Seitz >Assignee: Gerolf Seitz >Priority: Minor > Fix For: 1.3.3 > > Attachments: modal-window-resize-glitch.jpg > > > see attached screenshot. > fix: add _overflow:auto to div.wicket-modal div.w_content_2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-1457) modalwindow with panel doesn't resize properly on IE
modalwindow with panel doesn't resize properly on IE Key: WICKET-1457 URL: https://issues.apache.org/jira/browse/WICKET-1457 Project: Wicket Issue Type: Bug Components: wicket-extensions Reporter: Gerolf Seitz Assignee: Gerolf Seitz Priority: Minor Fix For: 1.3.3 see attached screenshot. fix: add _overflow:auto to div.wicket-modal div.w_content_2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1376) Using AbstractAjaxTimerBehavior and mounting that page gives exception
[ https://issues.apache.org/jira/browse/WICKET-1376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12582987#action_12582987 ] Gerolf Seitz commented on WICKET-1376: -- i couldn't reproduce the illegalargumentexception with the clock example. however, adding a page to the ajaxrequesttarget doesn't work anyways. we could check whether the component is a page and then instead of adding the page to the target, add it's children (via addChildren). but this probably fails in most situations, as all children would have to have called .setOutputMarkupId(true). but maybe we can add check and just ignore those? > Using AbstractAjaxTimerBehavior and mounting that page gives exception > -- > > Key: WICKET-1376 > URL: https://issues.apache.org/jira/browse/WICKET-1376 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.3.1 >Reporter: Oliver Krohne >Assignee: Johan Compagner > Fix For: 1.3.3 > > > AbstractAjaxTimerBehavior renders a table every 3 seconds. > A DataView is used to populate the table. > I have tried mountBookmarkablePage(), QueryStringUrlCodingStrategy and > MixedParamUrlCodingStrategy. > Root cause: > java.lang.IllegalStateException: URL fragment has unmatched key/value pair: > amp > at > org.apache.wicket.request.target.coding.AbstractRequestTargetUrlCodingStrategy.decodeParameters(AbstractRequestTargetUrlCodingStrategy.java:174) > at > org.apache.wicket.request.target.coding.BookmarkablePageRequestTargetUrlCodingStrategy.decode(BookmarkablePageRequestTargetUrlCodingStrategy.java:76) > at > org.apache.wicket.protocol.http.request.WebRequestCodingStrategy.targetForRequest(WebRequestCodingStrategy.java:475) > at > org.apache.wicket.protocol.http.WebRequestCycleProcessor.resolve(WebRequestCycleProcessor.java:175) > at org.apache.wicket.RequestCycle.step(RequestCycle.java:1224) > at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1316) > at org.apache.wicket.RequestCycle.request(RequestCycle.java:493) > at org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:354) > at > org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:194) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) > at > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230) > at > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) > at > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) > at > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104) > at > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) > at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:261) > at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844) > at > org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:581) > at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447) > at java.lang.Thread.run(Thread.java:613) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (WICKET-1268) Form inside VelocityPanel throws WicketRuntimeException: Unable to find the markup for the component.
[ https://issues.apache.org/jira/browse/WICKET-1268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerolf Seitz resolved WICKET-1268. -- Resolution: Fixed Assignee: Gerolf Seitz (was: Eelco Hillenius) fixed: VelocityPanel implements IMarkupResourceStreamProvider and returns the evaluated velocity template (which doesn't get cached). onBeforeRender checks that child components can only be added if the generated markup should be parsed. > Form inside VelocityPanel throws WicketRuntimeException: Unable to find the > markup for the component. > - > > Key: WICKET-1268 > URL: https://issues.apache.org/jira/browse/WICKET-1268 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.3.0-final > Environment: Win XP / Tomcat 6.0 >Reporter: Markus Sabadello >Assignee: Gerolf Seitz > Fix For: 1.3.3 > > Attachments: simplevelocity.zip > > > I am trying to have a Form inside a VelocityPanel, but I get the following > Exception: > WicketMessage: Unable to find the markup for the component. That may be due > to transparent containers or components implementing IComponentResolver: > [MarkupContainer [Component id = form, page = > simplevelocity.SimpleVelocityPage, path = 3:velocity:form.MyForm, isVisible = > true, isVersioned = true]] > Root cause: > org.apache.wicket.WicketRuntimeException: Unable to find the markup for the > component. That may be due to transparent containers or components > implementing IComponentResolver: [MarkupContainer [Component id = form, page > = simplevelocity.SimpleVelocityPage, path = 3:velocity:form.MyForm, isVisible > = true, isVersioned = true]] > at org.apache.wicket.MarkupFragmentFinder.find(MarkupFragmentFinder.java:118) > at org.apache.wicket.Component.locateMarkupStream(Component.java:3584) > at org.apache.wicket.Component.getMarkupAttributes(Component.java:1359) > at org.apache.wicket.markup.html.form.Form.getMethod(Form.java:1310) > at org.apache.wicket.markup.html.form.Form.onComponentTag(Form.java:1457) > at org.apache.wicket.Component.renderComponent(Component.java:2400) > at org.apache.wicket.MarkupContainer.onRender(MarkupContainer.java:1354) > at org.apache.wicket.markup.html.form.Form.onRender(Form.java:1588) > at org.apache.wicket.Component.render(Component.java:2266) > at org.apache.wicket.MarkupContainer.renderNext(MarkupContainer.java:1240) > at org.apache.wicket.MarkupContainer.renderAll(MarkupContainer.java:1370) > at > org.apache.wicket.velocity.markup.html.VelocityPanel.onComponentTagBody(VelocityPanel.java:228) > at org.apache.wicket.Component.renderComponent(Component.java:2429) > at org.apache.wicket.MarkupContainer.onRender(MarkupContainer.java:1354) > at org.apache.wicket.Component.render(Component.java:2266) > at org.apache.wicket.MarkupContainer.renderNext(MarkupContainer.java:1240) > at org.apache.wicket.MarkupContainer.renderAll(MarkupContainer.java:1370) > at org.apache.wicket.Page.onRender(Page.java:1442) > at org.apache.wicket.Component.render(Component.java:2266) > at org.apache.wicket.Page.renderPage(Page.java:891) > at > org.apache.wicket.request.target.component.BookmarkablePageRequestTarget.respond(BookmarkablePageRequestTarget.java:231) > at > org.apache.wicket.request.AbstractRequestCycleProcessor.respond(AbstractRequestCycleProcessor.java:103) > at > org.apache.wicket.RequestCycle.processEventsAndRespond(RequestCycle.java:1100) > at org.apache.wicket.RequestCycle.step(RequestCycle.java:1169) > at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1245) > at org.apache.wicket.RequestCycle.request(RequestCycle.java:489) > at org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:354) > at > org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:194) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) > at > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:228) > at > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) > at > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) > at > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104) > at > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) > at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:216) > at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844) > at > org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:634) > at org.apache.tomcat.util.net.JIoEndpoint
[jira] Resolved: (WICKET-1329) AutoCompleteTextField's suggestion list *disappeared* when it is used inside a ModalWindow
[ https://issues.apache.org/jira/browse/WICKET-1329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerolf Seitz resolved WICKET-1329. -- Resolution: Fixed Fix Version/s: 1.3.3 Assignee: Gerolf Seitz (was: Janne Hietamäki) i set the z-index to 3, so it's higher than modalwindow's z-index. > AutoCompleteTextField's suggestion list *disappeared* when it is used inside > a ModalWindow > -- > > Key: WICKET-1329 > URL: https://issues.apache.org/jira/browse/WICKET-1329 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.3.0-final >Reporter: Andy Chu >Assignee: Gerolf Seitz > Fix For: 1.3.3 > > > When an AutoCompleteTextField is used in panel showed inside a ModalWindow, > the dropdown list for suggestions will be disappeared. The reason is that the > z-index of a normal ModalWindow is 2 while the z-index of the dropdown > list is 1. And there is no way to set this parameter programatically. > Therefore, the dropdown list is masked by the ModalWindow. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (WICKET-1372) Input field with autocomplete behavior does not submit the form via enter key in some cases
[ https://issues.apache.org/jira/browse/WICKET-1372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerolf Seitz resolved WICKET-1372. -- Resolution: Fixed Assignee: Gerolf Seitz (was: Janne Hietamäki) also, see WICKET-1454 > Input field with autocomplete behavior does not submit the form via enter key > in some cases > --- > > Key: WICKET-1372 > URL: https://issues.apache.org/jira/browse/WICKET-1372 > Project: Wicket > Issue Type: Bug > Components: wicket-extensions >Affects Versions: 1.3.1 > Environment: Debian >Reporter: Albert Brand >Assignee: Gerolf Seitz >Priority: Minor > Fix For: 1.3.3 > > > This is related to WICKET-2 but wasn't fixed in that bug: > When you enter nothing in an input field with autocomplete and press enter, > type something that doesn't give results or press escape when the > autocomplete box has appeared, you have to press enter twice to submit the > form. > The solution is quite simple: remove line 219 from wicket-autocomplete.js: > hidingAutocomplete=1; > This variable was introduced to keep enter from submitting, but by setting it > here always to 1, enter is blocked in the above cases. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (WICKET-1454) Enter in AutoCompleteTextField with AjaxFormSubmitBehavior on change-event submits form multiple times
[ https://issues.apache.org/jira/browse/WICKET-1454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerolf Seitz resolved WICKET-1454. -- Resolution: Fixed i think the following behavior is what a user would expect: (focus is always on textbox) menu visible, select item with keyboard, ENTER -> invoke onchange of textbox menu visible, ESC, ENTER -> submit form menu visible, no item selected, ENTER -> submit form menu visible, click on item with mouse -> invoke onchange of textbox menu hidden, ENTER -> submit form type some letters, click somewhere on the page -> invoke onchange of textbox > Enter in AutoCompleteTextField with AjaxFormSubmitBehavior on change-event > submits form multiple times > -- > > Key: WICKET-1454 > URL: https://issues.apache.org/jira/browse/WICKET-1454 > Project: Wicket > Issue Type: Bug > Components: wicket-extensions >Reporter: Gerolf Seitz >Assignee: Gerolf Seitz > Fix For: 1.3.3 > > > when the autocomplete menu is hidden, hitting enter in an > autocomplete-textbox submits the form several times (due to event handling in > onkeydown, onkeyup, onkeypress) > we should kill the event in 2 of the 3 eventhandlers. which one would be the > best to keep? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1454) Enter in AutoCompleteTextField with AjaxFormSubmitBehavior on change-event submits form multiple times
[ https://issues.apache.org/jira/browse/WICKET-1454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12582784#action_12582784 ] Gerolf Seitz commented on WICKET-1454: -- the problem is that onkeydown executes the original onchange (attached AFSB) event handler of the textbox when KEY_ENTER is pressed and doesn't kill the event. next, onkeypress doesn't kill the event because no item is selected, which leads to the form being submitted via a non-ajax roundtrip. now what we could/should do is NOT call onchange in onkeydown in the KEY_ENTER block, as browsers only fire the change event when the textbox loses focus. wdyt? > Enter in AutoCompleteTextField with AjaxFormSubmitBehavior on change-event > submits form multiple times > -- > > Key: WICKET-1454 > URL: https://issues.apache.org/jira/browse/WICKET-1454 > Project: Wicket > Issue Type: Bug > Components: wicket-extensions >Reporter: Gerolf Seitz >Assignee: Gerolf Seitz > Fix For: 1.3.3 > > > when the autocomplete menu is hidden, hitting enter in an > autocomplete-textbox submits the form several times (due to event handling in > onkeydown, onkeyup, onkeypress) > we should kill the event in 2 of the 3 eventhandlers. which one would be the > best to keep? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-1454) Enter in AutoCompleteTextField with AjaxFormSubmitBehavior on change-event submits form multiple times
[ https://issues.apache.org/jira/browse/WICKET-1454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerolf Seitz updated WICKET-1454: - Summary: Enter in AutoCompleteTextField with AjaxFormSubmitBehavior on change-event submits form multiple times (was: enter in AutoCompleteTextField submits form 2-4 times) > Enter in AutoCompleteTextField with AjaxFormSubmitBehavior on change-event > submits form multiple times > -- > > Key: WICKET-1454 > URL: https://issues.apache.org/jira/browse/WICKET-1454 > Project: Wicket > Issue Type: Bug > Components: wicket-extensions >Reporter: Gerolf Seitz >Assignee: Gerolf Seitz > Fix For: 1.3.3 > > > when the autocomplete menu is hidden, hitting enter in an > autocomplete-textbox submits the form several times (due to event handling in > onkeydown, onkeyup, onkeypress) > we should kill the event in 2 of the 3 eventhandlers. which one would be the > best to keep? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-1454) enter in AutoCompleteTextField submits form 2-4 times
[ https://issues.apache.org/jira/browse/WICKET-1454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerolf Seitz updated WICKET-1454: - Assignee: Gerolf Seitz Description: when the autocomplete menu is hidden, hitting enter in an autocomplete-textbox submits the form several times (due to event handling in onkeydown, onkeyup, onkeypress) we should kill the event in 2 of the 3 eventhandlers. which one would be the best to keep? was: in certain conditions, hitting enter in an autocompletetextbox submits the form several times (due to event handling in onkeydown, onkeyup, onkeypress) we should kill the event in 2 of the 3 eventhandlers. which one would be the best to keep? onkeypress (since it's the last of the 3 events)? > enter in AutoCompleteTextField submits form 2-4 times > - > > Key: WICKET-1454 > URL: https://issues.apache.org/jira/browse/WICKET-1454 > Project: Wicket > Issue Type: Bug > Components: wicket-extensions >Reporter: Gerolf Seitz >Assignee: Gerolf Seitz > Fix For: 1.3.3 > > > when the autocomplete menu is hidden, hitting enter in an > autocomplete-textbox submits the form several times (due to event handling in > onkeydown, onkeyup, onkeypress) > we should kill the event in 2 of the 3 eventhandlers. which one would be the > best to keep? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-1454) enter in AutoCompleteTextField submits form 2-4 times
enter in AutoCompleteTextField submits form 2-4 times - Key: WICKET-1454 URL: https://issues.apache.org/jira/browse/WICKET-1454 Project: Wicket Issue Type: Bug Components: wicket-extensions Reporter: Gerolf Seitz Fix For: 1.3.3 in certain conditions, hitting enter in an autocompletetextbox submits the form several times (due to event handling in onkeydown, onkeyup, onkeypress) we should kill the event in 2 of the 3 eventhandlers. which one would be the best to keep? onkeypress (since it's the last of the 3 events)? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (WICKET-310) AutoCompleteTextField does not invoke post call handlers
[ https://issues.apache.org/jira/browse/WICKET-310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerolf Seitz resolved WICKET-310. - Resolution: Fixed > AutoCompleteTextField does not invoke post call handlers > > > Key: WICKET-310 > URL: https://issues.apache.org/jira/browse/WICKET-310 > Project: Wicket > Issue Type: Bug > Components: wicket-extensions >Affects Versions: 1.2.3, 1.2.5 >Reporter: paolo di tommaso >Assignee: Janne Hietamäki >Priority: Minor > Fix For: 1.3.3 > > > The AutoCompleteTextField does not invoke the registered post call handlers > after the ajax request has been completed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-310) AutoCompleteTextField does not invoke post call handlers
[ https://issues.apache.org/jira/browse/WICKET-310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12582635#action_12582635 ] Gerolf Seitz commented on WICKET-310: - added call to Wicket.Ajax.invokePostCallHandlers in doUpdateChoices > AutoCompleteTextField does not invoke post call handlers > > > Key: WICKET-310 > URL: https://issues.apache.org/jira/browse/WICKET-310 > Project: Wicket > Issue Type: Bug > Components: wicket-extensions >Affects Versions: 1.2.3, 1.2.5 >Reporter: paolo di tommaso >Assignee: Janne Hietamäki >Priority: Minor > Fix For: 1.3.3 > > > The AutoCompleteTextField does not invoke the registered post call handlers > after the ajax request has been completed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1355) Autocomplete window has wrong position in scrolled context
[ https://issues.apache.org/jira/browse/WICKET-1355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12582622#action_12582622 ] Gerolf Seitz commented on WICKET-1355: -- in case we don't want to move the dropdown div to become a sibling of the textbox, the method YAHOO.Dom.getXY correctly calculates the position in a scrolled context. and since it's BSD licensed we could also use it in wicket-autocomplete.js needless to say that it's at least about 5 times the size (LOC) as the current getPosition method. > Autocomplete window has wrong position in scrolled context > -- > > Key: WICKET-1355 > URL: https://issues.apache.org/jira/browse/WICKET-1355 > Project: Wicket > Issue Type: Bug > Components: wicket-extensions >Affects Versions: 1.3.1 >Reporter: Erik van Oosten >Assignee: Janne Hietamäki > Fix For: 1.3.3 > > Attachments: wicket-autocomplete.js > > > When the autocompleted field is located in a scrolled div, the drop-down > window is positioned too far down. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (WICKET-1452) Error in javadoc class description in MySignInPage
[ https://issues.apache.org/jira/browse/WICKET-1452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerolf Seitz closed WICKET-1452. Resolution: Fixed Fix Version/s: (was: 1.3.2) 1.3.3 Assignee: Gerolf Seitz thanks > Error in javadoc class description in MySignInPage > -- > > Key: WICKET-1452 > URL: https://issues.apache.org/jira/browse/WICKET-1452 > Project: Wicket > Issue Type: Bug > Components: wicket-examples >Affects Versions: 1.3.2 >Reporter: Jörgen Persson >Assignee: Gerolf Seitz >Priority: Trivial > Fix For: 1.3.3 > > > In the class comment of class MySignInPage it says that it extends > MySignInPage, should of course be SignInPage. > /** > * Simple example of a sign in page. It extends MySignInPage, a base class > which provide standard > * functionality for typical log-in pages > * > * @author Jonathan Locke > */ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (WICKET-1351) AutoCompleteTextField's *scrollable* suggestion list can be better if it can be scrolled using KEY_UP and KEY_DOWN
[ https://issues.apache.org/jira/browse/WICKET-1351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerolf Seitz resolved WICKET-1351. -- Resolution: Fixed navigation with key_up/key_down scrolls the selected list item to the top of the suggestion list. also, when the user clicks on the scrollbar, focus is set on the textfield to enable further keyboard navigation > AutoCompleteTextField's *scrollable* suggestion list can be better if it can > be scrolled using KEY_UP and KEY_DOWN > -- > > Key: WICKET-1351 > URL: https://issues.apache.org/jira/browse/WICKET-1351 > Project: Wicket > Issue Type: Improvement > Components: wicket >Affects Versions: 1.3.0-final, 1.3.1 >Reporter: Andy Chu >Assignee: Gerolf Seitz > Fix For: 1.3.3 > > > In the situation described in issue [WICKET-1350], a user always expected > the suggestion list can be scrolled by using KEY_UP and KEY_DOWN. So far, the > suggestion list can only be scrolled by moving the scroll bar. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (WICKET-1350) AutoCompleteTextField's *scrollable* suggestion list disappeared when a mouse pointing to the scroll bar in IE6/7
[
https://issues.apache.org/jira/browse/WICKET-1350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gerolf Seitz resolved WICKET-1350.
--
Resolution: Fixed
simple fix:
add mouseout and mouseover listener to the choiceDiv (instead of
mouseover/mouseout on list-nodes) and set mouseactive accordingly
> AutoCompleteTextField's *scrollable* suggestion list disappeared when a mouse
> pointing to the scroll bar in IE6/7
> -
>
> Key: WICKET-1350
> URL: https://issues.apache.org/jira/browse/WICKET-1350
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.3.0-final, 1.3.1
> Environment: IE6/7
>Reporter: Andy Chu
>Assignee: Gerolf Seitz
> Fix For: 1.3.3
>
>
> if we define the following CCS to fix the height of the suggestion list, the
> list will become to be scrollable when it is overflow, for example, there are
> 100 suggestions should be shown.
> div.wicket-aa {
> height: 200px;
> overflow: auto;
> }
> if a user moves his mouse to the scroll bar, the suggestion list will
> disappear immediately in IE6/7 but in FF. The reason is that the *onblur*
> event of the text field is triggered in IE but in FF. At the moment the
> mouse pointing to the scroll bar, Wicket.AutoComplete.mouseactive is 0,
> therefore, hideAutoComplete() was called. That's why the suggestion list
> disappeared in IE6/7.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
