RE: Update Component on TextField Entry
> use the TextField component and add OnChangeAjaxBehavior to it, then > from inside onEvent() you can repaint the list. And remember to put a WebMarkupContainer around the repeater since repeaters cannot be addressed by Ajax (due to reused markup and resulting synthesized ids). - Tor Iver - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Apache Wicket is a Flawed Framework
On 17/11/11 16:44, Eric Kizaki wrote: Violates MVC: It smashes view and controller code into the same Java file. You have code that regulates page flow and code that changes css attributes in the same file. Even Spring MVC had better separation of concerns. JSP/Servlets with Spring MVC is better. Wicket is NOT based on MVC, so there's nothing to violate :). From Wicket in Action: "Wicket components represent the View and Controller in this pattern (MVC)" Excessively verbose and complicated: What is a LoadableDetachableModel? The learning curve for Wicket is immense. Breaks POJOS: A real POJO does not need to implement an interface or extend a class. Wicket forces your beans to be Serializable. This is like using EJBs in how it forced you to implement interfaces. if you had understood LoadableDetachableModel (or at least used it) you would not say "breaks POJO". Terrible AJAX: Compared to a few lines of jQuery AJAX is excessively complicated and verbose in Wicket. A lot of things like “AJAX” links should not be done via “AJAX” at all. Hiding a div on the client would simply be done with JavaScript on the client. Wicket better not require a server ??! do you know that Wicket is a Java framework and not a JavaScript (client side) library? - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Modal Window respond 404 with Internet Explorer.
Hi. I'm using Wicket 1.5.3. Modal Window respond 404 with Internet Explorer. Stack trace is displayed on the console. This issue does not occur in chrome. What caused the issue? I prepared quickstart. http://d.hatena.ne.jp/sekom/files/wicket153Modal.zip?d=y the stack trace below. WARN - WicketObjects - Could not resolve class [wicket] java.lang.ClassNotFoundException: wicket at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1680) at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1526) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:242) at org.apache.wicket.application.AbstractClassResolver.resolveClass(AbstractClassResolver.java:108) at org.apache.wicket.util.lang.WicketObjects.resolveClass(WicketObjects.java:68) at org.apache.wicket.request.mapper.AbstractComponentMapper.getPageClass(AbstractComponentMapper.java:138) at org.apache.wicket.request.mapper.BookmarkableMapper.parseRequest(BookmarkableMapper.java:110) at org.apache.wicket.request.mapper.AbstractBookmarkableMapper.mapRequest(AbstractBookmarkableMapper.java:263) at org.apache.wicket.request.mapper.CompoundRequestMapper.mapRequest(CompoundRequestMapper.java:130) at org.apache.wicket.request.cycle.RequestCycle.resolveRequestHandler(RequestCycle.java:181) at org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:206) at org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:280) at org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:162) at org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:218) 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:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:859) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:588) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489) at java.lang.Thread.run(Thread.java:595) - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Modal Window respond 404 with Internet Explorer.
Hi, Please create a ticket in Jira and attach the quickstart app there. Thanks! On Fri, Nov 18, 2011 at 11:07 AM, Masaya Seko wrote: > Hi. > I'm using Wicket 1.5.3. > Modal Window respond 404 with Internet Explorer. > Stack trace is displayed on the console. > This issue does not occur in chrome. > > What caused the issue? > > > I prepared quickstart. > http://d.hatena.ne.jp/sekom/files/wicket153Modal.zip?d=y > > > the stack trace below. > WARN - WicketObjects - Could not resolve class [wicket] > java.lang.ClassNotFoundException: wicket > at > org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1680) > at > org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1526) > at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:242) > at > org.apache.wicket.application.AbstractClassResolver.resolveClass(AbstractClassResolver.java:108) > at > org.apache.wicket.util.lang.WicketObjects.resolveClass(WicketObjects.java:68) > at > org.apache.wicket.request.mapper.AbstractComponentMapper.getPageClass(AbstractComponentMapper.java:138) > at > org.apache.wicket.request.mapper.BookmarkableMapper.parseRequest(BookmarkableMapper.java:110) > at > org.apache.wicket.request.mapper.AbstractBookmarkableMapper.mapRequest(AbstractBookmarkableMapper.java:263) > at > org.apache.wicket.request.mapper.CompoundRequestMapper.mapRequest(CompoundRequestMapper.java:130) > at > org.apache.wicket.request.cycle.RequestCycle.resolveRequestHandler(RequestCycle.java:181) > at > org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:206) > at > org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:280) > at > org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:162) > at > org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:218) > 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:233) > at > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) > at > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) > at > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) > at > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) > at > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298) > at > org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:859) > at > org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:588) > at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489) > at java.lang.Thread.run(Thread.java:595) > > > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: wicket 302 redirect loop
Good question. I guess I'll hassle the people at the tomcat users list. It's not a wicket issue as you pointed out. Using ONE_PASS_RENDER is fine as a workaround ... Thanks Willo On Thu, Nov 17, 2011 at 9:47 PM, Igor Vaynberg wrote: > so what do we need to do to fix it on our end? > > -igor > > On Thu, Nov 17, 2011 at 11:34 AM, thomas willomitzer > wrote: > > No I'm afraid ... just tried > > > > On Thu, Nov 17, 2011 at 8:19 PM, Igor Vaynberg >wrote: > > > >> would adding a bogus query param help there? so the url will look like > >> this: localhost/?1&bogus=1 > >> > >> -igor > >> > >> On Thu, Nov 17, 2011 at 10:21 AM, thomas willomitzer > >> wrote: > >> > Fair enough ... > >> > > >> > Looking at org.apache.catalina.connector.Response a url of e.g. > >> > http://localhost/?1 results in a path of length 0 which doesn't > append > >> the > >> > jsessionid. > >> > > >> > if( sb.length() > 0 ) { // jsessionid can't be first. > >> > > >> > It's obviously a tomcat issue ... but given the fact that tomcat is > >> widely > >> > used ... can't we do something about that? > >> > Well I did by using ONE_PASS_RENDER ;) > >> > > >> > Thanks > >> > Willo > >> > > >> >/** > >> > * Return the specified URL with the specified session identifier > >> > * suitably encoded. > >> > * > >> > * @param url URL to be encoded with the session id > >> > * @param sessionId Session id to be included in the encoded URL > >> > */ > >> >protected String toEncoded(String url, String sessionId) { > >> > > >> >if ((url == null) || (sessionId == null)) > >> >return (url); > >> > > >> >String path = url; > >> >String query = ""; > >> >String anchor = ""; > >> >int question = url.indexOf('?'); > >> >if (question >= 0) { > >> >path = url.substring(0, question); > >> >query = url.substring(question); > >> >} > >> >int pound = path.indexOf('#'); > >> >if (pound >= 0) { > >> >anchor = path.substring(pound); > >> >path = path.substring(0, pound); > >> >} > >> >StringBuilder sb = new StringBuilder(path); > >> >if( sb.length() > 0 ) { // jsessionid can't be first. > >> >sb.append(";"); > >> > > >> sb.append(ApplicationSessionCookieConfig.getSessionUriParamName( > >> >request.getContext())); > >> >sb.append("="); > >> >sb.append(sessionId); > >> >} > >> >sb.append(anchor); > >> >sb.append(query); > >> >return (sb.toString()); > >> > > >> >} > >> > > >> > > >> > On Thu, Nov 17, 2011 at 6:52 PM, Igor Vaynberg < > igor.vaynb...@gmail.com > >> >wrote: > >> > > >> >> as long as we are passing the /?1 url through > >> >> servletresponse#encoderedirecturl() tomcat is responsible for > >> >> appending the JSESSIONID if its not yet available in a cookie... > >> >> > >> >> -igor > >> >> > >> >> On Thu, Nov 17, 2011 at 2:16 AM, thomas willomitzer > >> wrote: > >> >> > Hi, > >> >> > > >> >> > Thanks for the advice! I follwed and traced the problem. Think > it's a > >> >> > combination of Wicket and Tomcat... > >> >> > > >> >> > When i send the request for http://localhost/, wicket get's the > >> session > >> >> > from tomcat, renders the page and buffers the response (since > >> >> > ONE_PASS_RENDER isn't default). > >> >> > Wicket (1.5.3) also appends the ?1 and sends a 302 redirect to > >> >> > http://localhost/?1 (in the 302 response header the cookie get's > >> >> correctly > >> >> > set - but not appended to the redirect URL). > >> >> > Tomcat (7.0.22) doesn't append jsessionid to an url like > >> >> http://localhost/?1. > >> >> > Looks like it's still the "empty path" and tomcat problem that > >> prohibits > >> >> > the appending of jsessionid. > >> >> > > >> >> > Now when I don't use cookies and follow the request to > >> >> > http://localhost/?1how should wicket know which session we're > talking > >> >> > about? > >> >> > > >> >> > Please note that this problem doesn't exist when sending a request > to > >> >> e.g. > >> >> > http://localhost/login. I get a correct redirect to > >> >> > http://localhost/login;jsessionid=xx. > >> >> > > >> >> > I could think of the following "workaround": > >> >> > 1.) For the homepage use ONE_PASS_RENDER > >> >> > > >> >> > Is this a tomcat/wicket combination problem or am I doing something > >> >> wrong? > >> >> > > >> >> > Many thanks > >> >> > Willo > >> >> > > >> >> > On Wed, Nov 16, 2011 at 7:57 PM, Bertrand Guay-Paquet < > >> >> > ber...@step.polymtl.ca> wrote: > >> >> > > >> >> >> I don't know of any other specific causes unfortunately... > >> >> >> > >> >> >> Try setting a breakpoint in RequestCycle#onBeginRequest() and see > >> what > >> >> >> happens. Try your page constructor too since it might be closer to > >> the > >> >> >> source of the problem. > >> >> >> > >> >> >> Good luck! > >> >> >> Bertrand > >> >> >> > >> >> >
RE: Wicket 1.5.2, stalls on one tomcat
We have this problem with an application connecting to MS SQL Server. It seems that the applications stalls upon connecting to the database. This issue has been reported: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7105007. We had to revert to jdk 1.6_u25 to make it work. Java 7 works as well. Not sure if this is the same issue though... Hielke -Original Message- From: nino martinez wael [mailto:nino.martinez.w...@gmail.com] Sent: vrijdag 18 november 2011 8:20 To: users@wicket.apache.org Subject: Re: Wicket 1.5.2, stalls on one tomcat So I digged into this and discovered something strange. On the server that was working it had jre 6u24 and on the one not working it had jre 6u29. I could'nt restart the server, but after installing jdk 6u25 it actually worked.. This is not good. It could prove hard to replicate with other framework stacks, Im using a combo of mybatis, guice 3, wicket 1.5.3.. Anybody else using this on jre 6u29 on tomcat 7? regards Nino 2011/11/17 nino martinez wael > THANKS! > > > 2011/11/17 Andrea Del Bene > >> Profile the stalled server with Visual VM? It should detect existing >> deadlocks... >> >>> Hi >>> >>> I have a very strange problem. At a customers site we have 2 servers >>> with 1 Tomcat 7 installed each. One day on one of the servers our >>> application just stalled after loading the sign in page, when you >>> click the login button. >>> Im >>> not sure this is a wicket problem. Heres what I've tried so far: >>> >>> >>>- Restart Tomcat >>>- Point the working application at the non working servers sql >>> database, >>>it still works. >>>- Purge Tomcats session storage and temporary files >>>- Restart the server >>>- Redeploy the application, with the war from the working server >>> (just >>> >>>to be sure) >>> >>> I've even tried setting up SQL Profiler and sniffing on the database >>> connections, nothing strange goes on here. Just seems like the >>> application stalls when you try to login. Keep in mind that this >>> works without problems from the other server. >>> >>> >>> >>> regards Nino >>> >>> >> >> --**--**- >> To unsubscribe, e-mail: >> users-unsubscribe@wicket.**apache.org> .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: wicket 302 redirect loop
On Fri, Nov 18, 2011 at 11:10 AM, thomas willomitzer wrote: > Good question. I guess I'll hassle the people at the tomcat users list. > It's not a wicket issue as you pointed out. > Using ONE_PASS_RENDER is fine as a workaround ... Another workaround is to use a filter path, i.e. WicketFilter to listen at /app/* instead of /*. But this issue looks like https://issues.apache.org/jira/browse/WICKET-3841 and this problem has been fixed in Tomcat 7.0.18 > > Thanks > Willo > > On Thu, Nov 17, 2011 at 9:47 PM, Igor Vaynberg wrote: > >> so what do we need to do to fix it on our end? >> >> -igor >> >> On Thu, Nov 17, 2011 at 11:34 AM, thomas willomitzer >> wrote: >> > No I'm afraid ... just tried >> > >> > On Thu, Nov 17, 2011 at 8:19 PM, Igor Vaynberg > >wrote: >> > >> >> would adding a bogus query param help there? so the url will look like >> >> this: localhost/?1&bogus=1 >> >> >> >> -igor >> >> >> >> On Thu, Nov 17, 2011 at 10:21 AM, thomas willomitzer >> >> wrote: >> >> > Fair enough ... >> >> > >> >> > Looking at org.apache.catalina.connector.Response a url of e.g. >> >> > http://localhost/?1 results in a path of length 0 which doesn't >> append >> >> the >> >> > jsessionid. >> >> > >> >> > if( sb.length() > 0 ) { // jsessionid can't be first. >> >> > >> >> > It's obviously a tomcat issue ... but given the fact that tomcat is >> >> widely >> >> > used ... can't we do something about that? >> >> > Well I did by using ONE_PASS_RENDER ;) >> >> > >> >> > Thanks >> >> > Willo >> >> > >> >> > /** >> >> > * Return the specified URL with the specified session identifier >> >> > * suitably encoded. >> >> > * >> >> > * @param url URL to be encoded with the session id >> >> > * @param sessionId Session id to be included in the encoded URL >> >> > */ >> >> > protected String toEncoded(String url, String sessionId) { >> >> > >> >> > if ((url == null) || (sessionId == null)) >> >> > return (url); >> >> > >> >> > String path = url; >> >> > String query = ""; >> >> > String anchor = ""; >> >> > int question = url.indexOf('?'); >> >> > if (question >= 0) { >> >> > path = url.substring(0, question); >> >> > query = url.substring(question); >> >> > } >> >> > int pound = path.indexOf('#'); >> >> > if (pound >= 0) { >> >> > anchor = path.substring(pound); >> >> > path = path.substring(0, pound); >> >> > } >> >> > StringBuilder sb = new StringBuilder(path); >> >> > if( sb.length() > 0 ) { // jsessionid can't be first. >> >> > sb.append(";"); >> >> > >> >> sb.append(ApplicationSessionCookieConfig.getSessionUriParamName( >> >> > request.getContext())); >> >> > sb.append("="); >> >> > sb.append(sessionId); >> >> > } >> >> > sb.append(anchor); >> >> > sb.append(query); >> >> > return (sb.toString()); >> >> > >> >> > } >> >> > >> >> > >> >> > On Thu, Nov 17, 2011 at 6:52 PM, Igor Vaynberg < >> igor.vaynb...@gmail.com >> >> >wrote: >> >> > >> >> >> as long as we are passing the /?1 url through >> >> >> servletresponse#encoderedirecturl() tomcat is responsible for >> >> >> appending the JSESSIONID if its not yet available in a cookie... >> >> >> >> >> >> -igor >> >> >> >> >> >> On Thu, Nov 17, 2011 at 2:16 AM, thomas willomitzer >> >> wrote: >> >> >> > Hi, >> >> >> > >> >> >> > Thanks for the advice! I follwed and traced the problem. Think >> it's a >> >> >> > combination of Wicket and Tomcat... >> >> >> > >> >> >> > When i send the request for http://localhost/, wicket get's the >> >> session >> >> >> > from tomcat, renders the page and buffers the response (since >> >> >> > ONE_PASS_RENDER isn't default). >> >> >> > Wicket (1.5.3) also appends the ?1 and sends a 302 redirect to >> >> >> > http://localhost/?1 (in the 302 response header the cookie get's >> >> >> correctly >> >> >> > set - but not appended to the redirect URL). >> >> >> > Tomcat (7.0.22) doesn't append jsessionid to an url like >> >> >> http://localhost/?1. >> >> >> > Looks like it's still the "empty path" and tomcat problem that >> >> prohibits >> >> >> > the appending of jsessionid. >> >> >> > >> >> >> > Now when I don't use cookies and follow the request to >> >> >> > http://localhost/?1how should wicket know which session we're >> talking >> >> >> > about? >> >> >> > >> >> >> > Please note that this problem doesn't exist when sending a request >> to >> >> >> e.g. >> >> >> > http://localhost/login. I get a correct redirect to >> >> >> > http://localhost/login;jsessionid=xx. >> >> >> > >> >> >> > I could think of the following "workaround": >> >> >> > 1.) For the homepage use ONE_PASS_RENDER >> >> >> > >> >> >> > Is this a tomcat/wicket combination problem or am I doing something >> >> >> wrong? >> >> >> > >> >> >> > Many thanks >> >> >> > Willo >> >> >> > >> >> >> > On Wed, Nov 16, 2011 at 7:57 PM, Bertra
RE: Apache Wicket is a Flawed Framework
>Breaks POJOS: A real POJO does not need to implement an interface or >extend a class. A object oriented framework is a foundation on which you extend your application. Back in the C++ world there was MFC, OWL, .Net, etc., In the Java world there was AWT and then Swing etc.,. All event driven, object oriented component based frameworks. All were pretty easy to build desktop applications in. Most of an application's UI elements extended from core classes in the framework. That's just how you use OO frameworks. If you want to write UI elements that do not extend or implement classes of interfaces of a 'framework' then you're not really using any framework and reinventing the wheel. >Bad Defaults: Most pages are stateless. Every page in our app is stateful. We show the username of the current user at the top of the page after logging on and we also have a panel on the right that shows alerts specific to the current user. Sure the main content of each page is not delivered differently per user but many of the auxiliary components are. >Causes a redeploy whenever you add anything: Maybe Java developers are >used to this, but in any other web development environment I do not need to >redeploy after adding a text box to the page. We use a component resolver. That can make it possible for the HTML markup to drive the component hierarchy without explicitly adding components in Java code each time you want to add a new component. >Stateful Component based framework are a terrible idea: Even at the >theoretical level this is a bad idea. It is a leaky abstraction over a >simple request/response cycle. My examples of desktop app frameworks above were all event driven, object oriented, component based frameworks. This model evolved to be *universal* in the desktop world for a good reason - it's a damn fine architecture IMHO and obviously in the opinion of the rest of the world of desktop application developers. Einstein said, "Make something as simple as possible but not too simple". Request/response is just too simple to be useful for anyone who has come through from the desktop application world and 'gets' event driven, object oriented component based architectures. When I moved from desktop to web development I went CGI, servlets, JSPs, Struts, Echo and now Wicket. Until I started using Echo & Wicket my web app days were never as fun or 'clean' as ye olde desktop app days. For me Wicket is the ONLY web UI framework that gives me the same kind of development productivity and clean, reusable application source code that I enjoyed in the desktop app development world. >It made something simple and made it overly complicated. This remind me of Hibernate and ORMS. Yeah, ok, if you're not using an ORM in your apps by now and still spending your days writing SQL glue code then we need to have a talk ;) Chris - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: wicket 302 redirect loop
Thanks Martin, Guess the tomcat people forgot to put that into 7.0.18 - I'm using 7.0.22 and still have the problem. On Fri, Nov 18, 2011 at 10:16 AM, Martin Grigorov wrote: > On Fri, Nov 18, 2011 at 11:10 AM, thomas willomitzer > wrote: > > Good question. I guess I'll hassle the people at the tomcat users list. > > It's not a wicket issue as you pointed out. > > Using ONE_PASS_RENDER is fine as a workaround ... > > Another workaround is to use a filter path, i.e. WicketFilter to > listen at /app/* instead of /*. > But this issue looks like > https://issues.apache.org/jira/browse/WICKET-3841 and this problem has > been fixed in Tomcat 7.0.18 > > > > > Thanks > > Willo > > > > On Thu, Nov 17, 2011 at 9:47 PM, Igor Vaynberg >wrote: > > > >> so what do we need to do to fix it on our end? > >> > >> -igor > >> > >> On Thu, Nov 17, 2011 at 11:34 AM, thomas willomitzer > >> wrote: > >> > No I'm afraid ... just tried > >> > > >> > On Thu, Nov 17, 2011 at 8:19 PM, Igor Vaynberg < > igor.vaynb...@gmail.com > >> >wrote: > >> > > >> >> would adding a bogus query param help there? so the url will look > like > >> >> this: localhost/?1&bogus=1 > >> >> > >> >> -igor > >> >> > >> >> On Thu, Nov 17, 2011 at 10:21 AM, thomas willomitzer > >> >> wrote: > >> >> > Fair enough ... > >> >> > > >> >> > Looking at org.apache.catalina.connector.Response a url of e.g. > >> >> > http://localhost/?1 results in a path of length 0 which doesn't > >> append > >> >> the > >> >> > jsessionid. > >> >> > > >> >> > if( sb.length() > 0 ) { // jsessionid can't be first. > >> >> > > >> >> > It's obviously a tomcat issue ... but given the fact that tomcat is > >> >> widely > >> >> > used ... can't we do something about that? > >> >> > Well I did by using ONE_PASS_RENDER ;) > >> >> > > >> >> > Thanks > >> >> > Willo > >> >> > > >> >> >/** > >> >> > * Return the specified URL with the specified session > identifier > >> >> > * suitably encoded. > >> >> > * > >> >> > * @param url URL to be encoded with the session id > >> >> > * @param sessionId Session id to be included in the encoded URL > >> >> > */ > >> >> >protected String toEncoded(String url, String sessionId) { > >> >> > > >> >> >if ((url == null) || (sessionId == null)) > >> >> >return (url); > >> >> > > >> >> >String path = url; > >> >> >String query = ""; > >> >> >String anchor = ""; > >> >> >int question = url.indexOf('?'); > >> >> >if (question >= 0) { > >> >> >path = url.substring(0, question); > >> >> >query = url.substring(question); > >> >> >} > >> >> >int pound = path.indexOf('#'); > >> >> >if (pound >= 0) { > >> >> >anchor = path.substring(pound); > >> >> >path = path.substring(0, pound); > >> >> >} > >> >> >StringBuilder sb = new StringBuilder(path); > >> >> >if( sb.length() > 0 ) { // jsessionid can't be first. > >> >> >sb.append(";"); > >> >> > > >> >> sb.append(ApplicationSessionCookieConfig.getSessionUriParamName( > >> >> >request.getContext())); > >> >> >sb.append("="); > >> >> >sb.append(sessionId); > >> >> >} > >> >> >sb.append(anchor); > >> >> >sb.append(query); > >> >> >return (sb.toString()); > >> >> > > >> >> >} > >> >> > > >> >> > > >> >> > On Thu, Nov 17, 2011 at 6:52 PM, Igor Vaynberg < > >> igor.vaynb...@gmail.com > >> >> >wrote: > >> >> > > >> >> >> as long as we are passing the /?1 url through > >> >> >> servletresponse#encoderedirecturl() tomcat is responsible for > >> >> >> appending the JSESSIONID if its not yet available in a cookie... > >> >> >> > >> >> >> -igor > >> >> >> > >> >> >> On Thu, Nov 17, 2011 at 2:16 AM, thomas willomitzer < > wi...@test.at> > >> >> wrote: > >> >> >> > Hi, > >> >> >> > > >> >> >> > Thanks for the advice! I follwed and traced the problem. Think > >> it's a > >> >> >> > combination of Wicket and Tomcat... > >> >> >> > > >> >> >> > When i send the request for http://localhost/, wicket get's the > >> >> session > >> >> >> > from tomcat, renders the page and buffers the response (since > >> >> >> > ONE_PASS_RENDER isn't default). > >> >> >> > Wicket (1.5.3) also appends the ?1 and sends a 302 redirect to > >> >> >> > http://localhost/?1 (in the 302 response header the cookie > get's > >> >> >> correctly > >> >> >> > set - but not appended to the redirect URL). > >> >> >> > Tomcat (7.0.22) doesn't append jsessionid to an url like > >> >> >> http://localhost/?1. > >> >> >> > Looks like it's still the "empty path" and tomcat problem that > >> >> prohibits > >> >> >> > the appending of jsessionid. > >> >> >> > > >> >> >> > Now when I don't use cookies and follow the request to > >> >> >> > http://localhost/?1how should wicket know which session we're > >> talking > >> >> >> > about? > >> >> >> > > >> >> >> > Please note that this problem doesn't exist when
Re: Modal Window respond 404 with Internet Explorer.
Hi. I created WICKET-4241 ticket. I wait for fix. Thanks. --- On Fri, 2011/11/18, Martin Grigorov wrote: > Hi, > > Please create a ticket in Jira and attach the quickstart app there. > Thanks! > > On Fri, Nov 18, 2011 at 11:07 AM, Masaya Seko wrote: > > Hi. > > I'm using Wicket 1.5.3. > > Modal Window respond 404 with Internet Explorer. > > Stack trace is displayed on the console. > > This issue does not occur in chrome. > > > > What caused the issue? > > > > > > I prepared quickstart. > > http://d.hatena.ne.jp/sekom/files/wicket153Modal.zip?d=y > > > > > > the stack trace below. > > WARN - WicketObjects - Could not resolve class [wicket] > > java.lang.ClassNotFoundException: wicket > > at > > org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1680) > > at > > org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1526) > > at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320) > > at java.lang.Class.forName0(Native Method) > > at java.lang.Class.forName(Class.java:242) > > at > > org.apache.wicket.application.AbstractClassResolver.resolveClass(AbstractClassResolver.java:108) > > at > > org.apache.wicket.util.lang.WicketObjects.resolveClass(WicketObjects.java:68) > > at > > org.apache.wicket.request.mapper.AbstractComponentMapper.getPageClass(AbstractComponentMapper.java:138) > > at > > org.apache.wicket.request.mapper.BookmarkableMapper.parseRequest(BookmarkableMapper.java:110) > > at > > org.apache.wicket.request.mapper.AbstractBookmarkableMapper.mapRequest(AbstractBookmarkableMapper.java:263) > > at > > org.apache.wicket.request.mapper.CompoundRequestMapper.mapRequest(CompoundRequestMapper.java:130) > > at > > org.apache.wicket.request.cycle.RequestCycle.resolveRequestHandler(RequestCycle.java:181) > > at > > org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:206) > > at > > org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:280) > > at > > org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:162) > > at > > org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:218) > > 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:233) > > at > > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) > > at > > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) > > at > > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) > > at > > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) > > at > > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298) > > at > > org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:859) > > at > > org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:588) > > at > > org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489) > > at java.lang.Thread.run(Thread.java:595) > > > > > > > > - > > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > > For additional commands, e-mail: users-h...@wicket.apache.org > > > > > > > > -- > Martin Grigorov > jWeekend > Training, Consulting, Development > http://jWeekend.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: Apache Wicket is a Flawed Framework
well, I have nothing against writing my own SQL with spring;] but it is true that before I read wicket in action I was like a child in fog :/ after JSP I started palying with tapestry and tapestry has a bit better introduction pages. it is not that there is not enough information around but wicket lacks free introduction that shows the wicket way (but maybe I could not find it). looking at wicket stuff is hard at the beginning. I tried vaadin and tapestry and I still find wicket as very nice framework anyway I would never ever go back to JSP ;] pozdrawiam Paweł Kamiński kami...@gmail.com pkaminski@gmail.com __ On 18 November 2011 10:35, Chris Colman wrote: >>Breaks POJOS: A real POJO does not need to implement an interface or >>extend a class. > > A object oriented framework is a foundation on which you extend your > application. Back in the C++ world there was MFC, OWL, .Net, etc., In > the Java world there was AWT and then Swing etc.,. All event driven, > object oriented component based frameworks. All were pretty easy to > build desktop applications in. > > Most of an application's UI elements extended from core classes in the > framework. That's just how you use OO frameworks. If you want to write > UI elements that do not extend or implement classes of interfaces of a > 'framework' then you're not really using any framework and reinventing > the wheel. > >>Bad Defaults: Most pages are stateless. > > Every page in our app is stateful. We show the username of the current > user at the top of the page after logging on and we also have a panel on > the right that shows alerts specific to the current user. Sure the main > content of each page is not delivered differently per user but many of > the auxiliary components are. > >>Causes a redeploy whenever you add anything: Maybe Java developers are >>used to this, but in any other web development environment I do not > need to >>redeploy after adding a text box to the page. > > We use a component resolver. That can make it possible for the HTML > markup to drive the component hierarchy without explicitly adding > components in Java code each time you want to add a new component. > >>Stateful Component based framework are a terrible idea: Even at the >>theoretical level this is a bad idea. It is a leaky abstraction over a >>simple request/response cycle. > > My examples of desktop app frameworks above were all event driven, > object oriented, component based frameworks. This model evolved to be > *universal* in the desktop world for a good reason - it's a damn fine > architecture IMHO and obviously in the opinion of the rest of the world > of desktop application developers. > > Einstein said, "Make something as simple as possible but not too > simple". Request/response is just too simple to be useful for anyone who > has come through from the desktop application world and 'gets' event > driven, object oriented component based architectures. > > When I moved from desktop to web development I went CGI, servlets, JSPs, > Struts, Echo and now Wicket. Until I started using Echo & Wicket my web > app days were never as fun or 'clean' as ye olde desktop app days. For > me Wicket is the ONLY web UI framework that gives me the same kind of > development productivity and clean, reusable application source code > that I enjoyed in the desktop app development world. > > >>It made something simple and made it overly complicated. This remind > me of Hibernate and ORMS. > > Yeah, ok, if you're not using an ORM in your apps by now and still > spending your days writing SQL glue code then we need to have a talk ;) > > Chris > > - > 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: AjaxLazyLoadPanel question
Great, it's working. Thanks for the quick response, Philip 2011/11/17 Igor Vaynberg > you can replace the lazy load panel instance: > > //check other selections > myLazyLoadPanel=myLazyLoadPanel.replaceWith(new > MyLazyLoadPanel(myLazyLoadPanel.getId(), ..) > target.addComponent(myLazyLoadPanel); > > this will reset the state of lazyloadpanel to the "not-yet-loaded" > > -igor > > On Thu, Feb 3, 2011 at 11:40 AM, Matt Schmidt > wrote: > > I currently have a DataGridView loaded inside of an AjaxLazyLoadPanel, > > including the service call to get the data. > > > > myLazyLoadPanel = new AjaxLazyLoadPanel("id", new > CollectionModel()) { > >public Component getLazyLoadComponent(String markupId) { > >if(getDefaultModelObject() == null) { > >setDefaultModelObject(myPojoService.readAll()); > >} > >return new MyDataGridView(markupId, getDefaultModel()); //ignoring > > casting for simplicity > >} > > } > > > > That works great for loading the page before the service call is > complete. > > > > But now I need to add a DropDownChoice to change the collection in the > data > > grid via Ajax after the page is loaded. Is there anyway to get the > > DataGridView to be replaced with an Ajax indicator (like on page load) > > during an Ajax "onchange" event for the DropDownChoice? I've added an > Ajax > > indicator to the DropDownChoice, but I would like the same behavior I > get on > > page load for the AjaxLazyLoadPanel. > > > > This is what I have for the drop down for starters: > > > > myDropDownChoice.add(new AjaxFormComponentUpdateBehavior("onchange") { > >protected void onUpdate(AjaxRequestTarget target) { > >if(myDropDownChoice.getModelObject().equals(foo)) { > > > myLazyLoadPanel.setDefaultModelObject(myPojoService.readFoo()); > >} > >//check other selections > > target.addComponent(myLazyLoadPanel); > >} > > } > > > > I may be looking at this entirely wrong... Any suggestions? > > > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
Re: Apache Wicket is a Flawed Framework
Hi, On Fri, 18 Nov 2011 11:04:39 +0100 kamiseq wrote: K> but it is true that before I read wicket in action I was like a K> child in fog :/ I totally agree with that. I'm just starting with wicket and without the book I think I would have dumped it because there is not much free documentation. Although I find most other web frameworks suffer in that region too. ;-) Regards -- 18. Nebelung 2011, 11:36 Homepage : http://www.jan0sch.de Right now I'm having amnesia and deja vu at the same time. -- Steven Wright pgpmQcvPd0RKP.pgp Description: PGP signature
Button with 3 images and issues
Hello everybody, I am starting a wicket project for the first time, and I created a button made of 3 images with html css. Here is my html : I want this button to be disableable. In Java, I only declare 1 AjaxButton, which is linked to the button tag. When I use setEnabled(false), it only adds the disabled tag to the button tag. I would need to add the disabled tag to the 2 other spans. While searching for an answer, I realized I could either create a custom component or add a behavior to automatically add the markup necessary to create this button. Thus, in my html I would only write : And all the class and span stuff would be added by wicket. However I have no idea how to do that. beforeRender and afterRender add markup before and after if I understood correctly, and onComponentTag adds attributes. It would be great if you could provide links or hints on how to do that. Thanks in advance. Florian -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Button-with-3-images-and-issues-tp4082830p4082830.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
Ajax busy indicator getting stuck
Hi, I have added a global ajax indicator to all my pages by having all pages (through a TemplatePage superclass) implement the IAjaxIndicatorAware interface. Generally it works, but I have noticed that it is quite easy to get the ajax indicator stuck spinning indefinitely, by issuing many ajax calls quickly the one after the other. For example if I press an ajax button multiple times quickly the busy indicator gets stuck. It seems as if the Wicket.show(hide)Incrementally js functions lose count of ajax requests and the busy indicator is never actually hidden. Has anyone encountered this problem? Thanks a lot Naz - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Ajax busy indicator getting stuck
I have also noticed that with 1.5.3... I normally block the page with div to prevent this but for links on a modal window it happens to me (because blocking div is behind modal). Regards, Ernesto On Fri, Nov 18, 2011 at 11:53 AM, Nazaret Kazarian wrote: > Hi, > > I have added a global ajax indicator to all my pages by having all > pages (through a TemplatePage superclass) implement the > IAjaxIndicatorAware interface. > > Generally it works, but I have noticed that it is quite easy to get > the ajax indicator stuck spinning indefinitely, by issuing many ajax > calls quickly the one after the other. For example if I press an ajax > button multiple times quickly the busy indicator gets stuck. > It seems as if the Wicket.show(hide)Incrementally js functions lose > count of ajax requests and the busy indicator is never actually > hidden. > > Has anyone encountered this problem? > > Thanks a lot > > Naz > > - > 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: Ajax busy indicator getting stuck
On Fri, Nov 18, 2011 at 12:59 PM, Ernesto Reinaldo Barreiro wrote: > I have also noticed that with 1.5.3... I normally block the page with > div to prevent this but for links on a modal window it happens to me > (because blocking div is behind modal). And you didn't experience this with 1.5.2 ? Maybe https://issues.apache.org/jira/browse/WICKET-4071 is involved ? > > Regards, > > Ernesto > > On Fri, Nov 18, 2011 at 11:53 AM, Nazaret Kazarian > wrote: >> Hi, >> >> I have added a global ajax indicator to all my pages by having all >> pages (through a TemplatePage superclass) implement the >> IAjaxIndicatorAware interface. >> >> Generally it works, but I have noticed that it is quite easy to get >> the ajax indicator stuck spinning indefinitely, by issuing many ajax >> calls quickly the one after the other. For example if I press an ajax >> button multiple times quickly the busy indicator gets stuck. >> It seems as if the Wicket.show(hide)Incrementally js functions lose >> count of ajax requests and the busy indicator is never actually >> hidden. >> >> Has anyone encountered this problem? >> >> Thanks a lot >> >> Naz >> >> - >> 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 > > -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
RE: Apache Wicket is a Flawed Framework
If you come here and try to start a flame about how bad Wicket is while you obviously have no clue how it works then atleast have the decency to write a propert post instead of a lame list of cons (and no pros) and a oneliner saying Spring MVC is the only other option... Hielke -Original Message- From: Eric Kizaki [mailto:erickiz...@gmail.com] Sent: donderdag 17 november 2011 16:45 To: users@wicket.apache.org Subject: Apache Wicket is a Flawed Framework Violates Dry: You must repeat the component hierarchy of your widgets that are in HTML in Java Code for no good reason. If you move your widget around in the html it will break the Java and you get a stack trace if you change the nesting. You have to keep these two files synched. A JSP file is more maintainable. At least the view code is in one place. Not previewable: One of the supposed benefits of Wicket is a clean template that could make pages previewable for designers. First, we don't have seperate designers at my company. Second, it is better if the samer person does development and design. Third, if you use extends your page will not be priviewable outside an application server running Wicket. This supposed benefit does not exist. Violates MVC: It smashes view and controller code into the same Java file. You have code that regulates page flow and code that changes css attributes in the same file. Even Spring MVC had better separation of concerns. JSP/Servlets with Spring MVC is better. Excessively verbose and complicated: What is a LoadableDetachableModel? The learning curve for Wicket is immense. Breaks POJOS: A real POJO does not need to implement an interface or extend a class. Wicket forces your beans to be Serializable. This is like using EJBs in how it forced you to implement interfaces. Terrible AJAX: Compared to a few lines of jQuery AJAX is excessively complicated and verbose in Wicket. A lot of things like “AJAX” links should not be done via “AJAX” at all. Hiding a div on the client would simply be done with JavaScript on the client. Wicket better not require a server request for that. You also have no JSON support and good luck debugging any JavaScript or AJAX in Firefox. Instead you have to use the subpar Wicket debugging. HTML5: No support for HTML 5 form elements unless you upgrade to Wicket 1.5. You will get a stack trace. The upgrade to Wicket 1.5 is painful and will break your code. Good luck getting this to work with jQuery mobile. Bad Defaults: Most pages are stateless. The default for Wicket is stateful. So if I want a decent URL and a bookmarkable page I have to mount the page and use a bookmarkable page link with page parameters. Using page parameters is worse than how Spring MVC does binding. I have to keep doing this over and over for each page. There is too much work involved to get a decent stateless page with a nice URL. This should be the default. Interferes with other libraries: It screws up your jQuery code. It forces you into a restrictive way of doing web-development: the Wicket Way. Causes a redeploy whenever you add anything: Maybe Java developers are used to this, but in any other web development environment I do not need to redeploy after adding a text box to the page. It is completely absurd. Only with JRebel is this alleviated. No, embedded Jetty in debug mode still slow. Even a simple JSP file has hot reloading on Tomcat and if I make a change to my view code the changes are immediately viewable in the browser when I refresh. This is WITHOUT JRebel. HTTPSession Objects are not hard: Most pages do not need state. If you do use HTTPSession it is simple. Can you use a map? Then you can use HTTPSession. This is less comlicated than most Wicket code. Stateful Component based framework are a terrible idea: Even at the theoretical level this is a bad idea. It is a leaky abstraction over a simple request/response cycle. It made something simple and made it overly complicated. This remind me of Hibernate and ORMS. I disagree that we should abstract things to this level and do everything in verbose Java. People are dropping Hibernate and going back to native SQL and Spring JDBC template. SQL and the relational model are easy. Working with HTTP requests is easy too. What was wrong with JSPs/Servlets? Keep it simple stupid. We know JSF was too complicated and it was terrible. Spring MVC is better and has rest support. It just works with Spring and has great support for the JSON Jackson mapper. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Apache-Wicket-is-a-Flawed-Framework-tp4080411p4080411.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: Ajax busy indicator getting stuck
Martin, Before switching to 1.5.3 I was working with 1.5.x trunk and I think it was the same there... but I can´t say that assertion is 100% true. As said in my case this happens to me on a modal window because my indicator panel blocks the UI and that blocking div is behind the modal. It should not be very difficult to produce a quick-start for this issue (I guess). Best regards, Ernesto On Fri, Nov 18, 2011 at 12:02 PM, Martin Grigorov wrote: > On Fri, Nov 18, 2011 at 12:59 PM, Ernesto Reinaldo Barreiro > wrote: >> I have also noticed that with 1.5.3... I normally block the page with >> div to prevent this but for links on a modal window it happens to me >> (because blocking div is behind modal). > > And you didn't experience this with 1.5.2 ? > Maybe https://issues.apache.org/jira/browse/WICKET-4071 is involved ? > >> >> Regards, >> >> Ernesto >> >> On Fri, Nov 18, 2011 at 11:53 AM, Nazaret Kazarian >> wrote: >>> Hi, >>> >>> I have added a global ajax indicator to all my pages by having all >>> pages (through a TemplatePage superclass) implement the >>> IAjaxIndicatorAware interface. >>> >>> Generally it works, but I have noticed that it is quite easy to get >>> the ajax indicator stuck spinning indefinitely, by issuing many ajax >>> calls quickly the one after the other. For example if I press an ajax >>> button multiple times quickly the busy indicator gets stuck. >>> It seems as if the Wicket.show(hide)Incrementally js functions lose >>> count of ajax requests and the busy indicator is never actually >>> hidden. >>> >>> Has anyone encountered this problem? >>> >>> Thanks a lot >>> >>> Naz >>> >>> - >>> 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 >> >> > > > > -- > Martin Grigorov > jWeekend > Training, Consulting, Development > http://jWeekend.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: Ajax busy indicator getting stuck
I'm sorry I forgot to mention that I am using version 1.4.19 With a little reverse engineering I noticed that maybe one of the cases this happens is this: an ajax button is pressed, showIncrementally is executed, but the actual ajax request is postponed because its channel is busy. When the time comes to actually execute the request, the request is stopped because of precondition check, and thus hideIncrementally is never called. This loses the count. A fix might be to call hideIncrementally when the ajax request precondition is not met. As to why the precondition is not met, I am guessing it's because the previous ajax request did DOM replacement in a way that the precondition of the queued request is no longer met. 2011/11/18 Ernesto Reinaldo Barreiro : > Martin, > > Before switching to 1.5.3 I was working with 1.5.x trunk and I think > it was the same there... but I can´t say that assertion is 100% true. > > As said in my case this happens to me on a modal window because my > indicator panel blocks the UI and that blocking div is behind the > modal. It should not be very difficult to produce a quick-start for > this issue (I guess). > > Best regards, > > Ernesto > > On Fri, Nov 18, 2011 at 12:02 PM, Martin Grigorov > wrote: >> On Fri, Nov 18, 2011 at 12:59 PM, Ernesto Reinaldo Barreiro >> wrote: >>> I have also noticed that with 1.5.3... I normally block the page with >>> div to prevent this but for links on a modal window it happens to me >>> (because blocking div is behind modal). >> >> And you didn't experience this with 1.5.2 ? >> Maybe https://issues.apache.org/jira/browse/WICKET-4071 is involved ? >> >>> >>> Regards, >>> >>> Ernesto >>> >>> On Fri, Nov 18, 2011 at 11:53 AM, Nazaret Kazarian >>> wrote: Hi, I have added a global ajax indicator to all my pages by having all pages (through a TemplatePage superclass) implement the IAjaxIndicatorAware interface. Generally it works, but I have noticed that it is quite easy to get the ajax indicator stuck spinning indefinitely, by issuing many ajax calls quickly the one after the other. For example if I press an ajax button multiple times quickly the busy indicator gets stuck. It seems as if the Wicket.show(hide)Incrementally js functions lose count of ajax requests and the busy indicator is never actually hidden. Has anyone encountered this problem? Thanks a lot Naz - 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 >>> >>> >> >> >> >> -- >> Martin Grigorov >> jWeekend >> Training, Consulting, Development >> http://jWeekend.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 > > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Ajax busy indicator getting stuck
Martin, WICKET-4071 is not involved as I am not using AjaxIndicatorAppender in any way. 2011/11/18 Nazaret Kazarian : > I'm sorry I forgot to mention that I am using version 1.4.19 > > With a little reverse engineering I noticed that maybe one of the > cases this happens is this: an ajax button is pressed, > showIncrementally is executed, but the actual ajax request is > postponed because its channel is busy. When the time comes to actually > execute the request, the request is stopped because of precondition > check, and thus hideIncrementally is never called. This loses the > count. A fix might be to call hideIncrementally when the ajax request > precondition is not met. As to why the precondition is not met, I am > guessing it's because the previous ajax request did DOM replacement in > a way that the precondition of the queued request is no longer met. > > > > > 2011/11/18 Ernesto Reinaldo Barreiro : >> Martin, >> >> Before switching to 1.5.3 I was working with 1.5.x trunk and I think >> it was the same there... but I can´t say that assertion is 100% true. >> >> As said in my case this happens to me on a modal window because my >> indicator panel blocks the UI and that blocking div is behind the >> modal. It should not be very difficult to produce a quick-start for >> this issue (I guess). >> >> Best regards, >> >> Ernesto >> >> On Fri, Nov 18, 2011 at 12:02 PM, Martin Grigorov >> wrote: >>> On Fri, Nov 18, 2011 at 12:59 PM, Ernesto Reinaldo Barreiro >>> wrote: I have also noticed that with 1.5.3... I normally block the page with div to prevent this but for links on a modal window it happens to me (because blocking div is behind modal). >>> >>> And you didn't experience this with 1.5.2 ? >>> Maybe https://issues.apache.org/jira/browse/WICKET-4071 is involved ? >>> Regards, Ernesto On Fri, Nov 18, 2011 at 11:53 AM, Nazaret Kazarian wrote: > Hi, > > I have added a global ajax indicator to all my pages by having all > pages (through a TemplatePage superclass) implement the > IAjaxIndicatorAware interface. > > Generally it works, but I have noticed that it is quite easy to get > the ajax indicator stuck spinning indefinitely, by issuing many ajax > calls quickly the one after the other. For example if I press an ajax > button multiple times quickly the busy indicator gets stuck. > It seems as if the Wicket.show(hide)Incrementally js functions lose > count of ajax requests and the busy indicator is never actually > hidden. > > Has anyone encountered this problem? > > Thanks a lot > > Naz > > - > 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 >>> >>> >>> >>> -- >>> Martin Grigorov >>> jWeekend >>> Training, Consulting, Development >>> http://jWeekend.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 >> >> > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Apache Wicket is a Flawed Framework
I started with the book wicket in action so it was ok. Before choosing a technology I look at the number of existing books and I buy the best one. But I'm not sure that every body does like me. My main problem is the wiki. The pages are often very old explaining things that do not apply with the last version of wicket and the wiki si so slow that I can't imagine working on it to update the pages :( 2011/11/18 robert.mcguinness > i'm baffled when people say the documentation is poor, the javadocs are > excellent and like igor said there are some great books (blogs too!). > books > and blogs get outdated fast since technlogy is rapidly advancing, so *use > the source luke!*. Not only will you learn Wicket, but I guarantee your > Java skills will improve. > > > awesome examples: > > > > https://github.com/apache/wicket https://github.com/apache/wicket (scan > over the unit test, best way to learn any framework not just wicket) > > https://github.com/55minutes/fiftyfive-wicket > https://github.com/55minutes/fiftyfive-wicket (fantastic) > > https://github.com/42Lines https://github.com/42Lines > > https://github.com/wicketstuff/core https://github.com/wicketstuff/core (a > gem, tons of examples on how to pretty much do anything) > > http://code.google.com/p/wiquery/source/checkout > http://code.google.com/p/wiquery/source/checkout > > https://github.com/jolira/wicket-stateless > https://github.com/jolira/wicket-stateless (wicket stateless is > excellent, > even easier with wicket 1.5) > > https://github.com/reaktor/oegyscroll > https://github.com/reaktor/oegyscroll > (endless pagination) > > http://code.google.com/p/wiquery/source/browse/core > http://code.google.com/p/wiquery/source/browse/core (jquery) > > http://code.google.com/p/jqwicket/source/browse/ > http://code.google.com/p/jqwicket/source/browse/ (jquery, learn from the > code and roll your own if it doesn't fit your needs, super easy > > https://github.com/rjnichols/visural-wicket > https://github.com/rjnichols/visural-wicket (great ui tools) > > https://xaloon.googlecode.com/svn/ https://xaloon.googlecode.com/svn/ > (excellent!) > > > > rob > > -- > View this message in context: > http://apache-wicket.1842946.n4.nabble.com/Apache-Wicket-is-a-Flawed-Framework-tp4080411p4082034.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: Apache Wicket is a Flawed Framework
Gaetan; I also like starting from a book. Then read the (scattered) docs and wiki when am looking for a solution to specific issues. Some projects have an official user guide that is downloadable as pdf or read online as html. I know documentation is one of the the most boring tasks for developers but its is necessary. May be we should hire someone to do the user guide. The users can donate to pay him. My 2c. Josh. On Fri, Nov 18, 2011 at 2:45 PM, Gaetan Zoritchak < g.zoritc...@moncoachfinance.com> wrote: > I started with the book wicket in action so it was ok. Before choosing a > technology I look at the number of existing books and I buy the best one. > But I'm not sure that every body does like me. > > My main problem is the wiki. The pages are often very old explaining things > that do not apply with the last version of wicket and the wiki si so > slow that I can't imagine working on it to update the pages :( > > 2011/11/18 robert.mcguinness > > > i'm baffled when people say the documentation is poor, the javadocs are > > excellent and like igor said there are some great books (blogs too!). > > books > > and blogs get outdated fast since technlogy is rapidly advancing, so *use > > the source luke!*. Not only will you learn Wicket, but I guarantee your > > Java skills will improve. > > > > > > awesome examples: > > > > > > > > https://github.com/apache/wicket https://github.com/apache/wicket (scan > > over the unit test, best way to learn any framework not just wicket) > > > > https://github.com/55minutes/fiftyfive-wicket > > https://github.com/55minutes/fiftyfive-wicket (fantastic) > > > > https://github.com/42Lines https://github.com/42Lines > > > > https://github.com/wicketstuff/core https://github.com/wicketstuff/core(a > > gem, tons of examples on how to pretty much do anything) > > > > http://code.google.com/p/wiquery/source/checkout > > http://code.google.com/p/wiquery/source/checkout > > > > https://github.com/jolira/wicket-stateless > > https://github.com/jolira/wicket-stateless (wicket stateless is > > excellent, > > even easier with wicket 1.5) > > > > https://github.com/reaktor/oegyscroll > > https://github.com/reaktor/oegyscroll > > (endless pagination) > > > > http://code.google.com/p/wiquery/source/browse/core > > http://code.google.com/p/wiquery/source/browse/core (jquery) > > > > http://code.google.com/p/jqwicket/source/browse/ > > http://code.google.com/p/jqwicket/source/browse/ (jquery, learn from > the > > code and roll your own if it doesn't fit your needs, super easy > > > > https://github.com/rjnichols/visural-wicket > > https://github.com/rjnichols/visural-wicket (great ui tools) > > > > https://xaloon.googlecode.com/svn/ https://xaloon.googlecode.com/svn/ > > (excellent!) > > > > > > > > rob > > > > -- > > View this message in context: > > > http://apache-wicket.1842946.n4.nabble.com/Apache-Wicket-is-a-Flawed-Framework-tp4080411p4082034.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: Apache Wicket is a Flawed Framework
On Thu, Nov 17, 2011 at 4:44 PM, Eric Kizaki wrote: Thanks for taking the time to vent your frustrations. I don't see any reason to start to ridicule you, or to think you are an incapable developer just because you don't like Wicket and have taken the time to get it off your chest. Wicket is not suitable for everyone, not suitable for every application, not suitable for every situation. We don't claim such, and neither do we force anyone to use Wicket. If you don't like what you see, too bad, move on to something you do like. Martijn - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Apache Wicket is a Flawed Framework
I have tried out the Wicket framework and many things I really like about it. Some observations: - Wicket changes drastically between versions, and even between minor versions / release candidates, things suddenly disappear from the API, sometimes without having been flagged as deprecated ; - as a result, many times the example code you find on the web or in books like 'Wicket in Action' does no longer work as is - the Javadoc of the source is quite OK for some classes, but for the great majority any textual explanations there are either sparse or absent - luckily the mailing list is nothing short of fantastic ! - I agree that it is rather too easy for Wicket to make things stateful, when you don't want it - and in my opinion the stuff you need to do to achieve "normal" URLs (no ?, no version number, no nothing) is just a pain. *Every* URL, for stateless or stateless pages or whatever, should be "normal", otherwise it is just not acceptable -- users never want to see those complicated-looking URLs under any circumstance - did not yet try out Ajax with Wicket, so I have no opinion on that Just my 2¢. In all, a great framework that is much easier to use than e.g. things based on JSP. Keep up the good work, guys ! Kind regards Heikki Doeleman -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Apache-Wicket-is-a-Flawed-Framework-tp4080411p4082988.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: Apache Wicket is a Flawed Framework
"- did not yet try out Ajax with Wicket, so I have no opinion on that " In my opinion, ajax is the killer feature. Give it a try. Josh. On Fri, Nov 18, 2011 at 3:07 PM, heikki wrote: > I have tried out the Wicket framework and many things I really like about > it. > Some observations: > > > - Wicket changes drastically between versions, and even between minor > versions / release candidates, things suddenly disappear from the API, > sometimes without having been flagged as deprecated ; > > - as a result, many times the example code you find on the web or in books > like 'Wicket in Action' does no longer work as is > > - the Javadoc of the source is quite OK for some classes, but for the great > majority any textual explanations there are either sparse or absent > > - luckily the mailing list is nothing short of fantastic ! > > - I agree that it is rather too easy for Wicket to make things stateful, > when you don't want it > > - and in my opinion the stuff you need to do to achieve "normal" URLs (no > ?, > no version number, no nothing) is just a pain. *Every* URL, for stateless > or > stateless pages or whatever, should be "normal", otherwise it is just not > acceptable -- users never want to see those complicated-looking URLs under > any circumstance > > - did not yet try out Ajax with Wicket, so I have no opinion on that > > Just my 2¢. In all, a great framework that is much easier to use than e.g. > things based on JSP. Keep up the good work, guys ! > > Kind regards > Heikki Doeleman > > > -- > View this message in context: > http://apache-wicket.1842946.n4.nabble.com/Apache-Wicket-is-a-Flawed-Framework-tp4080411p4082988.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: Ajax busy indicator getting stuck
Same problem with IndicatingAjaxLink when I switch to AjaxChannel.Type.DROP -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Ajax-busy-indicator-getting-stuck-tp4082837p4083026.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: InMethod grid, Hidden Field in column does not get updated
Any takers, this one has me stumped. Is there anything special with how a HiddenField gets updated after an Ajax call. The HiddenField is in the same panel as a TextField. The TextField gets updated but the HiddenField does not. I have checked and the values have changed on the model object for both fields. I thought that when you add a component to the target that the component and all its children would get updated. I see the HiddenField coming back in the Ajax response, it just has the old value. Thanks, Warren -Original Message- From: Warren Bell Sent: Wednesday, November 16, 2011 11:04 AM To: 'users@wicket.apache.org' Subject: InMethod grid, Hidden Field in column does not get updated I have an Inmethod grid with a HiddenField in a panel in a column. This HiddenField does not get updated after a SubmitCancelColumn is clicked. All the other fields get updated correctly except for the HiddenField. There is also a TextField in the same panel as the HiddenField, the TextField gets updated correctly. Here is the column code, newPriceTextField gets updated correctly and oldNewPriceHiddenField does not get updated: WicketColumnAdapter newPriceColumn = new WicketColumnAdapter("newPriceColumnAdapter", new org.apache.wicket.extensions.markup.html.repeater.data.table.PropertyColumn(new Model("New Price"), "newPrice")) { @Override public Component newCell(WebMarkupContainer parent, String componentId, IModel rowModel) { final PriceChange priceChange = (PriceChange)rowModel.getObject(); final TextField newPriceTextField = new TextField("newPrice", new PropertyModel(priceChange, "newPrice"), Double.class) final HiddenField oldNewPriceHiddenField = new HiddenField("oldNewPrice", new PropertyModel(priceChange, "oldNewPrice"), Double.class); CostNewPricePanel panel = new CostNewPricePanel(newPriceTextField, oldNewPriceHiddenField); return panel; } }; Also, the "oldNewPrice" property of the oldNewPriceHiddenField does change after SubmitCancelColumn gets clicked. What do I need to do to get the HiddenField to update correctly? Thanks, Warren Bell - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Apache Wicket is a Flawed Framework
Hi all! Thanks for this list, Rob! Not that there would be any more to say except: * I've never seen so informative and extremely helpfull Exception/Error messages in any framework or tool so far. Thank you! * Concerning the "ugly" URLs: well, I don't think that the "real" users out there bother so much. (But you should still aim to the most perfect solution, for the honour...) Working with APEX I've realized that there are blogs based on APEX - and hey, compared to APEX' URLs, wicket's are a treat... Cheers, Chantal On Fri, 2011-11-18 at 04:35 +0100, robert.mcguinness wrote: > i'm baffled when people say the documentation is poor, the javadocs are > excellent and like igor said there are some great books (blogs too!). books > and blogs get outdated fast since technlogy is rapidly advancing, so *use > the source luke!*. Not only will you learn Wicket, but I guarantee your > Java skills will improve. > > > awesome examples: > > > > https://github.com/apache/wicket https://github.com/apache/wicket (scan > over the unit test, best way to learn any framework not just wicket) > > https://github.com/55minutes/fiftyfive-wicket > https://github.com/55minutes/fiftyfive-wicket (fantastic) > > https://github.com/42Lines https://github.com/42Lines > > https://github.com/wicketstuff/core https://github.com/wicketstuff/core (a > gem, tons of examples on how to pretty much do anything) > > http://code.google.com/p/wiquery/source/checkout > http://code.google.com/p/wiquery/source/checkout > > https://github.com/jolira/wicket-stateless > https://github.com/jolira/wicket-stateless (wicket stateless is excellent, > even easier with wicket 1.5) > > https://github.com/reaktor/oegyscroll https://github.com/reaktor/oegyscroll > (endless pagination) > > http://code.google.com/p/wiquery/source/browse/core > http://code.google.com/p/wiquery/source/browse/core (jquery) > > http://code.google.com/p/jqwicket/source/browse/ > http://code.google.com/p/jqwicket/source/browse/ (jquery, learn from the > code and roll your own if it doesn't fit your needs, super easy > > https://github.com/rjnichols/visural-wicket > https://github.com/rjnichols/visural-wicket (great ui tools) > > https://xaloon.googlecode.com/svn/ https://xaloon.googlecode.com/svn/ > (excellent!) > > > > rob > > -- > View this message in context: > http://apache-wicket.1842946.n4.nabble.com/Apache-Wicket-is-a-Flawed-Framework-tp4080411p4082034.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: Apache Wicket is a Flawed Framework
I was searching for a Java framework two years ago because I wanted server-side persistence and a statically typed language with the option for easy AJAX and debugging while the output markup is largely maintained the way I wrote the templates. I think I found Wicket via DZone due to the 1.4 release. I already read a book from Manning before and liked that it was written in a way that enables the reader to jump right into programming after having read the introductory chapters. I was happy when I saw that Wicket in Action seemed to use a similar structure. I think I tried Wicket without the book first but got stuck really quick (at latest when I got to the point when I needed models which was quite immediate) and so buying WiA was a quick (and good) decision. As with any framework, it takes at least one project to get your head around it, so you better start with some personal project in your free time. On the following 2-3 projects you are iterating on the "maybe I could have done it better that way" process. But that's just the way it is for any framework in any language (and also without any framework at all). I assume the OP is using Wicket the first time without any guidance and just hasn't found into it yet. I wasn't able to put Wicket in use at work until January this year but now we are on our 2nd (my 4th) Wicket project. What I could observe is that 1) you usually don't find into Wicket until you read a book (with WiA it's sufficient to read the introductory chapters, jump into coding and come back to the chapters whenever you need to know something) 2) there is an aversion until you get your head around the correct use of models and anonymous inner classes, at least if you never did something like that before (WiA introduces it quite good but you have to start coding before you really get it) 3) you should follow the (excellent) mailing list to read about issues you may encounter and use it as a knowledge base once you hit some problem/question (better on an own email account than on the archives) 4) if documentation does not help, read the source code (I found it pretty readable which is much different from other frameworks I have used/tried before - being easily accessible with Maven and a decent IDE, there is no excuse not to look into it) So, the conclusion is: There should be better free documentation but if you pick up a book it's quite easy to get started and the best 30€ ever spent. - I agree that it is rather too easy for Wicket to make things stateful, when you don't want it To turn that into a point of critique: It may be hard to get stateless pages. I've made a similar experience where I had a search form that would not go stateless. I couldn't figure out where anything was persisted but if I had dug deeper, I may have found the cause, but that issue wasn't important enough to invest more time in it. - and in my opinion the stuff you need to do to achieve "normal" URLs (no ?, no version number, no nothing) is just a pain. *Every* URL, for stateless or stateless pages or whatever, should be "normal", otherwise it is just not acceptable -- users never want to see those complicated-looking URLs under any circumstance I prefer the way Wicket handles persistence with at-most-once semantics by simply adding version numbers on the URL (after a redirect from an internal URL) as other methods are less successful in achieving that out of the box, pollute URLs even further or add hidden markup. IMO, two numbers on the URL are quite unobtrusive, especially as they are simply ignored and transparently reassigned if the session does not match (i.e. on a URL that has been pasted into an email etc.). - did not yet try out Ajax with Wicket, so I have no opinion on that It's incredibly easy to use; you should really try it. :) Just my 2¢. In all, a great framework that is much easier to use than e.g. things based on JSP. Keep up the good work, guys ! Full ack! :) - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
RE: EOFException(java.net.SocketException: Connection reset by peer: socket write error)
Hi Iver/Martin I also tried this.getRequestCycle().getOriginalResponse().setContentType("image/jpg"); getResponse().setContentType("image/jpeg"); but still getting same exception.. Please let me know how can I set content type (mime type ) of response so that content type of response and image should be same. I know the mime type of Image is JPEG... Thanks in advance.. Thanks Shail -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/EOFException-java-net-SocketException-Connection-reset-by-peer-socket-write-error-tp4043286p4083468.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: EOFException(java.net.SocketException: Connection reset by peer: socket write error)
Hi I am facing this problem in IE9 also.. Thanks Shail -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/EOFException-java-net-SocketException-Connection-reset-by-peer-socket-write-error-tp4043286p4083475.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: Apache Wicket is a Flawed Framework
I was not expecting so much hate. I guess now I am infamous in the Java world now. Look, it is just my opinion. Not many people actually stopped to address many of my points. They just immediately bashed me. I am sticking with Wicket because it is required for work. I am able to do stuff in it but it seems unnecessarily complicated. I own the “Wicket in Action” book and “Enjoying Web Development with Wicket Book” by Kent Ka Iok Tong. The second book is much more practical. Without these books I would not be able to do anything in Wicket. That is why I did not mention documentation. I would prefer to just be able to check out something like this http://static.springsource.org/docs/petclinic.html. This is a real working application that shows how to do things with databases etc. With Wicket, I had to string a bunch of snippets together and read two books. I am still not sure I am doing things the best way. To people who say I am inexperienced, I have tried JSF and GWT. Wicket is better than both of those. JSF has an invasive and complicated lifecycle. When I saw the lifecycle diagram I just stopped even looking into it. GWT uses terrible Swing style layouts and all these crappy interfaces for RPC. There was also no real help on the server. At least with Wicket I can still use HTML and CSS for my layouts. However, these component based frameworks are still way too complicated for a simple task: building a web page. In my humble opinion Spring MVC done right (no scriplets) with JSTL & EL and jQuery is better than Wicket. You can also use Velocity templating. I have also used Swing to build desktop apps. I would not say Swing is a shining example of how to build GUIs. I thought it was pretty bad, verbose, and impractical. The Play Framework has the right idea: stateless and restful. No clunky components and over-engineered objected-oriented baggage. Here is a quote from the Restlet page (http://www.restlet.org/about/introduction): “While powerful for complex centralized models, the object-oriented paradigm isn't always the best suited for Web development. Java developers need realize this and start thinking more RESTfully when developing new Web servers or new AJAX-based Web clients. The Restlet project is providing a simple yet solid foundation that can get you started right away on the Web 2.0.” - Jérôme Louvel, Restlet founder Maybe you can look up his Linkdin and start bashing him too. Oh no he said object-oriented is not the Holy Grail! I am definitely in the “I like to hand-code HTML, CSS, and Javascript” camp. I even like hand-coding SQL. I get complete control. These are all pretty easy languages; most of them are declarative. They are easier than Java. I know most Java developers do not feel this way and want to just do everything in Java. I think you should use the best tool for the job. Java is a mediocre tool to use in every domain. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Apache-Wicket-is-a-Flawed-Framework-tp4080411p4083476.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: EOFException(java.net.SocketException: Connection reset by peer: socket write error)
Hi Martin I also tried this.getRequestCycle().getOriginalResponse().setContentType("image/jpg"); getResponse().setContentType("image/jpeg"); but still getting same exception.. Please let me know how can I set content type (mime type ) of response so that content type of response and image should be same. I know the mime type of Image is JPEG... Thanks in advance.. Thanks Shail -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/EOFException-java-net-SocketException-Connection-reset-by-peer-socket-write-error-tp4043286p4083480.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: AjaxLazyLoadPanel question
Hello again, I have a follow-up question. Can I somehow update other components once the AjaxLazyLoadPanel's getLazyLoadComponent() method has completed? I thought I could use the new wicket 1.5 event mechanism for that but if I understood correctly I would have to send the AjaxRequestTarget in the payload to add my changed components to it, right? And I don't really know how to get the AjaxRequestTarget in the getLazyLoadComponent() method. Thanks in advance for any hints, Philip 2011/11/18 heapifyman > Great, it's working. > Thanks for the quick response, > > Philip > > > > 2011/11/17 Igor Vaynberg > >> you can replace the lazy load panel instance: >> >> //check other selections >> myLazyLoadPanel=myLazyLoadPanel.replaceWith(new >> MyLazyLoadPanel(myLazyLoadPanel.getId(), ..) >> target.addComponent(myLazyLoadPanel); >> >> this will reset the state of lazyloadpanel to the "not-yet-loaded" >> >> -igor >> >> On Thu, Feb 3, 2011 at 11:40 AM, Matt Schmidt >> wrote: >> > I currently have a DataGridView loaded inside of an AjaxLazyLoadPanel, >> > including the service call to get the data. >> > >> > myLazyLoadPanel = new AjaxLazyLoadPanel("id", new >> CollectionModel()) { >> >public Component getLazyLoadComponent(String markupId) { >> >if(getDefaultModelObject() == null) { >> >setDefaultModelObject(myPojoService.readAll()); >> >} >> >return new MyDataGridView(markupId, getDefaultModel()); >> //ignoring >> > casting for simplicity >> >} >> > } >> > >> > That works great for loading the page before the service call is >> complete. >> > >> > But now I need to add a DropDownChoice to change the collection in the >> data >> > grid via Ajax after the page is loaded. Is there anyway to get the >> > DataGridView to be replaced with an Ajax indicator (like on page load) >> > during an Ajax "onchange" event for the DropDownChoice? I've added an >> Ajax >> > indicator to the DropDownChoice, but I would like the same behavior I >> get on >> > page load for the AjaxLazyLoadPanel. >> > >> > This is what I have for the drop down for starters: >> > >> > myDropDownChoice.add(new AjaxFormComponentUpdateBehavior("onchange") { >> >protected void onUpdate(AjaxRequestTarget target) { >> >if(myDropDownChoice.getModelObject().equals(foo)) { >> > >> myLazyLoadPanel.setDefaultModelObject(myPojoService.readFoo()); >> >} >> >//check other selections >> > target.addComponent(myLazyLoadPanel); >> >} >> > } >> > >> > I may be looking at this entirely wrong... Any suggestions? >> > >> >> - >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> >
Re: Apache Wicket is a Flawed Framework
That's actually interesting you feel that way because I was just making the comment that I was surprised at how little hate was being displayed. Sure there are a couple here and there, but par for the internet is far, far lower (higher? maybe a golf analogy was a bad idea) than what we're seeing here. And, in fact, many people did attempt to address specific issues. However, you can't really expect sunshine and rainbows when the initial post says nothing positive whatsoever and offers no suggestions for improvement. This more recent post, however, I like so much better because you actually get into specific instances where there is room for improvement and link to a potential guide for a solution. I would definitely agree with you that something like the spring petclinic would be really handy. I, personally, can't count the number of times I found myself "doing it wrong" because I hadn't known to look at the javadoc in that other class over there (I'm looking at you, ListView vs DataTable). One of the largest strengths of wicket is its flexibility, but it tends to come at the cost of there being too many ways to do something. That makes it difficult to know which is the "right" way to accomplish the task. Until you really get to know wicket, it definitely feels a bit like you need to learn the secret handshakes and hidden incantations to make it do something as simple as showing feedback properly in a repeating view. There are a lot of us here that have gone through (and still going) that learning curve and could probably contribute to a large sample application that shows "how to do stuff". Additionally, I believe work on Wicket 6 has officially started, so if there are concrete suggestions for improvement, I bet Jira would love to record them for you. Is Wicket perfect? No, no framework is. But it's getting better and the more help it has, the better it will get. On Fri, Nov 18, 2011 at 9:27 AM, Eric Kizaki wrote: > I was not expecting so much hate. I guess now I am infamous in the Java > world now. Look, it is just my opinion. Not many people actually stopped > to address many of my points. They just immediately bashed me. > > I am sticking with Wicket because it is required for work. I am able to do > stuff in it but it seems unnecessarily complicated. I own the “Wicket in > Action” book and “Enjoying Web Development with Wicket Book” by Kent Ka Iok > Tong. The second book is much more practical. Without these books I would > not be able to do anything in Wicket. That is why I did not mention > documentation. I would prefer to just be able to check out something like > this http://static.springsource.org/docs/petclinic.html. This is a real > working application that shows how to do things with databases etc. With > Wicket, I had to string a bunch of snippets together and read two books. I > am still not sure I am doing things the best way. > > To people who say I am inexperienced, I have tried JSF and GWT. Wicket is > better than both of those. JSF has an invasive and complicated lifecycle. > When I saw the lifecycle diagram I just stopped even looking into it. GWT > uses terrible Swing style layouts and all these crappy interfaces for RPC. > There was also no real help on the server. At least with Wicket I can > still > use HTML and CSS for my layouts. However, these component based frameworks > are still way too complicated for a simple task: building a web page. In > my humble opinion Spring MVC done right (no scriplets) with JSTL & EL and > jQuery is better than Wicket. You can also use Velocity templating. I > have > also used Swing to build desktop apps. I would not say Swing is a shining > example of how to build GUIs. I thought it was pretty bad, verbose, and > impractical. The Play Framework has the right idea: stateless and > restful. > No clunky components and over-engineered objected-oriented baggage. > > Here is a quote from the Restlet page > (http://www.restlet.org/about/introduction): > “While powerful for complex centralized models, the object-oriented > paradigm > isn't always the best suited for Web development. Java developers need > realize this and start thinking more RESTfully when developing new Web > servers or new AJAX-based Web clients. The Restlet project is providing a > simple yet solid foundation that can get you started right away on the Web > 2.0.” > - Jérôme Louvel, Restlet founder > Maybe you can look up his Linkdin and start bashing him too. Oh no he said > object-oriented is not the Holy Grail! > > I am definitely in the “I like to hand-code HTML, CSS, and Javascript” > camp. > I even like hand-coding SQL. I get complete control. These are all pretty > easy languages; most of them are declarative. They are easier than Java. > I > know most Java developers do not feel this way and want to just do > everything in Java. I think you should use the best tool for the job. > Java > is a mediocre tool to use in every domain.
Re: Apache Wicket is a Flawed Framework
heikki wrote: > > - and in my opinion the stuff you need to do to achieve "normal" URLs (no > ?, no version number, no nothing) is just a pain. *Every* URL, for > stateless or stateless pages or whatever, should be "normal", otherwise it > is just not acceptable -- users never want to see those > complicated-looking URLs under any circumstance > > Here I totally agree. I think there are very few developers who understand this. An URL is a technical entity, and, if they had a choice, the vast majority of internet-users could very well do without it. URL's are /not/ user friendly. It's better now, but in the early days it was very cumbersome to help my >80 father (y'all understand >80, I presume) on the phone: 'No, dad, just type h-t-t-p-:-/-/.'. I really think this is a flaw in wicket, caused by a collective blank spot of it's otherwise very clever developers. But I really love Wicket, I managed to develop a quite complex application that's robust and easy to use, and it's only my second web application ever, the first being a Servlet with html-spawning only... -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Apache-Wicket-is-a-Flawed-Framework-tp4080411p4083524.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: Apache Wicket is a Flawed Framework
> The Play Framework has the right idea: stateless and restful. > No clunky components and over-engineered objected-oriented baggage. > > Play has some advantages but also shortcomings and presents significant risks. The transition from version 1 to version 2 will require re-writing the code. No migration possible! The new version seems to focus on scala (the views are now coded in scala instead of groovy). The business code can be in java and scala. What will happen to the java version in 2 years? Play's vision is a fully integrated technology stack with fairly fixed choices (JPA data access for java, Anorm - single layer over jdbc - for scala). This is not the approach of wicket which is much more modular and simply treat the presentation layer. In short, there is no silver bullet ... just find the framework that best meets your needs.
Problem with check / uncheck all using CheckGroupSelector
Hello, i am implementing a dataview table with a checkbox column. At the top of the column i place a checkbox to select/unselect all rows. But It is not working as i want. Using the class Check: checking and unchecking all rows works, but the collection to hold the selected rows is not getting populated. Using the classes CheckBox and AjaxCheckBox: checking and unschecking does not work, but the collection is getting populated. Sorry for eventual duplication, but i search this forum and the web and i couldn't get a hint to fix this problem. I will highly appreciate your help. Here are some code snippet that could help: *My Form* *Markup:* -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Problem-with-check-uncheck-all-using-CheckGroupSelector-tp4083663p4083663.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: AjaxLazyLoadPanel question
Hm, looks like AjaxRequestTarget.get() is what I was looking for? 2011/11/18 heapifyman > Hello again, > > I have a follow-up question. Can I somehow update other components once > the AjaxLazyLoadPanel's getLazyLoadComponent() method has completed? > > I thought I could use the new wicket 1.5 event mechanism for that but if I > understood correctly I would have to send the AjaxRequestTarget in the > payload to add my changed components to it, right? > And I don't really know how to get the AjaxRequestTarget in > the getLazyLoadComponent() method. > > Thanks in advance for any hints, > Philip > > > 2011/11/18 heapifyman > >> Great, it's working. >> Thanks for the quick response, >> >> Philip >> >> >> >> 2011/11/17 Igor Vaynberg >> >>> you can replace the lazy load panel instance: >>> >>> //check other selections >>> myLazyLoadPanel=myLazyLoadPanel.replaceWith(new >>> MyLazyLoadPanel(myLazyLoadPanel.getId(), ..) >>> target.addComponent(myLazyLoadPanel); >>> >>> this will reset the state of lazyloadpanel to the "not-yet-loaded" >>> >>> -igor >>> >>> On Thu, Feb 3, 2011 at 11:40 AM, Matt Schmidt >>> wrote: >>> > I currently have a DataGridView loaded inside of an AjaxLazyLoadPanel, >>> > including the service call to get the data. >>> > >>> > myLazyLoadPanel = new AjaxLazyLoadPanel("id", new >>> CollectionModel()) { >>> >public Component getLazyLoadComponent(String markupId) { >>> >if(getDefaultModelObject() == null) { >>> >setDefaultModelObject(myPojoService.readAll()); >>> >} >>> >return new MyDataGridView(markupId, getDefaultModel()); >>> //ignoring >>> > casting for simplicity >>> >} >>> > } >>> > >>> > That works great for loading the page before the service call is >>> complete. >>> > >>> > But now I need to add a DropDownChoice to change the collection in the >>> data >>> > grid via Ajax after the page is loaded. Is there anyway to get the >>> > DataGridView to be replaced with an Ajax indicator (like on page load) >>> > during an Ajax "onchange" event for the DropDownChoice? I've added an >>> Ajax >>> > indicator to the DropDownChoice, but I would like the same behavior I >>> get on >>> > page load for the AjaxLazyLoadPanel. >>> > >>> > This is what I have for the drop down for starters: >>> > >>> > myDropDownChoice.add(new AjaxFormComponentUpdateBehavior("onchange") { >>> >protected void onUpdate(AjaxRequestTarget target) { >>> >if(myDropDownChoice.getModelObject().equals(foo)) { >>> > >>> myLazyLoadPanel.setDefaultModelObject(myPojoService.readFoo()); >>> >} >>> >//check other selections >>> > target.addComponent(myLazyLoadPanel); >>> >} >>> > } >>> > >>> > I may be looking at this entirely wrong... Any suggestions? >>> > >>> >>> - >>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >>> For additional commands, e-mail: users-h...@wicket.apache.org >>> >>> >> >
Re: AjaxLazyLoadPanel question
yes -igor On Fri, Nov 18, 2011 at 8:25 AM, heapifyman wrote: > Hm, looks like AjaxRequestTarget.get() is what I was looking for? > > > > 2011/11/18 heapifyman > >> Hello again, >> >> I have a follow-up question. Can I somehow update other components once >> the AjaxLazyLoadPanel's getLazyLoadComponent() method has completed? >> >> I thought I could use the new wicket 1.5 event mechanism for that but if I >> understood correctly I would have to send the AjaxRequestTarget in the >> payload to add my changed components to it, right? >> And I don't really know how to get the AjaxRequestTarget in >> the getLazyLoadComponent() method. >> >> Thanks in advance for any hints, >> Philip >> >> >> 2011/11/18 heapifyman >> >>> Great, it's working. >>> Thanks for the quick response, >>> >>> Philip >>> >>> >>> >>> 2011/11/17 Igor Vaynberg >>> you can replace the lazy load panel instance: //check other selections myLazyLoadPanel=myLazyLoadPanel.replaceWith(new MyLazyLoadPanel(myLazyLoadPanel.getId(), ..) target.addComponent(myLazyLoadPanel); this will reset the state of lazyloadpanel to the "not-yet-loaded" -igor On Thu, Feb 3, 2011 at 11:40 AM, Matt Schmidt wrote: > I currently have a DataGridView loaded inside of an AjaxLazyLoadPanel, > including the service call to get the data. > > myLazyLoadPanel = new AjaxLazyLoadPanel("id", new CollectionModel()) { > public Component getLazyLoadComponent(String markupId) { > if(getDefaultModelObject() == null) { > setDefaultModelObject(myPojoService.readAll()); > } > return new MyDataGridView(markupId, getDefaultModel()); //ignoring > casting for simplicity > } > } > > That works great for loading the page before the service call is complete. > > But now I need to add a DropDownChoice to change the collection in the data > grid via Ajax after the page is loaded. Is there anyway to get the > DataGridView to be replaced with an Ajax indicator (like on page load) > during an Ajax "onchange" event for the DropDownChoice? I've added an Ajax > indicator to the DropDownChoice, but I would like the same behavior I get on > page load for the AjaxLazyLoadPanel. > > This is what I have for the drop down for starters: > > myDropDownChoice.add(new AjaxFormComponentUpdateBehavior("onchange") { > protected void onUpdate(AjaxRequestTarget target) { > if(myDropDownChoice.getModelObject().equals(foo)) { > myLazyLoadPanel.setDefaultModelObject(myPojoService.readFoo()); > } > //check other selections > target.addComponent(myLazyLoadPanel); > } > } > > I may be looking at this entirely wrong... Any suggestions? > - 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: Button with 3 images and issues
your html got eaten... -igor On Fri, Nov 18, 2011 at 2:52 AM, D0m3 wrote: > Hello everybody, > I am starting a wicket project for the first time, and I created a button > made of 3 images with html css. Here is my html : > > I want this button to be disableable. In Java, I only declare 1 AjaxButton, > which is linked to the button tag. When I use setEnabled(false), it only > adds the disabled tag to the button tag. I would need to add the disabled > tag to the 2 other spans. > While searching for an answer, I realized I could either create a custom > component or add a behavior to automatically add the markup necessary to > create this button. Thus, in my html I would only write : > > And all the class and span stuff would be added by wicket. > However I have no idea how to do that. beforeRender and afterRender add > markup before and after if I understood correctly, and onComponentTag adds > attributes. > It would be great if you could provide links or hints on how to do that. > Thanks in advance. > > Florian > > -- > View this message in context: > http://apache-wicket.1842946.n4.nabble.com/Button-with-3-images-and-issues-tp4082830p4082830.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: Problem with check / uncheck all using CheckGroupSelector
On Fri, 18 Nov 2011 07:31:48 -0800 (PST) massizigao wrote: > Hello, > > i am implementing a dataview table with a checkbox column. At the top > of the column i place a checkbox to select/unselect all rows. But It > is not working as i want. > Using the class Check: checking and unchecking all rows works, but > the collection to hold the selected rows is not getting populated. > Using the classes CheckBox and AjaxCheckBox: checking and unschecking > does not work, but the collection is getting populated. > Sorry for eventual duplication, but i search this forum and the web > and i couldn't get a hint to fix this problem. I will highly > appreciate your help. Here are some code snippet that could help: You need to use the appropriate combination of checkbox, group and selector. 1) If you use a CheckGroup, then you have to build your checkboxes with Check instances, and they need to be children of the CheckGroup. In your example, add your dataview to the CheckGroup, so the Check instances are also underneath that. Then you can use CheckGroupSelector. 2) You can also use CheckBox instances - these don't need to be grouped together, they are just all separate boolean checkboxes. To select/unselect all of these you need to use CheckBoxSelector. 3) You can also use a CheckboxMultipleChoice together with CheckboxMultipleChoiceSelector. For your case I recommend option 1, since you are using listview. I hope this helps. Carl-Eric www.wicketbuch.de - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
RE: ValidationForm.addPropertyValidators sometimes looks for child properties in parent's model
Dear Igor, (me)>> I get a call with expression being "child", and target being the local test object. Were expression "parent.child", this would succeed, as it would call getParent().getChild(). However, I'm not sure whether this is my bug or the wicket-validation-bean library's. (Igor)>this is probably a misuse of the compound property model, which is evil anyways. you have to create your components with ids that match the path from the root object, so if you want to access person.address property you cant put a text field with id "address" into a webmarkupcontainer of id "person", you have to add a text field with component id "person.address" I'm sorry that I can't send or post the problematic code; much of it is proprietary. Here's a censored précis. I have a Report object for people to fill out. Report has a variable of type Publication, Publication being an interface. public class Report implements Serializable { @Valid private Publication publication; } public interface Publication extends Serializable {} public class Book implements Publication {} public class Article implements Publication {} public class Monograph implements Publication() I have UI panels: public class BookPanel extends FormComponentPanel {} public class ArticlePanel extends FormComponentPanel {} public class MonographPanel extends FormComponentPanel {} I'm trying to create a PublicationPanel: public class PublicationPanel extends FormComponentPanel { private RadioChoice publicationTypeChoice; private FormComponentPanel specificPublicationPanel; } I will swap a BookPanel, ArticlePanel, and MonographPanel in depending on the user's choice of type. If CompoundPropertyModels are evil (and I'd like a pointer to why), how can I take a IModel and turn it into a IModel and IModel, and so on? Does the metagen project handle the polymorphism? Should I be using the single-argument constructor of FormComponentPanel at all? Does it matter if I need to use the PublicationPanel more than once in the ReportForm? Respectfully, Eric Jablow This communication, along with any attachments, is covered by federal and state law governing electronic communications and may contain company proprietary and legally privileged information. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, use or copying of this message is strictly prohibited. If you have received this in error, please reply immediately to the sender and delete this message. Thank you. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
LoadableDetachableModel getObject not final
Hi, I'm wondering if it is ok not to do 'final' this method. Correct me if I'm wrong but I think it is not normal to Override this method because we always have to Override load(). It's just a question to know what do you think. Thanks! Norberto
Re: Chained dropdowns
Can you please past the code snippet here or at pastebin please? --Original Message-- From: Tito To: users@wicket.apache.org ReplyTo: users@wicket.apache.org Subject: Chained dropdowns Sent: Nov 18, 2011 11:36 AM Hi, I'm trying to connect three drowpdowns. For example. combo1: Country combo2: Province combo3: City I'm updating dropdowns by Ajax with AjaxFormComponentUpdatingBehavior("onChange") and it works ok. But if you choose a Country, then a Province, then a City and after that you change the Country, the Province changes but not the city. I'm doing everything with models and adding all dropdowns to AjaxRequestTarget. Regards Norberto - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Apache Wicket is a Flawed Framework
i will address some points that i dont think have been addressed yet... On Thu, Nov 17, 2011 at 7:44 AM, Eric Kizaki wrote: > Violates Dry: You must repeat the component hierarchy of your widgets that > are in HTML in Java Code for no good reason. If you move your widget around > in the html it will break the Java and you get a stack trace if you change > the nesting. You have to keep these two files synched. A JSP file is more > maintainable. At least the view code is in one place. this will be much improved in the upcoming 6.0. this is not as trivial as saying: "oh, just let me move my components in markup anywhere" because a lot of the usecases actually depend on component hiearchy on the java side so it doesnt make sense having them out of sync. anyways, this was thoroughly discussed on the mailing list, have you bothered to search the archive before ranting? here is the link to a discussion: http://markmail.org/thread/5iczgvd42k6oeera > Not previewable: One of the supposed benefits of Wicket is a clean template > that could make pages previewable for designers. the pages are previewable to a much larger degree then they are with most other frameworks. we dont claim complete previewability i dont think, and if we do we shouldnt. wicket allows you to chunk up the ui and swap bits and pieces out at runtime, so of course it is very hard to construct a preview for a page that is composed of lots of smaller pieces, however, the pieces themselves are previewable. > First, we don't have > seperate designers at my company. im sorry > Second, it is better if the samer person > does development and design. heh. personally, i dont like to spend my time thinking about which css hack i need to apply to make a div line up perfectly across all browsers. i think most developers would agree with me. im just glad i work at a company where we do have designers who do that, do it well, and most of all love doing it :) > Third, if you use extends your page will not > be priviewable outside an application server running Wicket. This supposed > benefit does not exist. yep. or if you use panels. however, you are free to add chunks outside the wicket:extend tags that add the missing body/html/head tags to make the page or panel at least somewhat previewable, which our designers do sometimes. i think "previewability" in our context should mean that the designer can open a markup file used by wicket in the tool of their liking and not feel completely lost or afraid to tweak stuff. in my company the designers do the first pass on new markup, then the developers wicketize it and write the code. once that is done the designers often go back and tweak things, and they can do so easily without breaking anything - i think thats the important bit to take away. > Violates MVC: It smashes view and controller code into the same Java file. > You have code that regulates page flow and code that changes css attributes > in the same file. Even Spring MVC had better separation of concerns. > JSP/Servlets with Spring MVC is better. ive never understood why people want to externalize the flow of the application. it seems rather silly considering a lot of the flows are dynamic. especially once you consider panel-swapping or single-page-applications as they are often called. how do you externalize that flow? you cant. also, i do not see a semantic difference between the code that navigates and the code that tweaks css attributes. they are both about the user interface. as long as no one puts business logic into my components im ok. > Excessively verbose and complicated: What is a LoadableDetachableModel? an LDM is basically a closure. its only verbose because java is verbose when it comes to creating closures, but this will be fixed in java 8. > The learning curve for Wicket is immense. yes. for those coming from the mvc/servlets/action frameworks world it involves a complete, and i hate to use the term, "paradigm shift" in how you approach problems. you actually have to learn the OOP part of java :) people who have been coding swing, swt, gwt, or any other oop framework can pick up wicket very quickly. i think all your other points have been addressed in other emails. good luck -igor > Breaks POJOS: A real POJO does not need to implement an interface or extend > a class. Wicket forces your beans to be Serializable. This is like using > EJBs in how it forced you to implement interfaces. > > Terrible AJAX: Compared to a few lines of jQuery AJAX is excessively > complicated and verbose in Wicket. A lot of things like “AJAX” links should > not be done via “AJAX” at all. Hiding a div on the client would simply be > done with JavaScript on the client. Wicket better not require a server > request for that. You also have no JSON support and good luck debugging any > JavaScript or AJAX in Firefox. Instead you have to use the subpar Wicket > debugging. > > HTML5: No support for HTML 5 form elements unless you
Metagen configuration issue
I've cut and pasted the Metagen configuration listed in https://github.com/42Lines/metagen into my project pom, and these declarations are generating the metamodels twice: in target/generated-sources/annotations, and in target/metamodel. What must I do to cut out one of the metamodel locations? I'm a Maven novice. Respectfully, Eric Jablow This communication, along with any attachments, is covered by federal and state law governing electronic communications and may contain company proprietary and legally privileged information. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, use or copying of this message is strictly prohibited. If you have received this in error, please reply immediately to the sender and delete this message. Thank you.
RE: Apache Wicket is a Flawed Framework
Wicket is a different approach from the JSP(Spring MVC/Struts) model but is certainly an improvement over the basic Servlets and JSPs oriented MVC. One of the benefits is that you compile your wicket components to mostly pure Java and you have a good idea how your page will behave. Yes, Wicket does a lot of the work for you. That is good or bad depending on what your requirements are. -Original Message- From: Igor Vaynberg [mailto:igor.vaynb...@gmail.com] Sent: Friday, November 18, 2011 1:50 PM To: users@wicket.apache.org Subject: Re: Apache Wicket is a Flawed Framework i will address some points that i dont think have been addressed yet... On Thu, Nov 17, 2011 at 7:44 AM, Eric Kizaki wrote: > Violates Dry: You must repeat the component hierarchy of your widgets > that are in HTML in Java Code for no good reason. If you move your > widget around in the html it will break the Java and you get a stack > trace if you change the nesting. You have to keep these two files > synched. A JSP file is more maintainable. At least the view code is in one > place. this will be much improved in the upcoming 6.0. this is not as trivial as saying: "oh, just let me move my components in markup anywhere" because a lot of the usecases actually depend on component hiearchy on the java side so it doesnt make sense having them out of sync. anyways, this was thoroughly discussed on the mailing list, have you bothered to search the archive before ranting? here is the link to a discussion: http://markmail.org/thread/5iczgvd42k6oeera > Not previewable: One of the supposed benefits of Wicket is a clean > template that could make pages previewable for designers. the pages are previewable to a much larger degree then they are with most other frameworks. we dont claim complete previewability i dont think, and if we do we shouldnt. wicket allows you to chunk up the ui and swap bits and pieces out at runtime, so of course it is very hard to construct a preview for a page that is composed of lots of smaller pieces, however, the pieces themselves are previewable. > First, we don't have > seperate designers at my company. im sorry > Second, it is better if the samer person does development and design. heh. personally, i dont like to spend my time thinking about which css hack i need to apply to make a div line up perfectly across all browsers. i think most developers would agree with me. im just glad i work at a company where we do have designers who do that, do it well, and most of all love doing it :) > Third, if you use extends your page will not be priviewable outside > an application server running Wicket. This supposed benefit does not > exist. yep. or if you use panels. however, you are free to add chunks outside the wicket:extend tags that add the missing body/html/head tags to make the page or panel at least somewhat previewable, which our designers do sometimes. i think "previewability" in our context should mean that the designer can open a markup file used by wicket in the tool of their liking and not feel completely lost or afraid to tweak stuff. in my company the designers do the first pass on new markup, then the developers wicketize it and write the code. once that is done the designers often go back and tweak things, and they can do so easily without breaking anything - i think thats the important bit to take away. > Violates MVC: It smashes view and controller code into the same Java file. > You have code that regulates page flow and code that changes css > attributes in the same file. Even Spring MVC had better separation of > concerns. > JSP/Servlets with Spring MVC is better. ive never understood why people want to externalize the flow of the application. it seems rather silly considering a lot of the flows are dynamic. especially once you consider panel-swapping or single-page-applications as they are often called. how do you externalize that flow? you cant. also, i do not see a semantic difference between the code that navigates and the code that tweaks css attributes. they are both about the user interface. as long as no one puts business logic into my components im ok. > Excessively verbose and complicated: What is a LoadableDetachableModel? an LDM is basically a closure. its only verbose because java is verbose when it comes to creating closures, but this will be fixed in java 8. > The learning curve for Wicket is immense. yes. for those coming from the mvc/servlets/action frameworks world it involves a complete, and i hate to use the term, "paradigm shift" in how you approach problems. you actually have to learn the OOP part of java :) people who have been coding swing, swt, gwt, or any other oop framework can pick up wicket very quickly. i think all your other points have been addressed in other emails. good luck -igor > Breaks POJOS: A real POJO does not need to implement an interface or > extend a class. Wicket force
Re: ValidationForm.addPropertyValidators sometimes looks for child properties in parent's model
On Fri, Nov 18, 2011 at 9:32 AM, Jablow, Eric R wrote: > Dear Igor, > > (me)>> I get a call with expression being "child", and target being the local > test object. Were expression "parent.child", this would succeed, as it would > call getParent().getChild(). However, I'm not sure whether this is my bug or > the wicket-validation-bean library's. > > (Igor)>this is probably a misuse of the compound property model, which is > evil anyways. you have to create your components with ids that match > the path from the root object, so if you want to access person.address > property you cant put a text field with id "address" into a > webmarkupcontainer of id "person", you have to add a text field with > component id "person.address" > > I'm sorry that I can't send or post the problematic code; much of it is > proprietary. Here's a censored précis. but you can create a testcase, reproducing the bare bits of code in a testcase just like you did in the email below. the advantage would be that i would have something i can play with which makes it much easier to find the problem. > > I have a Report object for people to fill out. Report has a variable of type > Publication, Publication being an interface. > > public class Report implements Serializable { > @Valid > private Publication publication; > } > > public interface Publication extends Serializable {} > > public class Book implements Publication {} > public class Article implements Publication {} > public class Monograph implements Publication() > > I have UI panels: > > public class BookPanel extends FormComponentPanel {} > public class ArticlePanel extends FormComponentPanel {} > public class MonographPanel extends FormComponentPanel {} > > I'm trying to create a PublicationPanel: > > public class PublicationPanel extends FormComponentPanel { > private RadioChoice publicationTypeChoice; > private FormComponentPanel > specificPublicationPanel; > } > > I will swap a BookPanel, ArticlePanel, and MonographPanel in depending on the > user's choice of type. If CompoundPropertyModels are evil (and I'd like a > pointer to why), CPMs work great when they do, but when they do not it is extremely difficult to find out why - as you have discovered in this case. their implicit nature makes it so. this is why they are evil. > how can I take a IModel and turn it into a IModel and > IModel, and so on? you have to cast it because only you know that at some point Publication is actually a Book. > Does the metagen project handle the polymorphism? not in this case, just like java cant. > Should I be using the single-argument constructor of FormComponentPanel at > all? not sure. would need to see more code > Does it matter if I need to use the PublicationPanel more than once in the > ReportForm? it shouldnt. -igor > > Respectfully, > Eric Jablow > > This communication, along with any attachments, is covered by federal and > state law governing electronic communications and may contain company > proprietary and legally privileged information. If the reader of this > message is not the intended recipient, you are hereby notified that any > dissemination, distribution, use or copying of this message is strictly > prohibited. If you have received this in error, please reply immediately to > the sender and delete this message. Thank you. > > > - > 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: Metagen configuration issue
try removing the configuration block of the maven-processor-plugin and change the location of the helper plugin to generated-sources/annotations -igor On Fri, Nov 18, 2011 at 10:57 AM, Jablow, Eric R wrote: > I've cut and pasted the Metagen configuration listed in > https://github.com/42Lines/metagen into my project pom, and these > declarations are generating the metamodels twice: in > target/generated-sources/annotations, and in target/metamodel. What must I do > to cut out one of the metamodel locations? I'm a Maven novice. > > Respectfully, > Eric Jablow > > This communication, along with any attachments, is covered by federal and > state law governing electronic communications and may contain company > proprietary and legally privileged information. If the reader of this > message is not the intended recipient, you are hereby notified that any > dissemination, distribution, use or copying of this message is strictly > prohibited. If you have received this in error, please reply immediately to > the sender and delete this message. Thank you. > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: LoadableDetachableModel getObject not final
getObject() is what defines the contract of load(). if we make it overridable the user can then break the load() function - for example by not calling it from the override. why would you want to override getobject()? -igor On Fri, Nov 18, 2011 at 10:39 AM, Tito wrote: > Hi, > > I'm wondering if it is ok not to do 'final' this method. > Correct me if I'm wrong but I think it is not normal to Override this > method because we always have to Override load(). > > It's just a question to know what do you think. > > Thanks! > > Norberto > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
RE: Metagen configuration issue
>From: Igor Vaynberg [mailto:igor.vaynb...@gmail.com] Sent: Friday, November 18, 2011 2:21 PM To: users@wicket.apache.org Subject: Re: Metagen configuration issue try removing the configuration block of the maven-processor-plugin and change the location of the helper plugin to generated-sources/annotations --- This didn't work. Now, I have two identical directories, generated-sources/annotations, and generated-sources/apt. I cleaned my project, and then I replaced generated-sources/annotations with generated-sources/apt in the build-helper-maven-plugin. That failed, so I put generated-sources/apt in the maven-processor-plugin. I still have generated-sources/annotations and generated-sources/apt Eric . This communication, along with any attachments, is covered by federal and state law governing electronic communications and may contain company proprietary and legally privileged information. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, use or copying of this message is strictly prohibited. If you have received this in error, please reply immediately to the sender and delete this message. Thank you. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Metagen configuration issue
very strange. we are using the configuration on the github page and its working great here. try using the original configuration and add 2.0.5 to the maven processor plugin, maybe you are just using an old one. also add this into your pom so you can get to 2.0.5 sonatype-repo https://oss.sonatype.org/content/repositories/releases -igor On Fri, Nov 18, 2011 at 11:38 AM, Jablow, Eric R wrote: >>From: Igor Vaynberg [mailto:igor.vaynb...@gmail.com] > Sent: Friday, November 18, 2011 2:21 PM > To: users@wicket.apache.org > Subject: Re: Metagen configuration issue > > try removing the configuration block of the maven-processor-plugin and > change the location of the helper plugin to > generated-sources/annotations > > --- > > This didn't work. Now, I have two identical directories, > generated-sources/annotations, and generated-sources/apt. > > I cleaned my project, and then I replaced generated-sources/annotations with > generated-sources/apt in the build-helper-maven-plugin. That failed, so I put > generated-sources/apt in the maven-processor-plugin. I still have > generated-sources/annotations and generated-sources/apt > > Eric > . > This communication, along with any attachments, is covered by federal and > state law governing electronic communications and may contain company > proprietary and legally privileged information. If the reader of this > message is not the intended recipient, you are hereby notified that any > dissemination, distribution, use or copying of this message is strictly > prohibited. If you have received this in error, please reply immediately to > the sender and delete this message. Thank you. > > > - > 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: Metagen configuration issue
-Original Message- From: Igor Vaynberg [mailto:igor.vaynb...@gmail.com] Sent: Friday, November 18, 2011 2:43 PM To: users@wicket.apache.org Subject: Re: Metagen configuration issue very strange. we are using the configuration on the github page and its working great here. try using the original configuration and add 2.0.5 to the maven processor plugin, maybe you are just using an old one. also add this into your pom so you can get to 2.0.5 I think it's the version of the build-helper-maven-plugin. You have 1.3. I was using the latest, 1.7. I just switched to 1.3 and ran. Now, a build gives me generated-sources/apt and target/generated-sources/annotations. I then switched back to 1.7, and I removed the build-helper plugin. The maven-processor-plugin usage page claims that Sources will be generated into target/generated-sources/apt/main/java. Test sources into target/generated-sources/apt/test/java Both directories will be added to the compilation path One thing we're missing is the code on the usage page: org.apache.maven.plugins maven-compiler-plugin -proc:none Perhaps the compiler was running the annotation processor itself. And, it works! So, with later versions of the compiler plugin, you need to keep it from running the annotation processor itself. Respectfully, Eric Jablow This communication, along with any attachments, is covered by federal and state law governing electronic communications and may contain company proprietary and legally privileged information. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, use or copying of this message is strictly prohibited. If you have received this in error, please reply immediately to the sender and delete this message. Thank you. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Metagen configuration issue
sweet, thanks. i will add it to the readme -igor On Fri, Nov 18, 2011 at 12:23 PM, Jablow, Eric R wrote: > > > -Original Message- > From: Igor Vaynberg [mailto:igor.vaynb...@gmail.com] > Sent: Friday, November 18, 2011 2:43 PM > To: users@wicket.apache.org > Subject: Re: Metagen configuration issue > > very strange. we are using the configuration on the github page and > its working great here. > > try using the original configuration and add 2.0.5 > to the maven processor plugin, maybe you are just using an old one. > > also add this into your pom so you can get to 2.0.5 > > I think it's the version of the build-helper-maven-plugin. You have 1.3. I > was using the latest, 1.7. I just switched to 1.3 and ran. Now, a build > gives me generated-sources/apt and target/generated-sources/annotations. > > I then switched back to 1.7, and I removed the build-helper plugin. The > maven-processor-plugin usage page claims that > > Sources will be generated into target/generated-sources/apt/main/java. > Test sources into target/generated-sources/apt/test/java Both directories > will be added to the compilation path > > One thing we're missing is the code on the usage page: > > > org.apache.maven.plugins > maven-compiler-plugin > > -proc:none > > > > Perhaps the compiler was running the annotation processor itself. And, it > works! So, with later versions of the compiler plugin, you need to keep it > from running the annotation processor itself. > > Respectfully, > Eric Jablow > > This communication, along with any attachments, is covered by federal and > state law governing electronic communications and may contain company > proprietary and legally privileged information. If the reader of this > message is not the intended recipient, you are hereby notified that any > dissemination, distribution, use or copying of this message is strictly > prohibited. If you have received this in error, please reply immediately to > the sender and delete this message. Thank you. > > > - > 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: Metagen configuration issue
-Original Message- From: Igor Vaynberg [mailto:igor.vaynb...@gmail.com] Sent: Friday, November 18, 2011 4:04 PM To: users@wicket.apache.org Subject: Re: Metagen configuration issue sweet, thanks. i will add it to the readme -igor > > > org.apache.maven.plugins > maven-compiler-plugin > > -proc:none > > > > Perhaps the compiler was running the annotation processor itself. And, it > works! So, with later versions of the compiler plugin, you need to keep it > from running the annotation processor itself. > > Respectfully, > Eric Jablow Note that Eclipse users will be unhappy unless one adds this to the pom: org.apache.maven.plugins maven-eclipse-plugin 2.8 target/generated-sources/apt I have no idea about other IDEs. Perhaps the plugin I removed would have handled that. Respectfully, Eric Jablow This communication, along with any attachments, is covered by federal and state law governing electronic communications and may contain company proprietary and legally privileged information. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, use or copying of this message is strictly prohibited. If you have received this in error, please reply immediately to the sender and delete this message. Thank you. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Metagen configuration issue
yes, thats what it did :) -igor On Fri, Nov 18, 2011 at 1:09 PM, Jablow, Eric R wrote: > > -Original Message- > From: Igor Vaynberg [mailto:igor.vaynb...@gmail.com] > Sent: Friday, November 18, 2011 4:04 PM > To: users@wicket.apache.org > Subject: Re: Metagen configuration issue > > sweet, thanks. i will add it to the readme > > -igor >> >> >> org.apache.maven.plugins >> maven-compiler-plugin >> >> -proc:none >> >> >> >> Perhaps the compiler was running the annotation processor itself. And, it >> works! So, with later versions of the compiler plugin, you need to keep it >> from running the annotation processor itself. >> >> Respectfully, >> Eric Jablow > > Note that Eclipse users will be unhappy unless one adds this to the pom: > > > org.apache.maven.plugins > maven-eclipse-plugin > 2.8 > > target/generated-sources/apt > > > > I have no idea about other IDEs. Perhaps the plugin I removed would have > handled that. > > Respectfully, > Eric Jablow > > This communication, along with any attachments, is covered by federal and > state law governing electronic communications and may contain company > proprietary and legally privileged information. If the reader of this > message is not the intended recipient, you are hereby notified that any > dissemination, distribution, use or copying of this message is strictly > prohibited. If you have received this in error, please reply immediately to > the sender and delete this message. Thank you. > > > - > 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: Ajax busy indicator getting stuck
That sounds reasonable. According to the scenario I described above, the indicator will always get stuck if you use channel type Drop and issue an ajax request on a busy channel. 2011/11/18 coincoinfou : > Same problem with IndicatingAjaxLink when I switch to AjaxChannel.Type.DROP > > -- > View this message in context: > http://apache-wicket.1842946.n4.nabble.com/Ajax-busy-indicator-getting-stuck-tp4082837p4083026.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: Ajax busy indicator getting stuck
quickstart, jira? -igor On Fri, Nov 18, 2011 at 1:20 PM, Nazaret Kazarian wrote: > That sounds reasonable. According to the scenario I described above, > the indicator will always get stuck if you use channel type Drop and > issue an ajax request on a busy channel. > > > > 2011/11/18 coincoinfou : >> Same problem with IndicatingAjaxLink when I switch to AjaxChannel.Type.DROP >> >> -- >> View this message in context: >> http://apache-wicket.1842946.n4.nabble.com/Ajax-busy-indicator-getting-stuck-tp4082837p4083026.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 > > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Ajax busy indicator getting stuck
Yep, I will create a quickstart and create a jira. If it turns out to be a bug, until it gets solved, I am thinking of showing / hiding the busy indicator using js pre/post call handlers. And maybe also use the following code as a condition in post call handler to hide the indicator: wicketAjaxBusy: function() { for (var c in Wicket.channelManager.channels) { if (Wicket.channelManager.channels[c].busy) { return true; } } return false; } Do you think that's a good idea? 2011/11/18 Igor Vaynberg : > quickstart, jira? > > -igor > > On Fri, Nov 18, 2011 at 1:20 PM, Nazaret Kazarian > wrote: >> That sounds reasonable. According to the scenario I described above, >> the indicator will always get stuck if you use channel type Drop and >> issue an ajax request on a busy channel. >> >> >> >> 2011/11/18 coincoinfou : >>> Same problem with IndicatingAjaxLink when I switch to AjaxChannel.Type.DROP >>> >>> -- >>> View this message in context: >>> http://apache-wicket.1842946.n4.nabble.com/Ajax-busy-indicator-getting-stuck-tp4082837p4083026.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 >> >> > > - > 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
Wicket Gradle build
Hi, Are the Wicket Gradle build files maintained and in sync with the poms? Is the eclipse integration with Gradle working well? I'd like to give Gradle a try but only if I can build Wicket with it too. I searched the dev and user lists and couldn't find a definitive answer. Regards, Bertrand - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket Gradle build
no, they are not. its something we tried but in the end decided not to use...i will add a comment to the gradle file... -igor On Fri, Nov 18, 2011 at 1:47 PM, Bertrand Guay-Paquet wrote: > Hi, > > Are the Wicket Gradle build files maintained and in sync with the poms? Is > the eclipse integration with Gradle working well? I'd like to give Gradle a > try but only if I can build Wicket with it too. > > I searched the dev and user lists and couldn't find a definitive answer. > > Regards, > Bertrand > > - > 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: Wicket Gradle build
Thanks for the info! I guess I'll keep "enjoying" Maven some more :) On 18/11/2011 4:48 PM, Igor Vaynberg wrote: no, they are not. its something we tried but in the end decided not to use...i will add a comment to the gradle file... -igor On Fri, Nov 18, 2011 at 1:47 PM, Bertrand Guay-Paquet wrote: Hi, Are the Wicket Gradle build files maintained and in sync with the poms? Is the eclipse integration with Gradle working well? I'd like to give Gradle a try but only if I can build Wicket with it too. I searched the dev and user lists and couldn't find a definitive answer. Regards, Bertrand - 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 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Apache Wicket is a Flawed Framework
First of all, sorry for my previous comment. It was wrong judging you instead discussing the points addressed in your post. Nevertheless, nobody hates you for your opinion :). This kind of posts appears from time to time and there is nothing wrong with them as long as these address valid issues (which is not the case this time). You cannot please everybody. The only problem is the way you titled your post - that is the real bashing. When writing this kind of post, don't forget that you are bashing not only the framework, but also the time and effort of the people who contributed to this open source project. A constructive critique is always appreciated. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Apache-Wicket-is-a-Flawed-Framework-tp4080411p4084976.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: AjaxEditableLabel inside of AjaxEditableLabel
I am not sure how to stop propagating the event. Could you please provide any pointers? Here is the relevant code: final String keypress = "var kc=wicketKeyCode(event); if (kc==27) " + cancelCall + " else if (kc!=13) { return true; } else " + saveCall; tag.put("onblur", saveCall); tag.put("onkeypress", "if (Wicket.Browser.isSafari()) { return; }; " + keypress); tag.put("onkeydown", "if (!Wicket.Browser.isSafari()) { return; }; " + keypress); On Fri, Nov 18, 2011 at 12:32 AM, Martin Grigorov wrote: > Hi, > > You'll need to stop the propagation of the event. > To do that you'll have to override > org.apache.wicket.extensions.ajax.markup.html.AjaxEditableLabel.EditorAjaxBehavior.onComponentTag(ComponentTag) > > On Fri, Nov 18, 2011 at 7:48 AM, Alec Swan wrote: >> Hello, >> >> I have two AjaxEditableLabel components. I use jQuery to place one >> component inside of another when the user views the page. The problem >> is that when the user clicks inside of the inner AjaxEditableLabel it >> goes into edit mode but right after that the outer AjaxEditableLabel >> goes into edit mode. >> >> How can I prevent the outer AjaxEditableLabel from going into edit mode? >> >> Thanks, >> >> Alec >> >> - >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> > > > > -- > Martin Grigorov > jWeekend > Training, Consulting, Development > http://jWeekend.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: Apache Wicket is a Flawed Framework
Needless to say, I don't particularly agree with most of the criticisms listed. And for the right job, Java isn't half as bad as you seem to think. I'd say the trouble is Java vs. the JDK (and other libraries). While Java itself is still reasonably cool, there is a lot of real crap out there. And there's plenty in the JDK! But if you're determined to program well, you can wrap and hide the majority of this crap quite excellently in Java. What you're left with is a screaming fast server-side programming language with more support in terms of platforms and functionality than anything in history. While I'd love to see a Scala where I can read 90% of the source code out there at a glance like I can with Java, I'll stick with Java (at least on the server side) for now. Given that you hate Wicket and Java (and have a LOT of energy for that given the length of your post), why don't you switch jobs? You sound unhappy with your gig. And although the economy is down, software is actually quite hot and there are a lot of jobs for people that just want to hack on loosely typed UI scripts. Heck, I'm getting emails from headhunters almost daily. I'd say life is too short to lump it. If Wicket doesn't suit you, switch frameworks. If it's required at work and that makes you hate your job, switch jobs. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Apache-Wicket-is-a-Flawed-Framework-tp4080411p4085067.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: Wicket Gradle build
just for giggles, i enjoy Wicket + Gradle and maintain both here, slightly modified to fit my needs. you can get the gradle build files as examples for 1.5. https://github.com/robmcguinness/wicket https://github.com/robmcguinness/wicket -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Wicket-Gradle-build-tp4084846p4085506.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: Chained dropdowns
show the code On Fri, Nov 18, 2011 at 1:36 PM, Tito wrote: > Hi, I'm trying to connect three drowpdowns. > > For example. > > combo1: Country > combo2: Province > combo3: City > > I'm updating dropdowns by Ajax with > AjaxFormComponentUpdatingBehavior("onChange") and it works ok. > But if you choose a Country, then a Province, then a City and after that > you change the Country, the Province changes but not the city. > > I'm doing everything with models and adding all dropdowns to > AjaxRequestTarget. > > Regards > > Norberto > -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org*
Re: Ajax busy indicator getting stuck
that might work. -igor On Fri, Nov 18, 2011 at 1:45 PM, Nazaret Kazarian wrote: > Yep, I will create a quickstart and create a jira. > > If it turns out to be a bug, until it gets solved, I am thinking of > showing / hiding the busy indicator using js pre/post call handlers. > And maybe also use the following code as a condition in post call > handler to hide the indicator: > > wicketAjaxBusy: function() { > for (var c in Wicket.channelManager.channels) { > if (Wicket.channelManager.channels[c].busy) { > return true; > } > } > return false; > } > > Do you think that's a good idea? > > > 2011/11/18 Igor Vaynberg : >> quickstart, jira? >> >> -igor >> >> On Fri, Nov 18, 2011 at 1:20 PM, Nazaret Kazarian >> wrote: >>> That sounds reasonable. According to the scenario I described above, >>> the indicator will always get stuck if you use channel type Drop and >>> issue an ajax request on a busy channel. >>> >>> >>> >>> 2011/11/18 coincoinfou : Same problem with IndicatingAjaxLink when I switch to AjaxChannel.Type.DROP -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Ajax-busy-indicator-getting-stuck-tp4082837p4083026.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 >>> >>> >> >> - >> 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 > > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org