Re: AutoCompleteTextField with position: fixed
Hello, Your issue seems to be related to css and not to Wicket itself. From the css spec for "position: fixed" : The box's position is calculated according to the 'absolute' model, but in addition, the box is fixed with respect to some reference. [...] the box is fixed with respect to the viewport and does not move when scrolled. I'm not trying to be condescending here, especially since I don't fully understand your issue, but maybe looking up a tutorial on css positioning might give you the answer. I'm not convinced you need any javascript to fix this. Regards, Bertrand On 10/12/2014 5:27 AM, pureza wrote: Hi, I need to have an AutoCompleteTextField with position: fixed, because it sits inside a fixed Modal. However, Wicket calculates the position coordinates based on the top of the document and not the top of the screen, so the dropdown doesn't show up in the right place when there is a scrollbar. To fix this, I tried to add custom JavaScript code to the AutoCompleteBehavior, by overriding updateAjaxAttributes and adding my own AjaxCallListener. However, this didn't work because AutoCompleteBehavior seems to ignore any AjaxCallListener, as reported here: http://mail-archives.apache.org/mod_mbox/wicket-users/201301.mbox/%3c1358755750041-4655560.p...@n4.nabble.com%3E. Could you tell me what's the best way of achieving this? Thank you, Luis Pureza -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/AutoCompleteTextField-with-position-fixed-tp4668713.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Should I use a (stateless) WebPage or a Resource to return a json response for an autocomplete component?
Thank you both for your answers. I have reasons to roll my own autocomplete component. But I did take a look at the way wiqiery and wicket-jquery are serving the choices. As far as I can tell neither is using a stateless/lightweight way for serving the choices. Both serve them with a request to the page that contains the autocomplete component. This provides flexibility (because you can use the page state to adapt the returned choices) but also sounds quite expensive. Am I going too far here worrying about performance? Also, if I wanted to use resources as Andrea suggested, the only way to register them is via an initializer or at application start? Can't the component register them? On Sat, Dec 13, 2014 at 10:33 PM, Martin Grigorov wrote: > > Hi, > > There are few very good integrations between Wicket and JQuery UI. > Check https://github.com/sebfz1/wicket-jquery-ui and > https://github.com/WiQuery/wiquery > Both of them provide autocomplete component. > > Martin Grigorov > Wicket Training and Consulting > https://twitter.com/mtgrigorov > > On Sat, Dec 13, 2014 at 7:50 PM, Andrea Del Bene > wrote: > > > > Hi, > > > > I suggest you to use a resource instead of an adapted stateless page. > > Wicketstuff has a module with special Wicket resources to implement REST > > api: https://github.com/wicketstuff/core/tree/master/ > > jdk-1.7-parent/wicketstuff-restannotations-parent. Here you can find > > resources that already produce JSON in output. > > To configure them you might use a Wicket initializer: > > http://wicket.apache.org/guide/guide/single.html#advanced_3 > > > > Hi all, > >> > >> I am making an autocomplete component based on jquery-autocomplete. > >> > >> I have currently implemented the data source using a stateless web page > >> which writes the json response. > >> > >> What I don't like about this is that it is a separate file/class from my > >> autocomplete component. But I like that it's stateless. > >> > >> Could I achieve the same effect (statelessness) using a dynamic resource > >> registered/created from within the autocomplete component? In other > words > >> I > >> want the autocomplete component, upon creation, to register a resource > >> that > >> can be used to serve the autocomplete options. But I want the resource > to > >> be stateless and lightweight and the requests to return the autocomplete > >> options should not have to go through the page that contains the > >> autocomplete component. > >> > >> Furthermore, if I have the same autocomplete component twice in a page, > >> the > >> resource should be registered only once and server requests for both > >> components. > >> > >> Is this possible? Can you provide some guidelines? > >> > >> Thanks > >> Marios > >> > >> > > > > - > > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > > For additional commands, e-mail: users-h...@wicket.apache.org > > > > >
Re: Should I use a (stateless) WebPage or a Resource to return a json response for an autocomplete component?
Hi, There are few very good integrations between Wicket and JQuery UI. Check https://github.com/sebfz1/wicket-jquery-ui and https://github.com/WiQuery/wiquery Both of them provide autocomplete component. Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Sat, Dec 13, 2014 at 7:50 PM, Andrea Del Bene wrote: > > Hi, > > I suggest you to use a resource instead of an adapted stateless page. > Wicketstuff has a module with special Wicket resources to implement REST > api: https://github.com/wicketstuff/core/tree/master/ > jdk-1.7-parent/wicketstuff-restannotations-parent. Here you can find > resources that already produce JSON in output. > To configure them you might use a Wicket initializer: > http://wicket.apache.org/guide/guide/single.html#advanced_3 > > Hi all, >> >> I am making an autocomplete component based on jquery-autocomplete. >> >> I have currently implemented the data source using a stateless web page >> which writes the json response. >> >> What I don't like about this is that it is a separate file/class from my >> autocomplete component. But I like that it's stateless. >> >> Could I achieve the same effect (statelessness) using a dynamic resource >> registered/created from within the autocomplete component? In other words >> I >> want the autocomplete component, upon creation, to register a resource >> that >> can be used to serve the autocomplete options. But I want the resource to >> be stateless and lightweight and the requests to return the autocomplete >> options should not have to go through the page that contains the >> autocomplete component. >> >> Furthermore, if I have the same autocomplete component twice in a page, >> the >> resource should be registered only once and server requests for both >> components. >> >> Is this possible? Can you provide some guidelines? >> >> Thanks >> Marios >> >> > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
Re: java.lang.ClassNotFoundException: lowercased class name?
Hi, The class name comes from the url, e.g. /wicket/resource/org.apache.wicket.ajax.AbstractDefaultAjaxBehavior/res/js/wicket-ajax-jquery.js Something changes the characters to be lower case. It could be any of the filters but it could be the browser/user too. Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Sat, Dec 13, 2014 at 9:54 PM, Hendy Irawan wrote: > > I wonder how another filter could alter the behavior for this issue.. > > The call fails at > > org.apache.wicket.core.util.lang.WicketObjects.resolveClass(WicketObjects.java:72), > surely the class name to be resolved is solely at Wicket's control? > > On Sun, Dec 14, 2014, 01:18 Ernesto Reinaldo Barreiro-4 [via Apache Wicket] > wrote: > > There are more filters, besides wicket filter, on the filter chain. Did you > check those? > > > -- > View this message in context: > http://apache-wicket.1842946.n4.nabble.com/java-lang-ClassNotFoundException-lowercased-class-name-tp4668754p4668757.html > Sent from the Users forum mailing list archive at Nabble.com. > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
Re: java.lang.ClassNotFoundException: lowercased class name?
I wonder how another filter could alter the behavior for this issue.. The call fails at org.apache.wicket.core.util.lang.WicketObjects.resolveClass(WicketObjects.java:72), surely the class name to be resolved is solely at Wicket's control? On Sun, Dec 14, 2014, 01:18 Ernesto Reinaldo Barreiro-4 [via Apache Wicket] wrote: There are more filters, besides wicket filter, on the filter chain. Did you check those? -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/java-lang-ClassNotFoundException-lowercased-class-name-tp4668754p4668757.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: java.lang.ClassNotFoundException: lowercased class name?
There are more filters, besides wicket filter, on the filter chain. Did you check those? On 13 Dec 2014 18:12, "Hendy Irawan" wrote: > Has anyone ever encountered this error? > > It confuses me because: > 1. It doesn't happen often, but happens a few times a day > 2. Only happens on production > 3. Pretty much all functionality work fine when tested manually > > What's weird is the class name is lowercased, i.e. > "org.apache.wicket.ajax.form.ajaxformchoicecomponentupdatingbehavior" > doesn't exist... but > "org.apache.wicket.ajax.form.AjaxFormChoiceComponentUpdatingBehavior" does. > Who did the lowercasing? > > 23:41:01.411 WARN | kalyanitun || > -ver-d12e39a9a23f5adefcfe3bfc3d520d68.js > msnbot-207-46-13-117.search.msn.com Mozilla/5.0 (compati | > -apr-8204-exec-4 > | o.a.w.c.u.l.WicketObjects| Could not resolve class > [org.apache.wicket.ajax.form.ajaxformchoicecomponentupdatingbehavior] > java.lang.ClassNotFoundException: > org.apache.wicket.ajax.form.ajaxformchoicecomponentupdatingbehavior > at > > org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1718) > ~[tomcat-catalina-7.0.52.jar:7.0.52] > at > > org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1569) > ~[tomcat-catalina-7.0.52.jar:7.0.52] > at java.lang.Class.forName0(Native Method) ~[na:1.8.0_25] > at java.lang.Class.forName(Class.java:344) ~[na:1.8.0_25] > at > > org.apache.wicket.application.AbstractClassResolver.resolveClass(AbstractClassResolver.java:108) > ~[wicket-core-6.18.0.jar:6.18.0] > at > > org.apache.wicket.core.util.lang.WicketObjects.resolveClass(WicketObjects.java:72) > ~[wicket-core-6.18.0.jar:6.18.0] > at > > org.apache.wicket.core.request.mapper.BasicResourceReferenceMapper.resolveClass(BasicResourceReferenceMapper.java:153) > [wicket-core-6.18.0.jar:6.18.0] > at > > org.apache.wicket.core.request.mapper.BasicResourceReferenceMapper.mapRequest(BasicResourceReferenceMapper.java:129) > [wicket-core-6.18.0.jar:6.18.0] > at > > org.apache.wicket.request.mapper.ParentPathReferenceRewriter.mapRequest(ParentPathReferenceRewriter.java:84) > [wicket-request-6.18.0.jar:6.18.0] > at > > org.apache.wicket.request.mapper.CompoundRequestMapper.mapRequest(CompoundRequestMapper.java:152) > [wicket-request-6.18.0.jar:6.18.0] > at > > org.apache.wicket.request.cycle.RequestCycle.resolveRequestHandler(RequestCycle.java:190) > [wicket-core-6.18.0.jar:6.18.0] > at > > org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:215) > [wicket-core-6.18.0.jar:6.18.0] > at > > org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:289) > [wicket-core-6.18.0.jar:6.18.0] > at > > org.apache.wicket.protocol.http.WicketFilter.processRequestCycle(WicketFilter.java:259) > [wicket-core-6.18.0.jar:6.18.0] > at > > org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:201) > [wicket-core-6.18.0.jar:6.18.0] > at > > org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:282) > [wicket-core-6.18.0.jar:6.18.0] > at > > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241) > [tomcat-catalina-7.0.52.jar:7.0.52] > at > > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208) > [tomcat-catalina-7.0.52.jar:7.0.52] > at > > org.soluvas.web.site.servlet.ShiroPrincipalsServletFilter.doFilter(ShiroPrincipalsServletFilter.java:59) > [org.soluvas.web.site-2.2.0-SNAPSHOT.jar:na] > at > > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241) > [tomcat-catalina-7.0.52.jar:7.0.52] > at > > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208) > [tomcat-catalina-7.0.52.jar:7.0.52] > at > > org.soluvas.web.site.servlet.MoreMdcServletFilter.doFilter(MoreMdcServletFilter.java:62) > [org.soluvas.web.site-2.2.0-SNAPSHOT.jar:na] > at > > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241) > [tomcat-catalina-7.0.52.jar:7.0.52] > at > > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208) > [tomcat-catalina-7.0.52.jar:7.0.52] > at > > ch.qos.logback.classic.helpers.MDCInsertingServletFilter.doFilter(MDCInsertingServletFilter.java:51) > [logback-classic-1.1.2.jar:na] > at > > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241) > [tomcat-catalina-7.0.52.jar:7.0.52] > at > > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208) > [tomcat-catalina-7.0.52.jar:7.0.52] > at > > org.apache.shiro.web.servlet.AbstractShiroFilter.executeChain(AbstractShiroFilter.java:449) > [shiro-web-1.2.3.jar:1.2.3
Re: Should I use a (stateless) WebPage or a Resource to return a json response for an autocomplete component?
Hi, I suggest you to use a resource instead of an adapted stateless page. Wicketstuff has a module with special Wicket resources to implement REST api: https://github.com/wicketstuff/core/tree/master/jdk-1.7-parent/wicketstuff-restannotations-parent. Here you can find resources that already produce JSON in output. To configure them you might use a Wicket initializer: http://wicket.apache.org/guide/guide/single.html#advanced_3 Hi all, I am making an autocomplete component based on jquery-autocomplete. I have currently implemented the data source using a stateless web page which writes the json response. What I don't like about this is that it is a separate file/class from my autocomplete component. But I like that it's stateless. Could I achieve the same effect (statelessness) using a dynamic resource registered/created from within the autocomplete component? In other words I want the autocomplete component, upon creation, to register a resource that can be used to serve the autocomplete options. But I want the resource to be stateless and lightweight and the requests to return the autocomplete options should not have to go through the page that contains the autocomplete component. Furthermore, if I have the same autocomplete component twice in a page, the resource should be registered only once and server requests for both components. Is this possible? Can you provide some guidelines? Thanks Marios - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
java.lang.ClassNotFoundException: lowercased class name?
Has anyone ever encountered this error? It confuses me because: 1. It doesn't happen often, but happens a few times a day 2. Only happens on production 3. Pretty much all functionality work fine when tested manually What's weird is the class name is lowercased, i.e. "org.apache.wicket.ajax.form.ajaxformchoicecomponentupdatingbehavior" doesn't exist... but "org.apache.wicket.ajax.form.AjaxFormChoiceComponentUpdatingBehavior" does. Who did the lowercasing? 23:41:01.411 WARN | kalyanitun || -ver-d12e39a9a23f5adefcfe3bfc3d520d68.js msnbot-207-46-13-117.search.msn.com Mozilla/5.0 (compati | -apr-8204-exec-4 | o.a.w.c.u.l.WicketObjects| Could not resolve class [org.apache.wicket.ajax.form.ajaxformchoicecomponentupdatingbehavior] java.lang.ClassNotFoundException: org.apache.wicket.ajax.form.ajaxformchoicecomponentupdatingbehavior at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1718) ~[tomcat-catalina-7.0.52.jar:7.0.52] at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1569) ~[tomcat-catalina-7.0.52.jar:7.0.52] at java.lang.Class.forName0(Native Method) ~[na:1.8.0_25] at java.lang.Class.forName(Class.java:344) ~[na:1.8.0_25] at org.apache.wicket.application.AbstractClassResolver.resolveClass(AbstractClassResolver.java:108) ~[wicket-core-6.18.0.jar:6.18.0] at org.apache.wicket.core.util.lang.WicketObjects.resolveClass(WicketObjects.java:72) ~[wicket-core-6.18.0.jar:6.18.0] at org.apache.wicket.core.request.mapper.BasicResourceReferenceMapper.resolveClass(BasicResourceReferenceMapper.java:153) [wicket-core-6.18.0.jar:6.18.0] at org.apache.wicket.core.request.mapper.BasicResourceReferenceMapper.mapRequest(BasicResourceReferenceMapper.java:129) [wicket-core-6.18.0.jar:6.18.0] at org.apache.wicket.request.mapper.ParentPathReferenceRewriter.mapRequest(ParentPathReferenceRewriter.java:84) [wicket-request-6.18.0.jar:6.18.0] at org.apache.wicket.request.mapper.CompoundRequestMapper.mapRequest(CompoundRequestMapper.java:152) [wicket-request-6.18.0.jar:6.18.0] at org.apache.wicket.request.cycle.RequestCycle.resolveRequestHandler(RequestCycle.java:190) [wicket-core-6.18.0.jar:6.18.0] at org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:215) [wicket-core-6.18.0.jar:6.18.0] at org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:289) [wicket-core-6.18.0.jar:6.18.0] at org.apache.wicket.protocol.http.WicketFilter.processRequestCycle(WicketFilter.java:259) [wicket-core-6.18.0.jar:6.18.0] at org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:201) [wicket-core-6.18.0.jar:6.18.0] at org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:282) [wicket-core-6.18.0.jar:6.18.0] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241) [tomcat-catalina-7.0.52.jar:7.0.52] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208) [tomcat-catalina-7.0.52.jar:7.0.52] at org.soluvas.web.site.servlet.ShiroPrincipalsServletFilter.doFilter(ShiroPrincipalsServletFilter.java:59) [org.soluvas.web.site-2.2.0-SNAPSHOT.jar:na] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241) [tomcat-catalina-7.0.52.jar:7.0.52] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208) [tomcat-catalina-7.0.52.jar:7.0.52] at org.soluvas.web.site.servlet.MoreMdcServletFilter.doFilter(MoreMdcServletFilter.java:62) [org.soluvas.web.site-2.2.0-SNAPSHOT.jar:na] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241) [tomcat-catalina-7.0.52.jar:7.0.52] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208) [tomcat-catalina-7.0.52.jar:7.0.52] at ch.qos.logback.classic.helpers.MDCInsertingServletFilter.doFilter(MDCInsertingServletFilter.java:51) [logback-classic-1.1.2.jar:na] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241) [tomcat-catalina-7.0.52.jar:7.0.52] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208) [tomcat-catalina-7.0.52.jar:7.0.52] at org.apache.shiro.web.servlet.AbstractShiroFilter.executeChain(AbstractShiroFilter.java:449) [shiro-web-1.2.3.jar:1.2.3] at org.apache.shiro.web.servlet.AbstractShiroFilter$1.call(AbstractShiroFilter.java:365) [shiro-web-1.2.3.jar:1.2.3] at org.apache.shiro.subject.support.SubjectCallable.doCall(SubjectCallable.java:90) [shiro-core-1.2.3.jar:1.2.3] at org.apache.shiro.subject.support.SubjectCallable.call(SubjectCallable.java:83) [shiro-core-1.2.3.jar:1.2
Should I use a (stateless) WebPage or a Resource to return a json response for an autocomplete component?
Hi all, I am making an autocomplete component based on jquery-autocomplete. I have currently implemented the data source using a stateless web page which writes the json response. What I don't like about this is that it is a separate file/class from my autocomplete component. But I like that it's stateless. Could I achieve the same effect (statelessness) using a dynamic resource registered/created from within the autocomplete component? In other words I want the autocomplete component, upon creation, to register a resource that can be used to serve the autocomplete options. But I want the resource to be stateless and lightweight and the requests to return the autocomplete options should not have to go through the page that contains the autocomplete component. Furthermore, if I have the same autocomplete component twice in a page, the resource should be registered only once and server requests for both components. Is this possible? Can you provide some guidelines? Thanks Marios
