Re: Wicket libraries
Hi, May be, a solution for your case would be to use ivy ant tasks to manage/list the dependencies of wicket. I don't use Ivy, but it could use maven's repositories and pom.xml. I'm not sur it help you, because I don't use it, like lot of, I like maven 2 (dependencies and conventions), and more when I switch to a ant project where I need to read it to understand where are things, what are there scope (test, compile,...) finding the right jars when I try Seam one year ago was a headhache... but it's off topic. /david Robo wrote: Hello, Ok, seems removing \wicket-velocity-1.3.0-beta3.jar\ from build path solved problem with velocity problem. But please explain me why removing package from build path solves the problem if nowhere in my Hello World code i call for any of the velocity packages. Is there some duplicities in packages or what? As to Maven2. It seems that like you in some way force developers to Maven2. :-) In wicket inAction EA there is just mentioned that when using Ant you need to do some work about libraries ant Maven manages it for you. This is too little for serious docs. Please do look into Icefaces free docs. There is steb by step mentioned what libs one need to enable which feature and the libs are added as demo app more feature ritch. Developer needs to understand core functionalities and dependencies. Just After understandig this developer is able to set up Ant project, make project, Eclipse or Netbeans based project and if you want also Maven. :-) But many of the advices about libs was \Use Maven2\ like. If you use it, so use it but do not force me to use it. Explain in some part od book or docs what do I need to run which part of wicket to save my time to go into jars and solve dependencies troubles. Yes Maven solves you some problems with dependecies and also si suitable for small pr oject but at big projects it definitely fails. :-/ So please. I know you have lot of work with wicket, and as users can see you have a good aproach. But please do spend some time to at least write one chapter about libraries, neede dependencies and so on. If you have licensing problems just make one clear site with core libs link, dep libs link and explanation what feature they are enabling and so on. And make some quick start page in which you explainn dependecies on simple sample app :-)Do not take alibistic aproach of hiding everithing besides Maven. :-) Off topic section: We use Maven for more than one year, also Maven2, in the begining there was some WoW`s about how Maven Manages project. Really great. But as the project continued and wee needed to add many not so standard feature to project, like advanced autorization, very non standard libraries we were forced in the troubles wchich could be avoided when there was no Maven2. also the project layout is not the best for our taste. IMHO of cource. Rewriting project build to ANT took us 6 days, but from that time we saved us a lot of time and nerves of solving Maven troubles. From that time we just developed, exactly what we were paid for. Idea of Maven2 is very nice and usefull, but implementation is kind of tragedy :-/. If I would Alayster Crowley I`d like Maven. Because its black magic, but I`m just dump developer who is not even to able to hypnotize someone :-)). as we talked about Ant and Maven2 we really realized the good sides of Maven. but Ant has simple basic idea with few bilding bl oc ks, which when you combine them wiselly works perfectly. YOU do no need to study Ant. Just use it. In Maven wee need to study Maven, Study black Magic without success. :-) It remainds me of one Joke. Americans was looking for some pen, which could be used in space without troubles, They invested 1 000 000 $ in research and finally had one. Russians in the meantime used pencils. :-) (If you do not like Russians just switch the roles ;-) ) So we found Maven2 usefull with small to mid project with some commonly used libraries but here it stops. Once you set up good dependencies in Ant you well understand what library you use and why (maven shields you from this in some way) and yuo are able to solve troubles with build system fast. We do not really to care about looking for jars in google. Using Maven it is not that time saving. It is more confortable I agree, but not worth the time to solve Maven troubles. There is lot of buzz about \Convention over configuration\, But if that convention is badly designed, like Maven project layout, our aproach is flexibility over convention. (Jsp is convention but then came grrat wicket wchich is typical flexibility over convention, or good convention over bad convention :-) ). But reality besides Rails and Wicket I did not see any good convention (over configuration). EnD of off topic: Uff ;-) Robert - Originálna Správa - Od: Jonathan Locke Komu: Poslaná: 06.09.2007 04:07 Predmet: Re: Wicket libraries not only would the download be bigger, but
Page state, undo and versioning?
Hi, My scenario is the following, I've got a page that allows a user to send an sms to themselves every 20 seconds to a maximum of two times just incase something in the network stopped the sms from getting to them in the first place. I have an ajax timer that enables the resend button after the specified time and a count property of the page that stores the number of retries. All works well and the button is disabled and enabled as expected in the normal flow of events. BUT when the user hits the back button after everything has been disabled it's all enabled again, it's clearly to do with the undo ability of wicket but no matter what I try I can't seemed to keep those components disabled on an undo. I've tried: - setting the page to versioned/unversioned - checking the page state onBeforeRendering and trying to set the value What's really missing in my mind is a fundemental UNDERSTANDING of how this works and how I deal with this problem. It seems such as simple thing but I'm more then a little confused and starting to get irked. So my questions (plural) are the following: - where can I read more about what happens when the back button is hit? - is there a way I can TEST this scenario with WicketTester? - how do I keep that page in the same state on back being hit - Maybe I'm tackling this the wrong way and I should be storing the state in a session? Thanks as always Simon ps. Wicket rocks, it's just my understanding that doesn't
Re: Twice Behavior on the same event handler (wicket 1.2.x)
I am curious, what is your use case for chaining behaviors? I think that if you have two things that you want to chain, then chain them in the same handler, or use decorator to add the client-side code. Alex paolo di tommaso wrote: Carlos, Can you provide an example of your custom implementation of chained behaviour? Thanks, Paolo On 9/6/07, Carlos Pita [EMAIL PROTECTED] wrote: Currently people will have to build it in themselves like you did. We can investigate whether this can be improved for future versions, but From my own experience I wouldn't say that wicket should support this. It's too easy to write it yourself just to fit your specific needs, and otoh seems difficult to predict and support a significant number of possible use cases in a general way that keeps everyone happy, as you remarked. Regards, Carlos Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Twice-Behavior-on-the-same-event-handler-%28wicket-1.2.x%29-tf4386351.html#a12518265 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Strange bug in Wicket-1.3.0-beta2
You should try this with latest trunk. This should be fixed already, but after beta 3. -Matej On 9/6/07, Alex Objelean [EMAIL PROTECTED] wrote: When using wicket-1.3.0-beta3, still have the same problem. Here is again the stacktrace: org.apache.wicket.WicketRuntimeException: component body:panel:actionDetailsContainer:actionDetails:panel:pricesTabPanel:panel:tableContainer:pricesColumnContainer:pricesColumn:199 not found on page ro.isdc.centerparcs.dpa.ui.page.DPADashboardPage[id = 0], listener interface = [RequestListenerInterface name=IBehaviorListener, method=public abstract void org.apache.wicket.behavior.IBehaviorListener.onRequest()] at org.apache.wicket.request.AbstractRequestCycleProcessor.resolveListenerInterfaceTarget(AbstractRequestCycleProcessor.java:394) at org.apache.wicket.request.AbstractRequestCycleProcessor.resolveRenderedPage(AbstractRequestCycleProcessor.java:440) at org.apache.wicket.protocol.http.WebRequestCycleProcessor.resolve(WebRequestCycleProcessor.java:139) at org.apache.wicket.RequestCycle.step(RequestCycle.java:1091) at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1177) at org.apache.wicket.RequestCycle.request(RequestCycle.java:500) at org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:261) at org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:127) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:264) at org.acegisecurity.intercept.web.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:107) at org.acegisecurity.intercept.web.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:72) at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274) at org.acegisecurity.ui.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:110) at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274) at org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:217) at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274) at org.acegisecurity.ui.logout.LogoutFilter.doFilter(LogoutFilter.java:106) at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274) at org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:229) at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274) at org.acegisecurity.util.FilterChainProxy.doFilter(FilterChainProxy.java:148) at org.acegisecurity.util.FilterToBeanProxy.doFilter(FilterToBeanProxy.java:98) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684) at java.lang.Thread.run(Thread.java:595) igor.vaynberg wrote: try with latest trunk -igor On 8/15/07, Alex Objelean [EMAIL PROTECTED] wrote: I've got randomly an exception when clicking on the table row which has an AjaxEventBehavior assigned. Below is the stacktrace. Any ideas? [10:34:27.875] ERROR [http-8080-Processor1] RequestCycle - component body:panel:actionListContainer:actionList:form:actionList:14 not found on page ro.isdc.centerparcs.dpa.ui.page.DPADashboardPage[id = 0], listener interface = [RequestListenerInterface name=IBehaviorListener, method=public abstract void org.apache.wicket.behavior.IBehaviorListener.onRequest()] org.apache.wicket.WicketRuntimeException: component body:panel:actionListContainer:actionList:form:actionList:14 not found on page
Re: Strange bug in Wicket-1.3.0-beta2
Right now, I do not know if this kind of issue can be fixed on the wicket side. But what I do know for sure, is that this have to do with making multiple ajax request which are scheduled by the Wicket.Channel and are executed synchronously and which affects the DOM when the response is arrived, thus the component tree is out of sync with the actual DOM. (For instance user clicks 5 times on the Edit button, which is a slow operation and its response change the component's DOM) I am searching for workarounds for this issue. It is about preventing user to make multiple request (blocking), but this is not that easy (God bless IE). Alex Alex Objelean wrote: I've got randomly an exception when clicking on the table row which has an AjaxEventBehavior assigned. Below is the stacktrace. Any ideas? [10:34:27.875] ERROR [http-8080-Processor1] RequestCycle - component body:panel:actionListContainer:actionList:form:actionList:14 not found on page ro.isdc.centerparcs.dpa.ui.page.DPADashboardPage[id = 0], listener interface = [RequestListenerInterface name=IBehaviorListener, method=public abstract void org.apache.wicket.behavior.IBehaviorListener.onRequest()] org.apache.wicket.WicketRuntimeException: component body:panel:actionListContainer:actionList:form:actionList:14 not found on page ro.isdc.centerparcs.dpa.ui.page.DPADashboardPage[id = 0], listener interface = [RequestListenerInterface name=IBehaviorListener, method=public abstract void org.apache.wicket.behavior.IBehaviorListener.onRequest()] at org.apache.wicket.request.AbstractRequestCycleProcessor.resolveListenerInterfaceTarget(AbstractRequestCycleProcessor.java:394) at org.apache.wicket.request.AbstractRequestCycleProcessor.resolveRenderedPage(AbstractRequestCycleProcessor.java:440) at org.apache.wicket.protocol.http.WebRequestCycleProcessor.resolve(WebRequestCycleProcessor.java:139) at org.apache.wicket.RequestCycle.step(RequestCycle.java:1090) at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1176) at org.apache.wicket.RequestCycle.request(RequestCycle.java:499) at org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:257) at org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:127) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:264) at org.acegisecurity.intercept.web.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:107) at org.acegisecurity.intercept.web.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:72) at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274) at org.acegisecurity.ui.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:110) at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274) at org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:217) at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274) at org.acegisecurity.ui.logout.LogoutFilter.doFilter(LogoutFilter.java:106) at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274) at org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:229) at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274) at org.acegisecurity.util.FilterChainProxy.doFilter(FilterChainProxy.java:148) at org.acegisecurity.util.FilterToBeanProxy.doFilter(FilterToBeanProxy.java:98) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664) at
Re: JavaScript Frameworks
Sure i wanna do real programming in javascript. My issue was, the back end devs here can tap away writing wicket but it wont cover 100% of the interactions that are needed on the front end. So I hoped that if wicked used a preferred JS framework for some of its widgets I could save alot of overhead and go with that on the _other_ frontend interactions i have to deal with. Anyways, thanks for the help people. Johan Compagner wrote: ahh so you want to do real programming in the javascript? So attaching purely in client side javascript events and those events call the server? Thats not how wicket works, in wicket you normally don't program javascript you get it pushed and the events get attached by the serverside. johan On 9/5/07, bmarvell [EMAIL PROTECTED] wrote: Sorry, Again mine is coming from a very front end perspective ie writing JS in a progressive enhancement style. Your pseudo code looks like the other end of the spectrum ie java code My main point over this thread was to also appreciate that while wicket is designed for java devs it needs to have JS framework code that can be used by UI developers. Hence why I believe having the ability to write things in a front end way is a GOOD thing. Nino Saturnino Martinez Vazquez Wael wrote: hmm I'll have to take a deeper look into this. The main idea about the input events are that you should be able to just add events of any sort (mouse, key, time?) to anycomponent that will either trigger that component or another, this means triggering from client to server. No real work has been done on the input events project other that the project are setup on the stuff svn, also some base infrastructure has been done. pseudo code example: form myform; label.add(new Event(Events.keypressed(a),Event.keydown, myform)); above should trigger myform when a are pressed and label has focus. disclaimer : this might be bad example:) regards Nino bmarvell wrote: I personally think a CSS DOM traversal/manipulation model that can tie to events elegantly is what's needed. i.e: http://jquery.com http://bennolan.com/behaviour/ Being able to say: $(#somthing li).click(. Is so much easier to code and read than: document.getElementById (something).getElementsByTagName(li).. Nino Saturnino Martinez Vazquez Wael wrote: on the Events part I might aswell go on with the input events contrib... As this now has been up a lot of times one the mailing list.. I might seem to find some time to do it.. But it would be really nice to see what people would like of features from it? regards Nino bmarvell wrote: Right then so for completeness: * Ajax Calls [In house] * Animation [animator.js] * Dom manipulation and traversal (CSS style for this is becoming highly favourable) [??] * Events [??] Has any of this been addressed or considered yet? I'm just coming in from the point of a front end developer and trying to identify whats either missing or I cant find :confused: Gerolf Seitz wrote: So for those specific issues are we to say: http://martijndashorst.com/blog/2007/04/16/javascript-animation-libraries-compared/ Is the future?? in this case, take a look at http://wicketstuff.org/confluence/display/STUFFWIKI/wicketstuff-animator ;) gerolf Matej Knopp-2 wrote: Hi, this question has been asked here numerous times. The thing is, there is in fact no real alternative of wicket-ajax for us. Wicket is not built about Ajax widgets.Wicket is about server-side components that can be partially updated using Ajax. That's a fundamental difference. As for the features, wicket-ajax has numerous advanced features such as - asynchronous pipeline that allows loading dependencies in asynchronous way, yet respecting the order (unlike e.g. dojo where the depending javascript are loaded using synchronous http requests which block entire browser = usability disaster) - ajax channels that allow you to stack or drop pending requests - multipart ajax response for replacing multiple components in one response, ajax header contribution processing (so that component can render header response as it would normally do, wicket transparently processes it and loads all dependencies (javascript references, stylesheets, etc) in an asynchronous way while respecting the order) - wicket-ajax.js is about 7kb compressed (with stripped down comments). As this is a general purpose ajax framework, the size matters. For sites where you using ajax only on certain places, having a 200kb javascript dependency would be quite a burden - there's more to it, the code is quite well documented, if you are interested you can dig into it, also you should search achives, this has been discussed here already. -Matej On 9/5/07,
Re: Tracking down an elusive error during migration to 1.3
not the case that David has.. If i write a test case for the ValueMap and i get and put username in it everything works. Ofcourse if i set the debug logging level then i get a debug warning because we do log there when we couldn't find a get or a is property method.. johan On 9/6/07, Igor Vaynberg [EMAIL PROTECTED] wrote: you wrote it! :) -igor On 9/5/07, Johan Compagner [EMAIL PROTECTED] wrote: is also something really going wrong?? because 501 is this: try { method = clz.getMethod(is + name, null); } catch (Exception e) { log.debug(Cannot find getter + clz + . + expression, e); } we try to TEST if we can find it, and then do a debug log if we still can't find it after that we will see that it is a map and fallback on that. johan On 9/5/07, David Leangen [EMAIL PROTECTED] wrote: Migrating from 1.2 to 1.3. I've been trying to track down the cause of the following error. Since this is using reflection, I'm not getting any useful line numbers or direct information on the cause. If anybody can shed some light on this for me, I'd really appreciate it! All I know is that it happens at render time when visiting one of the components, but it's difficult to find the exact component. java.lang.NoSuchMethodException: org.apache.wicket.util.value.ValueMap.isUsername() at java.lang.Class.getMethod(Class.java:1581) at org.apache.wicket.util.lang.PropertyResolver.findGetter( PropertyResolver.java:501) at org.apache.wicket.util.lang.PropertyResolver.getGetAndSetter( PropertyResolver.java:317) ... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Page state, undo and versioning?
On Thursday, September 6, 2007, 9:12:32 AM, wicket [EMAIL PROTECTED] wrote: My scenario is the following, I've got a page that allows a user to send an sms to themselves every 20 seconds to a maximum of two times just incase something in the network stopped the sms from getting to them in the first place. [Offtopic] Does that actually work, as my expectation/experience would suggest that you'll either get two SMs or none? /Gwyn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Progressive Enhancement
Guys, While I'm ruffling the wicket feathers I thought I'd ask about about another issue that's been bothering me with wicket. From what I can see you either have the option of using AJAX or not. This is all well and good but they seem like very forked approaches. So what I'm trying to say is has there been any thought into taking a progressive enhancement approach? Taking that approach would mean pages that were ajax would work if the the user disabled javascript or not. Not to mention a whole wealth of other benefits that can be found here... http://en.wikipedia.org/wiki/Progressive_enhancement Just a question/thought don't flame me ;) -- View this message in context: http://www.nabble.com/Progressive-Enhancement-tf4390623.html#a12518275 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: Wicket libraries stack trace
Hello Gwyn, So after I put wicket-velocity jar in my build path, I`m getting following errors. (I`m using nothing from it and the prove is when I remove it it deploys OK.) ---6.9.2007 11:37:21 org.apache.catalina.core.StandardContext filterStart SEVERE: Exception starting filter HelloWorldApplication java.lang.NoClassDefFoundError: org/apache/velocity/app/Velocity at org.apache.wicket.velocity.Initializer.init(Initializer.java:64) at org.apache.wicket.Application.callInitializers(Application.java:808) at org.apache.wicket.Application.initializeComponents(Application.java:638) at org.apache.wicket.protocol.http.WicketFilter.init(WicketFilter.java:423) at org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:275) at org.apache.catalina.core.ApplicationFilterConfig.setFilterDef(ApplicationFilterConfig.java:397) at org.apache.catalina.core.ApplicationFilterConfig.(ApplicationFilterConfig.java:108) at org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:3693) at org.apache.catalina.core.StandardContext.start(StandardContext.java:4340) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:525) at org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:626) at org.apache.catalina.startup.HostConfig.deployDescriptors(HostConfig.java:553) at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:488) at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1138) at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:311) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:117) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1053) at org.apache.catalina.core.StandardHost.start(StandardHost.java:719) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443) at org.apache.catalina.core.StandardService.start(StandardService.java:516) at org.apache.catalina.core.StandardServer.start(StandardServer.java:710) at org.apache.catalina.startup.Catalina.start(Catalina.java:566) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:288) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:413) 6.9.2007 11:37:25 org.apache.catalina.core.StandardContext filterStart SEVERE: Exception starting filter HelloWorldApplication java.lang.NoClassDefFoundError: org/apache/velocity/app/Velocity at org.apache.wicket.velocity.Initializer.init(Initializer.java:64) at org.apache.wicket.Application.callInitializers(Application.java:808) at org.apache.wicket.Application.initializeComponents(Application.java:638) at org.apache.wicket.protocol.http.WicketFilter.init(WicketFilter.java:423) at org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:275) at org.apache.catalina.core.ApplicationFilterConfig.setFilterDef(ApplicationFilterConfig.java:397) at org.apache.catalina.core.ApplicationFilterConfig.(ApplicationFilterConfig.java:108) at org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:3693) at org.apache.catalina.core.StandardContext.start(StandardContext.java:4340) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:525) at org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:626) at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:511) at org.apache.catalina.startup.HostConfig.check(HostConfig.java:1220) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.tomcat.util.modeler.BaseModelMBean.invoke(BaseModelMBean.java:297) at
Re: Wicket validation flaw?
I thought we were trimming textfield strings, but now i see it's no longer the case. Is it a regression or a feature? Also the missing message doesn't make much sense, can you please report a JIRA issue and attach a quick start project? -Matej On 9/6/07, Alex Objelean [EMAIL PROTECTED] wrote: I've discovered the following issue: When using a DateTextField in a form (with the format: dd/MM/), user by mistake add an extra space (for instance: 06/09/2007 ) and submit the form. The are two problems: 1) I would expect the convertor to convert this value correct, but the AbstractConverter.parse method throws a ConversionException because: (position.getIndex() != stringValue.length()) 2) The above exception is not reported anywhere, because validate method does not check if the input is valid after converting its value: public final void validate() { validateRequired(); if (isValid()) { convertInput(); if (isValid() isRequired() getConvertedInput() == null isInputNullable()) { reportRequiredError(); } /*isn't something like this missing here?*/ if (!isValid()) { /*report Conversion error*/ } if (isValid()) { validateValidators(); } } } Any thoughts? Thank you! Alex. -- View this message in context: http://www.nabble.com/Wicket-validation-flaw--tf4390183.html#a12517215 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket libraries stack trace
On Thursday, September 6, 2007, 9:52:46 AM, Robo [EMAIL PROTECTED] wrote: So after I put wicket-velocity jar in my build path, I`m getting following errors. (I`m using nothing from it and the prove is when I remove it it deploys OK.) ... So please explain me why Tomcat is complaining at deployment time about velocity just including it in the build path? What's happening is that the Wicket Application instance has searched the classpath to read all the wicket.properties files provided. The one in the wicket-velocity jar says initializer=org.apache.wicket.velocity.Initializer, so it's trying to run that initializer instance, but you're missing the dependances. If using Maven, you'd have them, but if not, you can go to MvnRepository (http://mvnrepository.com/) and search which would take you to http://mvnrepository.com/artifact/velocity/velocity/1.4 where it shows that you need velocity-dep-1.4.jar too. That's a useful site to bookmark, whether using Maven or not (probably even more if not!) /Gwyn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Strange bug in Wicket-1.3.0-beta2
Thank you very much Matej! To be honest, I didn't expected to have such a prompt response. :) Btw, when beta-4 is out? Alex. Matej Knopp-2 wrote: Yes, I know what's causing it. And as I said, this should be already taken care of. I've added a special precondition evaluated right before each scheduled ajax request to check if the originating DOM element is still in the document. -Matej On 9/6/07, Alex Objelean [EMAIL PROTECTED] wrote: Right now, I do not know if this kind of issue can be fixed on the wicket side. But what I do know for sure, is that this have to do with making multiple ajax request which are scheduled by the Wicket.Channel and are executed synchronously and which affects the DOM when the response is arrived, thus the component tree is out of sync with the actual DOM. (For instance user clicks 5 times on the Edit button, which is a slow operation and its response change the component's DOM) I am searching for workarounds for this issue. It is about preventing user to make multiple request (blocking), but this is not that easy (God bless IE). Alex Alex Objelean wrote: I've got randomly an exception when clicking on the table row which has an AjaxEventBehavior assigned. Below is the stacktrace. Any ideas? [10:34:27.875] ERROR [http-8080-Processor1] RequestCycle - component body:panel:actionListContainer:actionList:form:actionList:14 not found on page ro.isdc.centerparcs.dpa.ui.page.DPADashboardPage[id = 0], listener interface = [RequestListenerInterface name=IBehaviorListener, method=public abstract void org.apache.wicket.behavior.IBehaviorListener.onRequest()] org.apache.wicket.WicketRuntimeException: component body:panel:actionListContainer:actionList:form:actionList:14 not found on page ro.isdc.centerparcs.dpa.ui.page.DPADashboardPage[id = 0], listener interface = [RequestListenerInterface name=IBehaviorListener, method=public abstract void org.apache.wicket.behavior.IBehaviorListener.onRequest()] at org.apache.wicket.request.AbstractRequestCycleProcessor.resolveListenerInterfaceTarget(AbstractRequestCycleProcessor.java:394) at org.apache.wicket.request.AbstractRequestCycleProcessor.resolveRenderedPage(AbstractRequestCycleProcessor.java:440) at org.apache.wicket.protocol.http.WebRequestCycleProcessor.resolve(WebRequestCycleProcessor.java:139) at org.apache.wicket.RequestCycle.step(RequestCycle.java:1090) at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1176) at org.apache.wicket.RequestCycle.request(RequestCycle.java:499) at org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:257) at org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:127) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:264) at org.acegisecurity.intercept.web.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:107) at org.acegisecurity.intercept.web.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:72) at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274) at org.acegisecurity.ui.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:110) at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274) at org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:217) at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274) at org.acegisecurity.ui.logout.LogoutFilter.doFilter(LogoutFilter.java:106) at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274) at org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:229) at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274) at org.acegisecurity.util.FilterChainProxy.doFilter(FilterChainProxy.java:148) at org.acegisecurity.util.FilterToBeanProxy.doFilter(FilterToBeanProxy.java:98) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) at
Re: Strange bug in Wicket-1.3.0-beta2
Dunno, there's still work to do, but there are snapshot somewhere available, you can grab those if you don't want to build wicket. -Matej On 9/6/07, Alex Objelean [EMAIL PROTECTED] wrote: Thank you very much Matej! To be honest, I didn't expected to have such a prompt response. :) Btw, when beta-4 is out? Alex. Matej Knopp-2 wrote: Yes, I know what's causing it. And as I said, this should be already taken care of. I've added a special precondition evaluated right before each scheduled ajax request to check if the originating DOM element is still in the document. -Matej On 9/6/07, Alex Objelean [EMAIL PROTECTED] wrote: Right now, I do not know if this kind of issue can be fixed on the wicket side. But what I do know for sure, is that this have to do with making multiple ajax request which are scheduled by the Wicket.Channel and are executed synchronously and which affects the DOM when the response is arrived, thus the component tree is out of sync with the actual DOM. (For instance user clicks 5 times on the Edit button, which is a slow operation and its response change the component's DOM) I am searching for workarounds for this issue. It is about preventing user to make multiple request (blocking), but this is not that easy (God bless IE). Alex Alex Objelean wrote: I've got randomly an exception when clicking on the table row which has an AjaxEventBehavior assigned. Below is the stacktrace. Any ideas? [10:34:27.875] ERROR [http-8080-Processor1] RequestCycle - component body:panel:actionListContainer:actionList:form:actionList:14 not found on page ro.isdc.centerparcs.dpa.ui.page.DPADashboardPage[id = 0], listener interface = [RequestListenerInterface name=IBehaviorListener, method=public abstract void org.apache.wicket.behavior.IBehaviorListener.onRequest()] org.apache.wicket.WicketRuntimeException: component body:panel:actionListContainer:actionList:form:actionList:14 not found on page ro.isdc.centerparcs.dpa.ui.page.DPADashboardPage[id = 0], listener interface = [RequestListenerInterface name=IBehaviorListener, method=public abstract void org.apache.wicket.behavior.IBehaviorListener.onRequest()] at org.apache.wicket.request.AbstractRequestCycleProcessor.resolveListenerInterfaceTarget(AbstractRequestCycleProcessor.java:394) at org.apache.wicket.request.AbstractRequestCycleProcessor.resolveRenderedPage(AbstractRequestCycleProcessor.java:440) at org.apache.wicket.protocol.http.WebRequestCycleProcessor.resolve(WebRequestCycleProcessor.java:139) at org.apache.wicket.RequestCycle.step(RequestCycle.java:1090) at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1176) at org.apache.wicket.RequestCycle.request(RequestCycle.java:499) at org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:257) at org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:127) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:264) at org.acegisecurity.intercept.web.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:107) at org.acegisecurity.intercept.web.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:72) at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274) at org.acegisecurity.ui.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:110) at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274) at org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:217) at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274) at org.acegisecurity.ui.logout.LogoutFilter.doFilter(LogoutFilter.java:106) at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274) at org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:229) at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274) at org.acegisecurity.util.FilterChainProxy.doFilter(FilterChainProxy.java:148) at org.acegisecurity.util.FilterToBeanProxy.doFilter(FilterToBeanProxy.java:98) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) at
Re: Strange bug in Wicket-1.3.0-beta2
http://www.wicketstuff.org/maven/repository/org/apache/wicket/ On 9/6/07, Matej Knopp [EMAIL PROTECTED] wrote: Dunno, there's still work to do, but there are snapshot somewhere available, you can grab those if you don't want to build wicket. -Matej On 9/6/07, Alex Objelean [EMAIL PROTECTED] wrote: Thank you very much Matej! To be honest, I didn't expected to have such a prompt response. :) Btw, when beta-4 is out? Alex. Matej Knopp-2 wrote: Yes, I know what's causing it. And as I said, this should be already taken care of. I've added a special precondition evaluated right before each scheduled ajax request to check if the originating DOM element is still in the document. -Matej On 9/6/07, Alex Objelean [EMAIL PROTECTED] wrote: Right now, I do not know if this kind of issue can be fixed on the wicket side. But what I do know for sure, is that this have to do with making multiple ajax request which are scheduled by the Wicket.Channel and are executed synchronously and which affects the DOM when the response is arrived, thus the component tree is out of sync with the actual DOM. (For instance user clicks 5 times on the Edit button, which is a slow operation and its response change the component's DOM) I am searching for workarounds for this issue. It is about preventing user to make multiple request (blocking), but this is not that easy (God bless IE). Alex Alex Objelean wrote: I've got randomly an exception when clicking on the table row which has an AjaxEventBehavior assigned. Below is the stacktrace. Any ideas? [10:34:27.875] ERROR [http-8080-Processor1] RequestCycle - component body:panel:actionListContainer:actionList:form:actionList:14 not found on page ro.isdc.centerparcs.dpa.ui.page.DPADashboardPage[id = 0], listener interface = [RequestListenerInterface name=IBehaviorListener, method=public abstract void org.apache.wicket.behavior.IBehaviorListener.onRequest()] org.apache.wicket.WicketRuntimeException: component body:panel:actionListContainer:actionList:form:actionList:14 not found on page ro.isdc.centerparcs.dpa.ui.page.DPADashboardPage[id = 0], listener interface = [RequestListenerInterface name=IBehaviorListener, method=public abstract void org.apache.wicket.behavior.IBehaviorListener.onRequest()] at org.apache.wicket.request.AbstractRequestCycleProcessor.resolveListenerInterfaceTarget(AbstractRequestCycleProcessor.java:394) at org.apache.wicket.request.AbstractRequestCycleProcessor.resolveRenderedPage(AbstractRequestCycleProcessor.java:440) at org.apache.wicket.protocol.http.WebRequestCycleProcessor.resolve(WebRequestCycleProcessor.java:139) at org.apache.wicket.RequestCycle.step(RequestCycle.java:1090) at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1176) at org.apache.wicket.RequestCycle.request(RequestCycle.java:499) at org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:257) at org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:127) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:264) at org.acegisecurity.intercept.web.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:107) at org.acegisecurity.intercept.web.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:72) at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274) at org.acegisecurity.ui.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:110) at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274) at org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:217) at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274) at org.acegisecurity.ui.logout.LogoutFilter.doFilter(LogoutFilter.java:106) at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274) at org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:229) at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274) at org.acegisecurity.util.FilterChainProxy.doFilter(FilterChainProxy.java:148) at
Re: Wicket validation flaw?
Done, see here: https://issues.apache.org/jira/browse/WICKET-934 WICKET-934 Matej Knopp-2 wrote: I thought we were trimming textfield strings, but now i see it's no longer the case. Is it a regression or a feature? Also the missing message doesn't make much sense, can you please report a JIRA issue and attach a quick start project? -Matej On 9/6/07, Alex Objelean [EMAIL PROTECTED] wrote: I've discovered the following issue: When using a DateTextField in a form (with the format: dd/MM/), user by mistake add an extra space (for instance: 06/09/2007 ) and submit the form. The are two problems: 1) I would expect the convertor to convert this value correct, but the AbstractConverter.parse method throws a ConversionException because: (position.getIndex() != stringValue.length()) 2) The above exception is not reported anywhere, because validate method does not check if the input is valid after converting its value: public final void validate() { validateRequired(); if (isValid()) { convertInput(); if (isValid() isRequired() getConvertedInput() == null isInputNullable()) { reportRequiredError(); } /*isn't something like this missing here?*/ if (!isValid()) { /*report Conversion error*/ } if (isValid()) { validateValidators(); } } } Any thoughts? Thank you! Alex. -- View this message in context: http://www.nabble.com/Wicket-validation-flaw--tf4390183.html#a12517215 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Wicket-validation-flaw--tf4390183.html#a12519551 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Progressive Enhancement
Here is an article on the subject: http://day-to-day-stuff.blogspot.com/2007/01/backward-compatible-ajax-development.html Regards, Erik. Taking that approach would mean pages that were ajax would work if the the user disabled javascript or not. Not to mention a whole wealth of other benefits that can be found here... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Why the AbstractRepeater#onBeforeRender is final wicket-1.3.0-SNAPSHOT (6 sept 2007)?
I've grabbed the latest SNAPSHOT from the repository and have noticed that AbstractRepeater#onBeforeRender is final. I wonder what is the reason for this? (I need to do something in it's subclass) /** * @see org.apache.wicket.Component#onBeforeRender() */ protected final void onBeforeRender() { if (isVisibleInHierarchy()) { onPopulate(); } super.onBeforeRender(); } Alex -- View this message in context: http://www.nabble.com/Why-the-AbstractRepeater-onBeforeRender-is-final-wicket-1.3.0-SNAPSHOT-%286-sept-2007%29--tf4391492.html#a12520558 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Progressive Enhancement
Thanks :) Erik van Oosten wrote: Here is an article on the subject: http://day-to-day-stuff.blogspot.com/2007/01/backward-compatible-ajax-development.html Regards, Erik. Taking that approach would mean pages that were ajax would work if the the user disabled javascript or not. Not to mention a whole wealth of other benefits that can be found here... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Progressive-Enhancement-tf4390623.html#a12520702 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why the AbstractRepeater#onBeforeRender is final wicket-1.3.0-SNAPSHOT (6 sept 2007)?
I would prefer to use onBeforeRender, instead of onPopulate, since it is the I do in other components. Why would I use different life-cycle methods, depending on the component I'm using? Alex Matej Knopp-2 wrote: IMHO that's a bit wrong. You can subclass onPopulate instead, but i think we can remove the code, because after recent changes onBeforeRender() is only called when component is visible in hierarchy. -Matej On 9/6/07, Alex Objelean [EMAIL PROTECTED] wrote: I've grabbed the latest SNAPSHOT from the repository and have noticed that AbstractRepeater#onBeforeRender is final. I wonder what is the reason for this? (I need to do something in it's subclass) /** * @see org.apache.wicket.Component#onBeforeRender() */ protected final void onBeforeRender() { if (isVisibleInHierarchy()) { onPopulate(); } super.onBeforeRender(); } Alex -- View this message in context: http://www.nabble.com/Why-the-AbstractRepeater-onBeforeRender-is-final-wicket-1.3.0-SNAPSHOT-%286-sept-2007%29--tf4391492.html#a12520558 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Why-the-AbstractRepeater-onBeforeRender-is-final-wicket-1.3.0-SNAPSHOT-%286-sept-2007%29--tf4391492.html#a12520766 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why the AbstractRepeater#onBeforeRender is final wicket-1.3.0-SNAPSHOT (6 sept 2007)?
Thank you again, Matej! :) Will it be fixed, or should I create a task in JIRA? Alex Matej Knopp-2 wrote: Some time ago onBeforeRender was called always, even if the component was not visible. This had caused problems with repeaters, therefore this restriction - to make sure onPopulate is called only when component is visible. But IMHO that's no longer necessary. -Matej On 9/6/07, Alex Objelean [EMAIL PROTECTED] wrote: I would prefer to use onBeforeRender, instead of onPopulate, since it is the I do in other components. Why would I use different life-cycle methods, depending on the component I'm using? Alex Matej Knopp-2 wrote: IMHO that's a bit wrong. You can subclass onPopulate instead, but i think we can remove the code, because after recent changes onBeforeRender() is only called when component is visible in hierarchy. -Matej On 9/6/07, Alex Objelean [EMAIL PROTECTED] wrote: I've grabbed the latest SNAPSHOT from the repository and have noticed that AbstractRepeater#onBeforeRender is final. I wonder what is the reason for this? (I need to do something in it's subclass) /** * @see org.apache.wicket.Component#onBeforeRender() */ protected final void onBeforeRender() { if (isVisibleInHierarchy()) { onPopulate(); } super.onBeforeRender(); } Alex -- View this message in context: http://www.nabble.com/Why-the-AbstractRepeater-onBeforeRender-is-final-wicket-1.3.0-SNAPSHOT-%286-sept-2007%29--tf4391492.html#a12520558 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Why-the-AbstractRepeater-onBeforeRender-is-final-wicket-1.3.0-SNAPSHOT-%286-sept-2007%29--tf4391492.html#a12520766 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Why-the-AbstractRepeater-onBeforeRender-is-final-wicket-1.3.0-SNAPSHOT-%286-sept-2007%29--tf4391492.html#a12521043 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why the AbstractRepeater#onBeforeRender is final wicket-1.3.0-SNAPSHOT (6 sept 2007)?
Please do, so that we don't forget. -Matej On 9/6/07, Alex Objelean [EMAIL PROTECTED] wrote: Thank you again, Matej! :) Will it be fixed, or should I create a task in JIRA? Alex Matej Knopp-2 wrote: Some time ago onBeforeRender was called always, even if the component was not visible. This had caused problems with repeaters, therefore this restriction - to make sure onPopulate is called only when component is visible. But IMHO that's no longer necessary. -Matej On 9/6/07, Alex Objelean [EMAIL PROTECTED] wrote: I would prefer to use onBeforeRender, instead of onPopulate, since it is the I do in other components. Why would I use different life-cycle methods, depending on the component I'm using? Alex Matej Knopp-2 wrote: IMHO that's a bit wrong. You can subclass onPopulate instead, but i think we can remove the code, because after recent changes onBeforeRender() is only called when component is visible in hierarchy. -Matej On 9/6/07, Alex Objelean [EMAIL PROTECTED] wrote: I've grabbed the latest SNAPSHOT from the repository and have noticed that AbstractRepeater#onBeforeRender is final. I wonder what is the reason for this? (I need to do something in it's subclass) /** * @see org.apache.wicket.Component#onBeforeRender() */ protected final void onBeforeRender() { if (isVisibleInHierarchy()) { onPopulate(); } super.onBeforeRender(); } Alex -- View this message in context: http://www.nabble.com/Why-the-AbstractRepeater-onBeforeRender-is-final-wicket-1.3.0-SNAPSHOT-%286-sept-2007%29--tf4391492.html#a12520558 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Why-the-AbstractRepeater-onBeforeRender-is-final-wicket-1.3.0-SNAPSHOT-%286-sept-2007%29--tf4391492.html#a12520766 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Why-the-AbstractRepeater-onBeforeRender-is-final-wicket-1.3.0-SNAPSHOT-%286-sept-2007%29--tf4391492.html#a12521043 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
wicket tester / tester.assertResultPage(clazz, filename);
Hi Im trying to create a test that renders a page and then compares it to the expected result. Currently I keep getting diff errors although I just copied the contents of the html file from the tester.dumpPage() and placed it in the expected result file. I guess its just a matter of spaces thats wrong, but not matter how I change them they dont seem to add up apparently. As it can be somewhat a task guessing how the contents of a wicket page might look, I thought this was the most simple approach to doing this but I might be wrong? regards Nino - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: wicket tester / tester.assertResultPage(clazz, filename);
I should also mentioned that Im testing by doing this: WicketTester.assertResultPage(this.getClass(), filename); Nino Saturnino Martinez Vazquez Wael wrote: Hi Im trying to create a test that renders a page and then compares it to the expected result. Currently I keep getting diff errors although I just copied the contents of the html file from the tester.dumpPage() and placed it in the expected result file. I guess its just a matter of spaces thats wrong, but not matter how I change them they dont seem to add up apparently. As it can be somewhat a task guessing how the contents of a wicket page might look, I thought this was the most simple approach to doing this but I might be wrong? regards Nino - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why the AbstractRepeater#onBeforeRender is final wicket-1.3.0-SNAPSHOT (6 sept 2007)?
Done. Here is the issue link: https://issues.apache.org/jira/browse/WICKET-935 WICKET-935 Matej Knopp-2 wrote: Please do, so that we don't forget. -Matej On 9/6/07, Alex Objelean [EMAIL PROTECTED] wrote: Thank you again, Matej! :) Will it be fixed, or should I create a task in JIRA? Alex Matej Knopp-2 wrote: Some time ago onBeforeRender was called always, even if the component was not visible. This had caused problems with repeaters, therefore this restriction - to make sure onPopulate is called only when component is visible. But IMHO that's no longer necessary. -Matej On 9/6/07, Alex Objelean [EMAIL PROTECTED] wrote: I would prefer to use onBeforeRender, instead of onPopulate, since it is the I do in other components. Why would I use different life-cycle methods, depending on the component I'm using? Alex Matej Knopp-2 wrote: IMHO that's a bit wrong. You can subclass onPopulate instead, but i think we can remove the code, because after recent changes onBeforeRender() is only called when component is visible in hierarchy. -Matej On 9/6/07, Alex Objelean [EMAIL PROTECTED] wrote: I've grabbed the latest SNAPSHOT from the repository and have noticed that AbstractRepeater#onBeforeRender is final. I wonder what is the reason for this? (I need to do something in it's subclass) /** * @see org.apache.wicket.Component#onBeforeRender() */ protected final void onBeforeRender() { if (isVisibleInHierarchy()) { onPopulate(); } super.onBeforeRender(); } Alex -- View this message in context: http://www.nabble.com/Why-the-AbstractRepeater-onBeforeRender-is-final-wicket-1.3.0-SNAPSHOT-%286-sept-2007%29--tf4391492.html#a12520558 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Why-the-AbstractRepeater-onBeforeRender-is-final-wicket-1.3.0-SNAPSHOT-%286-sept-2007%29--tf4391492.html#a12520766 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Why-the-AbstractRepeater-onBeforeRender-is-final-wicket-1.3.0-SNAPSHOT-%286-sept-2007%29--tf4391492.html#a12521043 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Why-the-AbstractRepeater-onBeforeRender-is-final-wicket-1.3.0-SNAPSHOT-%286-sept-2007%29--tf4391492.html#a12521149 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Strange bug in Wicket-1.3.0-beta2
With the latest SNAPSHOT, the application throws Exception almost always :(... I thing, it has not been tested too much. Here is the stacktrace: .apache.wicket.WicketRuntimeException: component body:panel:actionListContainer:actionList:form:actionList:65 not found on page ro.isdc.centerparcs.dpa.ui.page.DPADashboardPage[id = 0], listener interface = [RequestListenerInterface name=IBehaviorListener, method=public abstract void org.apache.wicket.behavior.IBehaviorListener.onRequest()] at org.apache.wicket.request.AbstractRequestCycleProcessor.resolveListenerInterfaceTarget(AbstractRequestCycleProcessor.java:393) at org.apache.wicket.request.AbstractRequestCycleProcessor.resolveRenderedPage(AbstractRequestCycleProcessor.java:439) at org.apache.wicket.protocol.http.WebRequestCycleProcessor.resolve(WebRequestCycleProcessor.java:139) at org.apache.wicket.RequestCycle.step(RequestCycle.java:1077) at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1173) at org.apache.wicket.RequestCycle.request(RequestCycle.java:483) at org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:277) at org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:129) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:264) at org.acegisecurity.intercept.web.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:107) at org.acegisecurity.intercept.web.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:72) at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274) at org.acegisecurity.ui.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:110) at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274) at org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:217) at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274) at org.acegisecurity.ui.logout.LogoutFilter.doFilter(LogoutFilter.java:106) at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274) at org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:229) at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274) at org.acegisecurity.util.FilterChainProxy.doFilter(FilterChainProxy.java:148) at org.acegisecurity.util.FilterToBeanProxy.doFilter(FilterToBeanProxy.java:98) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684) at java.lang.Thread.run(Thread.java:595) Matej Knopp-2 wrote: http://www.wicketstuff.org/maven/repository/org/apache/wicket/ On 9/6/07, Matej Knopp [EMAIL PROTECTED] wrote: Dunno, there's still work to do, but there are snapshot somewhere available, you can grab those if you don't want to build wicket. -Matej On 9/6/07, Alex Objelean [EMAIL PROTECTED] wrote: Thank you very much Matej! To be honest, I didn't expected to have such a prompt response. :) Btw, when beta-4 is out? Alex. Matej Knopp-2 wrote: Yes, I know what's causing it. And as I said, this should be already taken care of. I've added a special precondition evaluated right before each scheduled ajax request to check if the originating DOM element is still in the document. -Matej On 9/6/07, Alex Objelean [EMAIL PROTECTED] wrote: Right now, I do not know if this kind of issue can
Howto use AttributeModifier
Hi *, i use wicket-1.2.6. I try to change the background-color of an gridtable item. But i dont get it to work. Is there a howto or doc for it? javadoc is not that detailed. My goal is to display a table with link as cell-content. If i click on the link the cell should be marked selected by changing the color. Maybe there is a better (simplier) way? Thanks for your help Per Here is my code (i removed some not required details, to shorten up the mail). package wicket.quickstart; import java.util.Date; import wicket.AttributeModifier; import wicket.Component; import wicket.PageParameters; import wicket.behavior.SimpleAttributeModifier; import wicket.extensions.markup.html.repeater.data.GridView; import wicket.extensions.markup.html.repeater.data.IDataProvider; import wicket.extensions.markup.html.repeater.data.ListDataProvider; import wicket.extensions.markup.html.repeater.refreshing.Item; import wicket.markup.html.basic.Label; import wicket.markup.html.link.Link; import wicket.model.IModel; import wicket.model.Model; public class SelectDay extends QuickStartPage { private static class HighlitableDataItem extends Item { private boolean highlite = true; private AttributeModifier modifier = null; public void toggleHighlite() { highlite = !highlite; } public HighlitableDataItem(String id, int index, IModel model) { super(id, index, model); modifier = new AttributeModifier(class, selected, new Model() { public Object getObject(Component component) { if (highlite){ return selected; } return deselected; } }); add(modifier); } } public SelectDay(final PageParameters parameters) { List list = new ArrayList(); list.add(1); list.add(2); list.add(3); IDataProvider dataProvider = new ListDataProvider(list); GridView gridView = new GridView(rows, dataProvider) { protected void populateItem(final Item item) { final Integer weekday = (Integer) item .getModelObject(); Link link = new Link(toggleHighlite) { public void onClick() { System.out.println(onclick); HighlitableDataItem hitem = (HighlitableDataItem) item; hitem.toggleHighlite(); } }; link.add(new Label(linklabel, weekday)); item.add(link); item.add(new Label(day, )); } protected void populateEmptyItem(Item item) { throw new UnsupportedOperationException(Unexpected); } protected Item newItem(String id, int index, IModel model) { Item result = null; Object o = model.getObject(this); if (o instanceof Integer) { result = new HighlitableDataItem(id, index, model); result.add(new SimpleAttributeModifier(style, background-color:#ff;)); } else { result = new Item(id, index, model); } return result; } }; gridView.setRows(2); gridView.setColumns(2); add(gridView); } } SelectDay.html !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN html head titleCalendar/title link rel=stylesheet href=buma.css type=text/css media=all / /head body h1QuickStart/h1 pCalendar/p div table class=calendar tbody tr wicket:id=rows td wicket:id=cols a href=# wicket:id=toggleHighlitespan wicket:id=linklabel/span/a span wicket:id=day/span /td /tr /tbody /table /div /body /html buma.css table.calendar { margin:auto; align: center; border-spacing: 3px; } table.calendar td { background: #FFBF00; text-align: center; color: #33; border: 1px solid; border-color: #33; padding: 1px 7px; margin: 3px; empty-cells: hide; } table.calendar .selected { background: #FF; text-align: center; color: #33; border: 1px solid; border-color: #33; padding: 1px 7px; margin: 3px; empty-cells: hide; } table.calendar .deselected { background: #FF00FF; text-align: center; color: #33; border: 1px solid; border-color: #33; padding: 1px 7px; margin: 3px; empty-cells: hide; } -- Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten Browser-Versionen downloaden: http://www.gmx.net/de/go/browser - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to set wicket's locale?
On 9/5/07, Johan Compagner [EMAIL PROTECTED] wrote: can you make an jira issue for this? https://issues.apache.org/jira/browse/WICKET-936 Any ideas on encapsulating the session as a propertymodel for components in 1.2? Gabor - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to set wicket's locale?
new PropertyModel(Page.this, session.foo.sushi.bar); ? On 9/6/07, Gabor Szokoli [EMAIL PROTECTED] wrote: On 9/5/07, Johan Compagner [EMAIL PROTECTED] wrote: can you make an jira issue for this? https://issues.apache.org/jira/browse/WICKET-936 Any ideas on encapsulating the session as a propertymodel for components in 1.2? Gabor - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Buy Wicket in Action: http://manning.com/dashorst Apache Wicket 1.3.0-beta3 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta3/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Strange bug in Wicket-1.3.0-beta2
that's weird. could be a bug in precodition check. Can you please create a jira entry and add a quickstart project? This might be a corner case, I'd like to fix this asap. -Matej On 9/6/07, Alex Objelean [EMAIL PROTECTED] wrote: With the latest SNAPSHOT, the application throws Exception almost always :(... I thing, it has not been tested too much. Here is the stacktrace: .apache.wicket.WicketRuntimeException: component body:panel:actionListContainer:actionList:form:actionList:65 not found on page ro.isdc.centerparcs.dpa.ui.page.DPADashboardPage[id = 0], listener interface = [RequestListenerInterface name=IBehaviorListener, method=public abstract void org.apache.wicket.behavior.IBehaviorListener.onRequest()] at org.apache.wicket.request.AbstractRequestCycleProcessor.resolveListenerInterfaceTarget(AbstractRequestCycleProcessor.java:393) at org.apache.wicket.request.AbstractRequestCycleProcessor.resolveRenderedPage(AbstractRequestCycleProcessor.java:439) at org.apache.wicket.protocol.http.WebRequestCycleProcessor.resolve(WebRequestCycleProcessor.java:139) at org.apache.wicket.RequestCycle.step(RequestCycle.java:1077) at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1173) at org.apache.wicket.RequestCycle.request(RequestCycle.java:483) at org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:277) at org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:129) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:264) at org.acegisecurity.intercept.web.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:107) at org.acegisecurity.intercept.web.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:72) at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274) at org.acegisecurity.ui.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:110) at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274) at org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:217) at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274) at org.acegisecurity.ui.logout.LogoutFilter.doFilter(LogoutFilter.java:106) at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274) at org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:229) at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274) at org.acegisecurity.util.FilterChainProxy.doFilter(FilterChainProxy.java:148) at org.acegisecurity.util.FilterToBeanProxy.doFilter(FilterToBeanProxy.java:98) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684) at java.lang.Thread.run(Thread.java:595) Matej Knopp-2 wrote: http://www.wicketstuff.org/maven/repository/org/apache/wicket/ On 9/6/07, Matej Knopp [EMAIL PROTECTED] wrote: Dunno, there's still work to do, but there are snapshot somewhere available, you can grab those if you don't want to build wicket. -Matej On 9/6/07, Alex Objelean [EMAIL PROTECTED] wrote: Thank you very much Matej! To be honest, I didn't expected to have such a prompt response. :) Btw, when beta-4 is out? Alex. Matej Knopp-2 wrote: Yes, I know what's causing it. And as I
Re: Strange bug in Wicket-1.3.0-beta2
It's quite hard to create a quickstart project, since the project I'm working on is very large. But if you think that it is enough to create a JIRA task with the stacktrace and short description, than I'll do it. Alex Matej Knopp-2 wrote: that's weird. could be a bug in precodition check. Can you please create a jira entry and add a quickstart project? This might be a corner case, I'd like to fix this asap. -Matej On 9/6/07, Alex Objelean [EMAIL PROTECTED] wrote: With the latest SNAPSHOT, the application throws Exception almost always :(... I thing, it has not been tested too much. Here is the stacktrace: .apache.wicket.WicketRuntimeException: component body:panel:actionListContainer:actionList:form:actionList:65 not found on page ro.isdc.centerparcs.dpa.ui.page.DPADashboardPage[id = 0], listener interface = [RequestListenerInterface name=IBehaviorListener, method=public abstract void org.apache.wicket.behavior.IBehaviorListener.onRequest()] at org.apache.wicket.request.AbstractRequestCycleProcessor.resolveListenerInterfaceTarget(AbstractRequestCycleProcessor.java:393) at org.apache.wicket.request.AbstractRequestCycleProcessor.resolveRenderedPage(AbstractRequestCycleProcessor.java:439) at org.apache.wicket.protocol.http.WebRequestCycleProcessor.resolve(WebRequestCycleProcessor.java:139) at org.apache.wicket.RequestCycle.step(RequestCycle.java:1077) at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1173) at org.apache.wicket.RequestCycle.request(RequestCycle.java:483) at org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:277) at org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:129) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:264) at org.acegisecurity.intercept.web.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:107) at org.acegisecurity.intercept.web.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:72) at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274) at org.acegisecurity.ui.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:110) at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274) at org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:217) at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274) at org.acegisecurity.ui.logout.LogoutFilter.doFilter(LogoutFilter.java:106) at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274) at org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:229) at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274) at org.acegisecurity.util.FilterChainProxy.doFilter(FilterChainProxy.java:148) at org.acegisecurity.util.FilterToBeanProxy.doFilter(FilterToBeanProxy.java:98) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684) at java.lang.Thread.run(Thread.java:595) Matej Knopp-2 wrote: http://www.wicketstuff.org/maven/repository/org/apache/wicket/ On 9/6/07, Matej Knopp [EMAIL PROTECTED] wrote: Dunno, there's still work to do, but there are snapshot somewhere available, you can grab those if you don't want to build wicket. -Matej On 9/6/07, Alex
Re: Strange bug in Wicket-1.3.0-beta2
Unfortunately just a jira issue will not od that. Can't you try to isolate the problem? -Matej On 9/6/07, Alex Objelean [EMAIL PROTECTED] wrote: It's quite hard to create a quickstart project, since the project I'm working on is very large. But if you think that it is enough to create a JIRA task with the stacktrace and short description, than I'll do it. Alex Matej Knopp-2 wrote: that's weird. could be a bug in precodition check. Can you please create a jira entry and add a quickstart project? This might be a corner case, I'd like to fix this asap. -Matej On 9/6/07, Alex Objelean [EMAIL PROTECTED] wrote: With the latest SNAPSHOT, the application throws Exception almost always :(... I thing, it has not been tested too much. Here is the stacktrace: .apache.wicket.WicketRuntimeException: component body:panel:actionListContainer:actionList:form:actionList:65 not found on page ro.isdc.centerparcs.dpa.ui.page.DPADashboardPage[id = 0], listener interface = [RequestListenerInterface name=IBehaviorListener, method=public abstract void org.apache.wicket.behavior.IBehaviorListener.onRequest()] at org.apache.wicket.request.AbstractRequestCycleProcessor.resolveListenerInterfaceTarget(AbstractRequestCycleProcessor.java:393) at org.apache.wicket.request.AbstractRequestCycleProcessor.resolveRenderedPage(AbstractRequestCycleProcessor.java:439) at org.apache.wicket.protocol.http.WebRequestCycleProcessor.resolve(WebRequestCycleProcessor.java:139) at org.apache.wicket.RequestCycle.step(RequestCycle.java:1077) at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1173) at org.apache.wicket.RequestCycle.request(RequestCycle.java:483) at org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:277) at org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:129) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:264) at org.acegisecurity.intercept.web.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:107) at org.acegisecurity.intercept.web.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:72) at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274) at org.acegisecurity.ui.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:110) at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274) at org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:217) at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274) at org.acegisecurity.ui.logout.LogoutFilter.doFilter(LogoutFilter.java:106) at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274) at org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:229) at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274) at org.acegisecurity.util.FilterChainProxy.doFilter(FilterChainProxy.java:148) at org.acegisecurity.util.FilterToBeanProxy.doFilter(FilterToBeanProxy.java:98) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684) at java.lang.Thread.run(Thread.java:595) Matej Knopp-2 wrote:
Re: Strange bug in Wicket-1.3.0-beta2
Also, can you post code of the serverside event handler? -Matej On 9/6/07, Matej Knopp [EMAIL PROTECTED] wrote: Unfortunately just a jira issue will not od that. Can't you try to isolate the problem? -Matej On 9/6/07, Alex Objelean [EMAIL PROTECTED] wrote: It's quite hard to create a quickstart project, since the project I'm working on is very large. But if you think that it is enough to create a JIRA task with the stacktrace and short description, than I'll do it. Alex Matej Knopp-2 wrote: that's weird. could be a bug in precodition check. Can you please create a jira entry and add a quickstart project? This might be a corner case, I'd like to fix this asap. -Matej On 9/6/07, Alex Objelean [EMAIL PROTECTED] wrote: With the latest SNAPSHOT, the application throws Exception almost always :(... I thing, it has not been tested too much. Here is the stacktrace: .apache.wicket.WicketRuntimeException: component body:panel:actionListContainer:actionList:form:actionList:65 not found on page ro.isdc.centerparcs.dpa.ui.page.DPADashboardPage[id = 0], listener interface = [RequestListenerInterface name=IBehaviorListener, method=public abstract void org.apache.wicket.behavior.IBehaviorListener.onRequest()] at org.apache.wicket.request.AbstractRequestCycleProcessor.resolveListenerInterfaceTarget(AbstractRequestCycleProcessor.java:393) at org.apache.wicket.request.AbstractRequestCycleProcessor.resolveRenderedPage(AbstractRequestCycleProcessor.java:439) at org.apache.wicket.protocol.http.WebRequestCycleProcessor.resolve(WebRequestCycleProcessor.java:139) at org.apache.wicket.RequestCycle.step(RequestCycle.java:1077) at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1173) at org.apache.wicket.RequestCycle.request(RequestCycle.java:483) at org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:277) at org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:129) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:264) at org.acegisecurity.intercept.web.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:107) at org.acegisecurity.intercept.web.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:72) at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274) at org.acegisecurity.ui.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:110) at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274) at org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:217) at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274) at org.acegisecurity.ui.logout.LogoutFilter.doFilter(LogoutFilter.java:106) at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274) at org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:229) at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274) at org.acegisecurity.util.FilterChainProxy.doFilter(FilterChainProxy.java:148) at org.acegisecurity.util.FilterToBeanProxy.doFilter(FilterToBeanProxy.java:98) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
Re: wicket tester / tester.assertResultPage(clazz, filename);
Fidling around with the spaces, I've now boiled it down to this error only: ERROR - DiffUtil - === It's not that descriptive though:( Cant really see whats wrong.. regards Nino Nino Saturnino Martinez Vazquez Wael wrote: I should also mentioned that Im testing by doing this: WicketTester.assertResultPage(this.getClass(), filename); Nino Saturnino Martinez Vazquez Wael wrote: Hi Im trying to create a test that renders a page and then compares it to the expected result. Currently I keep getting diff errors although I just copied the contents of the html file from the tester.dumpPage() and placed it in the expected result file. I guess its just a matter of spaces thats wrong, but not matter how I change them they dont seem to add up apparently. As it can be somewhat a task guessing how the contents of a wicket page might look, I thought this was the most simple approach to doing this but I might be wrong? regards Nino - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: wicket tester / tester.assertResultPage(clazz, filename);
looking at the sourcefile I saw this option: -Dwicket.replace.expected.results=true could this be what I was looking for to genereate the expected results? I think so:) regards Nino Nino Saturnino Martinez Vazquez Wael wrote: Fidling around with the spaces, I've now boiled it down to this error only: ERROR - DiffUtil - === It's not that descriptive though:( Cant really see whats wrong.. regards Nino Nino Saturnino Martinez Vazquez Wael wrote: I should also mentioned that Im testing by doing this: WicketTester.assertResultPage(this.getClass(), filename); Nino Saturnino Martinez Vazquez Wael wrote: Hi Im trying to create a test that renders a page and then compares it to the expected result. Currently I keep getting diff errors although I just copied the contents of the html file from the tester.dumpPage() and placed it in the expected result file. I guess its just a matter of spaces thats wrong, but not matter how I change them they dont seem to add up apparently. As it can be somewhat a task guessing how the contents of a wicket page might look, I thought this was the most simple approach to doing this but I might be wrong? regards Nino - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Strange bug in Wicket-1.3.0-beta2
I will do that as soon as I can (hope tomorrow. Anyway, the quickstart is easy to create). Till then, a short description: I use a RefreshingView table with actions (some business entity). Each row has attached an AjaxEventBehavior to onclick event. When a row is clicked, another component (action summary) is refreshed. When using the SNAPSHOT version, I've got the exception when clicking any row. PS: I do not know if it is a precondition bug, maybe the wicket-ajax.js have some other malicious changes. Matej Knopp-2 wrote: Unfortunately just a jira issue will not od that. Can't you try to isolate the problem? -Matej On 9/6/07, Alex Objelean [EMAIL PROTECTED] wrote: It's quite hard to create a quickstart project, since the project I'm working on is very large. But if you think that it is enough to create a JIRA task with the stacktrace and short description, than I'll do it. Alex Matej Knopp-2 wrote: that's weird. could be a bug in precodition check. Can you please create a jira entry and add a quickstart project? This might be a corner case, I'd like to fix this asap. -Matej On 9/6/07, Alex Objelean [EMAIL PROTECTED] wrote: With the latest SNAPSHOT, the application throws Exception almost always :(... I thing, it has not been tested too much. Here is the stacktrace: .apache.wicket.WicketRuntimeException: component body:panel:actionListContainer:actionList:form:actionList:65 not found on page ro.isdc.centerparcs.dpa.ui.page.DPADashboardPage[id = 0], listener interface = [RequestListenerInterface name=IBehaviorListener, method=public abstract void org.apache.wicket.behavior.IBehaviorListener.onRequest()] at org.apache.wicket.request.AbstractRequestCycleProcessor.resolveListenerInterfaceTarget(AbstractRequestCycleProcessor.java:393) at org.apache.wicket.request.AbstractRequestCycleProcessor.resolveRenderedPage(AbstractRequestCycleProcessor.java:439) at org.apache.wicket.protocol.http.WebRequestCycleProcessor.resolve(WebRequestCycleProcessor.java:139) at org.apache.wicket.RequestCycle.step(RequestCycle.java:1077) at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1173) at org.apache.wicket.RequestCycle.request(RequestCycle.java:483) at org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:277) at org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:129) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:264) at org.acegisecurity.intercept.web.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:107) at org.acegisecurity.intercept.web.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:72) at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274) at org.acegisecurity.ui.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:110) at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274) at org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:217) at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274) at org.acegisecurity.ui.logout.LogoutFilter.doFilter(LogoutFilter.java:106) at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274) at org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:229) at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274) at org.acegisecurity.util.FilterChainProxy.doFilter(FilterChainProxy.java:148) at org.acegisecurity.util.FilterToBeanProxy.doFilter(FilterToBeanProxy.java:98) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) at
DIV TAG HEADER DO NOT WORK IN WICKET
THE HEADER IS NOT WORKING DIV id=header UL LIA href=# wicket:id=homeLinkHome/A/LI LI id=current wicket:id=trendArchiveA href=#Trend Archive/A/LI LIA href=# wicket:id=latestLookLink The Latest Looks/A/LI LI class=advanced wicket:id=pepsiStyleLinkA href=#Pepsi Style/A /LI LIA href=# wicket:id=myClosetLinkMy Closet/A /LI LIA href=# wicket:id=submitStyleLinkSubmit Style /A/LI /UL /DIV/td
Re: DIV TAG HEADER DO NOT WORK IN WICKET
hmm should'nt it be in or '' like this: div id=header? regards Nino bhupat parmar wrote: THE HEADER IS NOT WORKING DIV id=header UL LIA href=# wicket:id=homeLinkHome/A/LI LI id=current wicket:id=trendArchiveA href=#Trend Archive/A/LI LIA href=# wicket:id=latestLookLink The Latest Looks/A/LI LI class=advanced wicket:id=pepsiStyleLinkA href=#Pepsi Style/A /LI LIA href=# wicket:id=myClosetLinkMy Closet/A /LI LIA href=# wicket:id=submitStyleLinkSubmit Style /A/LI /UL /DIV/td - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Strange bug in Wicket-1.3.0-beta2
It's only a false alarm. Sorry. My fault. Probably I didn't perform a 'clean' before the application has been deployed. The issue is CLOSED! PS: Big 'THANK YOU' to Matej :). Alex Objelean wrote: Last post was completely wrong. Here is another handler which works ok: var wcall=wicketAjaxGet('?wicket:interface=:0:body:panel:actionDetailsContainer:actionDetails:panel:actionSummaryButtons:editOr', function() { }.bind(this), function() { }.bind(this), function() {return Wicket.$$(this)}.bind(this));return !wcall; Alex Objelean wrote: Yep, any row. What have I noticed also is that other ajax interaction works ok. The only difference is that one using wicketAjaxGet method, and another wicketAjaxPost (this one is ok). Maybe the bug is somewhere in this funtion: wicketAjaxGet? Alex Matej Knopp-2 wrote: When clicking _any_ row? Now that really is interesting. I hope you'll able to provide the quickstart soon. -Matej On 9/6/07, Alex Objelean [EMAIL PROTECTED] wrote: I will do that as soon as I can (hope tomorrow. Anyway, the quickstart is easy to create). Till then, a short description: I use a RefreshingView table with actions (some business entity). Each row has attached an AjaxEventBehavior to onclick event. When a row is clicked, another component (action summary) is refreshed. When using the SNAPSHOT version, I've got the exception when clicking any row. PS: I do not know if it is a precondition bug, maybe the wicket-ajax.js have some other malicious changes. Matej Knopp-2 wrote: Unfortunately just a jira issue will not od that. Can't you try to isolate the problem? -Matej On 9/6/07, Alex Objelean [EMAIL PROTECTED] wrote: It's quite hard to create a quickstart project, since the project I'm working on is very large. But if you think that it is enough to create a JIRA task with the stacktrace and short description, than I'll do it. Alex Matej Knopp-2 wrote: that's weird. could be a bug in precodition check. Can you please create a jira entry and add a quickstart project? This might be a corner case, I'd like to fix this asap. -Matej On 9/6/07, Alex Objelean [EMAIL PROTECTED] wrote: With the latest SNAPSHOT, the application throws Exception almost always :(... I thing, it has not been tested too much. Here is the stacktrace: .apache.wicket.WicketRuntimeException: component body:panel:actionListContainer:actionList:form:actionList:65 not found on page ro.isdc.centerparcs.dpa.ui.page.DPADashboardPage[id = 0], listener interface = [RequestListenerInterface name=IBehaviorListener, method=public abstract void org.apache.wicket.behavior.IBehaviorListener.onRequest()] at org.apache.wicket.request.AbstractRequestCycleProcessor.resolveListenerInterfaceTarget(AbstractRequestCycleProcessor.java:393) at org.apache.wicket.request.AbstractRequestCycleProcessor.resolveRenderedPage(AbstractRequestCycleProcessor.java:439) at org.apache.wicket.protocol.http.WebRequestCycleProcessor.resolve(WebRequestCycleProcessor.java:139) at org.apache.wicket.RequestCycle.step(RequestCycle.java:1077) at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1173) at org.apache.wicket.RequestCycle.request(RequestCycle.java:483) at org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:277) at org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:129) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:264) at org.acegisecurity.intercept.web.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:107) at org.acegisecurity.intercept.web.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:72) at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274) at org.acegisecurity.ui.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:110) at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274) at org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:217) at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274) at org.acegisecurity.ui.logout.LogoutFilter.doFilter(LogoutFilter.java:106) at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274) at
Re: Strange bug in Wicket-1.3.0-beta2
You're welcome :) On 9/6/07, Alex Objelean [EMAIL PROTECTED] wrote: It's only a false alarm. Sorry. My fault. Probably I didn't perform a 'clean' before the application has been deployed. The issue is CLOSED! PS: Big 'THANK YOU' to Matej :). Alex Objelean wrote: Last post was completely wrong. Here is another handler which works ok: var wcall=wicketAjaxGet('?wicket:interface=:0:body:panel:actionDetailsContainer:actionDetails:panel:actionSummaryButtons:editOr', function() { }.bind(this), function() { }.bind(this), function() {return Wicket.$$(this)}.bind(this));return !wcall; Alex Objelean wrote: Yep, any row. What have I noticed also is that other ajax interaction works ok. The only difference is that one using wicketAjaxGet method, and another wicketAjaxPost (this one is ok). Maybe the bug is somewhere in this funtion: wicketAjaxGet? Alex Matej Knopp-2 wrote: When clicking _any_ row? Now that really is interesting. I hope you'll able to provide the quickstart soon. -Matej On 9/6/07, Alex Objelean [EMAIL PROTECTED] wrote: I will do that as soon as I can (hope tomorrow. Anyway, the quickstart is easy to create). Till then, a short description: I use a RefreshingView table with actions (some business entity). Each row has attached an AjaxEventBehavior to onclick event. When a row is clicked, another component (action summary) is refreshed. When using the SNAPSHOT version, I've got the exception when clicking any row. PS: I do not know if it is a precondition bug, maybe the wicket-ajax.js have some other malicious changes. Matej Knopp-2 wrote: Unfortunately just a jira issue will not od that. Can't you try to isolate the problem? -Matej On 9/6/07, Alex Objelean [EMAIL PROTECTED] wrote: It's quite hard to create a quickstart project, since the project I'm working on is very large. But if you think that it is enough to create a JIRA task with the stacktrace and short description, than I'll do it. Alex Matej Knopp-2 wrote: that's weird. could be a bug in precodition check. Can you please create a jira entry and add a quickstart project? This might be a corner case, I'd like to fix this asap. -Matej On 9/6/07, Alex Objelean [EMAIL PROTECTED] wrote: With the latest SNAPSHOT, the application throws Exception almost always :(... I thing, it has not been tested too much. Here is the stacktrace: .apache.wicket.WicketRuntimeException: component body:panel:actionListContainer:actionList:form:actionList:65 not found on page ro.isdc.centerparcs.dpa.ui.page.DPADashboardPage[id = 0], listener interface = [RequestListenerInterface name=IBehaviorListener, method=public abstract void org.apache.wicket.behavior.IBehaviorListener.onRequest()] at org.apache.wicket.request.AbstractRequestCycleProcessor.resolveListenerInterfaceTarget(AbstractRequestCycleProcessor.java:393) at org.apache.wicket.request.AbstractRequestCycleProcessor.resolveRenderedPage(AbstractRequestCycleProcessor.java:439) at org.apache.wicket.protocol.http.WebRequestCycleProcessor.resolve(WebRequestCycleProcessor.java:139) at org.apache.wicket.RequestCycle.step(RequestCycle.java:1077) at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1173) at org.apache.wicket.RequestCycle.request(RequestCycle.java:483) at org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:277) at org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:129) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:264) at org.acegisecurity.intercept.web.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:107) at org.acegisecurity.intercept.web.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:72) at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274) at org.acegisecurity.ui.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:110) at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274) at org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:217) at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274) at
Re: Why the AbstractRepeater#onBeforeRender is final wicket-1.3.0-SNAPSHOT (6 sept 2007)?
the reason for it being final is that the super.onbeforerender() call HAS to be done last, otherwise new items do not get onbeforerender called on them. so if we remove final will you remember to always call it last? i think the chances are that are pretty small, thus its final. -igor On 9/6/07, Alex Objelean [EMAIL PROTECTED] wrote: I've grabbed the latest SNAPSHOT from the repository and have noticed that AbstractRepeater#onBeforeRender is final. I wonder what is the reason for this? (I need to do something in it's subclass) /** * @see org.apache.wicket.Component#onBeforeRender() */ protected final void onBeforeRender() { if (isVisibleInHierarchy()) { onPopulate(); } super.onBeforeRender(); } Alex -- View this message in context: http://www.nabble.com/Why-the-AbstractRepeater-onBeforeRender-is-final-wicket-1.3.0-SNAPSHOT-%286-sept-2007%29--tf4391492.html#a12520558 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to set wicket's locale?
sushi -igor On 9/6/07, Martijn Dashorst [EMAIL PROTECTED] wrote: new PropertyModel(Page.this, session.foo.sushi.bar); ? On 9/6/07, Gabor Szokoli [EMAIL PROTECTED] wrote: On 9/5/07, Johan Compagner [EMAIL PROTECTED] wrote: can you make an jira issue for this? https://issues.apache.org/jira/browse/WICKET-936 Any ideas on encapsulating the session as a propertymodel for components in 1.2? Gabor - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Buy Wicket in Action: http://manning.com/dashorst Apache Wicket 1.3.0-beta3 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta3/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: YAML / Wicket integration
Yes, you are right. All integration is just about adding something :-) . The benefit of integration projects is that they care about the integration. You don't have to manually download and install all those resources. But of couse you don't have to use it. Just add the CSS resources manually. :-) Johannes Schneider Alex Objelean wrote: I like the idea of the YAML or YUI grids. It's aim is to simplify CSS development. But I do not see any reason to create this kind of projects (wicket-yaml, wicket-yui-grids, etc) which integrates css frameworks. All integration is about, is just to add some CSS resources to you web page and that's it. Johannes Schneider-3 wrote: Hi, I have created a small project that integrates the great CSS framework YAML (http://www.yaml.de/en/home.html) into Wicket. As I am new to Wicket I really appreciate every feedback I could get. Project home page: http://cedarsoft.org/wicket/yaml-integration/index.html Download link: http://build.cedarsoft.de:8111/guestAuth/repository/download/bt14/.lastSuccessful/yaml-integration/target/yaml-integration-all.jar Regards, Johannes Schneider -- Johannes Schneider Im Lindenwasen 15 72810 Gomaringen Fon +49 7072 9229972 Fax +49 7072 50 Mobil +49 178 1364488 [EMAIL PROTECTED] http://www.johannes-schneider.info smime.p7s Description: S/MIME Cryptographic Signature
Re: YAML / Wicket integration
The source code is available: https://svn.cedarsoft.eu/open/eu.cedarsoft.wicket/trunk/yaml-integration/ Jan Mikkelsen wrote: Hi Johannes I think YAML looks extremely interesting. I did not know about it. But commenting on your framework is difficult without sourcecode. Best regards, Jan Mikkelsen Johannes Schneider wrote: Hi, I have created a small project that integrates the great CSS framework YAML (http://www.yaml.de/en/home.html) into Wicket. As I am new to Wicket I really appreciate every feedback I could get. Project home page: http://cedarsoft.org/wicket/yaml-integration/index.html Download link: http://build.cedarsoft.de:8111/guestAuth/repository/download/bt14/.lastSuccessful/yaml-integration/target/yaml-integration-all.jar Regards, Johannes Schneider - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Johannes Schneider Im Lindenwasen 15 72810 Gomaringen Fon +49 7072 9229972 Fax +49 7072 50 Mobil +49 178 1364488 [EMAIL PROTECTED] http://www.johannes-schneider.info smime.p7s Description: S/MIME Cryptographic Signature
And The Fastest Growing Web Framework Is...
This might be of interest to the Wicket community: http://www.javalobby.org/java/forums/t101110.html -- View this message in context: http://www.nabble.com/And-The-Fastest-Growing-Web-Framework-Is...-tf4392768.html#a12524620 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: applicationwide datePattern
try using session.setLocale() thats how i do it. Regards Dipu On 9/6/07, Korbinian Bachl [EMAIL PROTECTED] wrote: Hi, can anyone tell me how to change the default date pattern wicket should use in the whole app? I mean i can do: add(new DatePicker() { protected String getDatePattern() { return dd.MM.; } on each component manually, but that doesnt seem to be the right way. Regards, Korbinian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why the AbstractRepeater#onBeforeRender is final wicket-1.3.0-SNAPSHOT (6 sept 2007)?
a javadoc warning wont stop emails coming to this list :) onbeforerendercalled() is also an ugly way, uglier then onpopulate() which is at least more semantically named. the root problem is that java does not contain a compiler directive that would check for this, there is some support for this in JSR305, but who knows when that will come to fruition. until then the only sure way to do this is to make the method final :| -igor On 9/6/07, Alex Objelean [EMAIL PROTECTED] wrote: The way I do it, is this: protected void onBeforeRender() { //my init code super.onBeforeRender(); } I think it can be documented in the javadoc, that it is mandatory to call super at the end. User can also have a problem if just override the onBeforeRender without calling the super. I think, there is a lack of another life-cycle method which would not force user to call super. Something like the below: protected void onBeforeRender() { onBeforeRenderCalled() super.onBeforeRender(); } where onBeforeRenderCalled() is an empty method which would allow user to add his init logic. Alex. igor.vaynberg wrote: the reason for it being final is that the super.onbeforerender() call HAS to be done last, otherwise new items do not get onbeforerender called on them. so if we remove final will you remember to always call it last? i think the chances are that are pretty small, thus its final. -igor On 9/6/07, Alex Objelean [EMAIL PROTECTED] wrote: I've grabbed the latest SNAPSHOT from the repository and have noticed that AbstractRepeater#onBeforeRender is final. I wonder what is the reason for this? (I need to do something in it's subclass) /** * @see org.apache.wicket.Component#onBeforeRender() */ protected final void onBeforeRender() { if (isVisibleInHierarchy()) { onPopulate(); } super.onBeforeRender(); } Alex -- View this message in context: http://www.nabble.com/Why-the-AbstractRepeater-onBeforeRender-is-final-wicket-1.3.0-SNAPSHOT-%286-sept-2007%29--tf4391492.html#a12520558 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Why-the-AbstractRepeater-onBeforeRender-is-final-wicket-1.3.0-SNAPSHOT-%286-sept-2007%29--tf4391492.html#a12524545 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why the AbstractRepeater#onBeforeRender is final wicket-1.3.0-SNAPSHOT (6 sept 2007)?
I take the discussion is about removing onPopulate now? why not keep onPopulate and remove the final? On 9/6/07, Igor Vaynberg [EMAIL PROTECTED] wrote: the reason for it being final is that the super.onbeforerender() call HAS to be done last, otherwise new items do not get onbeforerender called on them. so if we remove final will you remember to always call it last? i think the chances are that are pretty small, thus its final. -igor On 9/6/07, Alex Objelean [EMAIL PROTECTED] wrote: I've grabbed the latest SNAPSHOT from the repository and have noticed that AbstractRepeater#onBeforeRender is final. I wonder what is the reason for this? (I need to do something in it's subclass) /** * @see org.apache.wicket.Component#onBeforeRender() */ protected final void onBeforeRender() { if (isVisibleInHierarchy()) { onPopulate(); } super.onBeforeRender(); } Alex -- View this message in context: http://www.nabble.com/Why-the-AbstractRepeater-onBeforeRender-is-final-wicket-1.3.0-SNAPSHOT-%286-sept-2007%29--tf4391492.html#a12520558 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DIV TAG HEADER DO NOT WORK IN WICKET
TSEE IS THAT AS LOUD AS YOU CAN GET? On 9/6/07, Igor Vaynberg [EMAIL PROTECTED] wrote: WHAT IS WRONG WITH IT? -IGOR On 9/6/07, bhupat parmar [EMAIL PROTECTED] wrote: THE HEADER IS NOT WORKING DIV id=header UL LIA href=# wicket:id=homeLinkHome/A/LI LI id=current wicket:id=trendArchiveA href=#Trend Archive/A/LI LIA href=# wicket:id=latestLookLink The Latest Looks/A/LI LI class=advanced wicket:id=pepsiStyleLinkA href=#Pepsi Style/A /LI LIA href=# wicket:id=myClosetLinkMy Closet/A /LI LIA href=# wicket:id=submitStyleLinkSubmit Style /A/LI /UL /DIV/td
Re: And The Fastest Growing Web Framework Is...
On 9/6/07, cowwoc [EMAIL PROTECTED] wrote: This might be of interest to the Wicket community: If you really think about this.. It just means that it takes more developers (jobs) in order to accomplish the same thing it takes with just a handful of wicket developers :P So I guess if you're in the perspective of out-of-work-can't-find-a-job-what-should-I-learn-because-wicket-was-too-hard then I guess it's interesting.. *cough* not.. ** All meant in good (attempted) humour.. please ignore :) ** ./C - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: And The Fastest Growing Web Framework Is...
http://www.indeed.com/jobtrends?q=java%2C+jsfl= java is all you need to know for wicket so jsf seems pretty low to me in that picture.. On 9/6/07, cowwoc [EMAIL PROTECTED] wrote: This might be of interest to the Wicket community: http://www.javalobby.org/java/forums/t101110.html -- View this message in context: http://www.nabble.com/And-The-Fastest-Growing-Web-Framework-Is...-tf4392768.html#a12524620 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DIV TAG HEADER DO NOT WORK IN WICKET
UR RIGHT. THE DIFFERENCE BETWEEN XHTML AND HTML IS THAT ATTRIBUTES MUST BE QUOTED: http://www.w3.org/TR/xhtml1/#diffs Nino Saturnino Martinez Vazquez Wael wrote: hmm should'nt it be in or '' like this: div id=header? regards Nino bhupat parmar wrote: THE HEADER IS NOT WORKING DIV id=header -- View this message in context: http://www.nabble.com/DIV-TAG-HEADER-DO-NOT-WORK-IN-WICKET-tf4392231.html#a12525267 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket libraries
Robo wrote: Ok, seems removing \wicket-velocity-1.3.0-beta3.jar\ from build path solved problem with velocity problem. But please explain me why removing package from build path solves the problem if nowhere in my Hello World code i call for any of the velocity packages. Is there some duplicities in packages or what? I expect because Wicket looks on the classpath for Wicket modules to initialise, finds some in that JAR, tries to and then can't find one of its dependencies. Modern Java apps tend to be complex beasts, with lots of dependencies. If you insist on managing these manually, you can expect to have a fair bit of work to do. That's why things like Ivy and Maven 2 were invented. As to Maven2. It seems that like you in some way force developers to Maven2. :-) No, not at all. But if you've deliberately chosen to manage your dependencies manually when there are perfectly good ways of doing it automatically, then we're not going to hold your hand for you. We don't get paid to do this, you know. If you don't like Maven 2 no one is forcing you to use it. Use Ivy instead. Or use the standalone Maven 2 Ant tasks for doing dependencies. Alternatively, install Maven 2, use it to build a quickstart WAR file with all the things you need, and then grab the JARs from there. Any of these options would take you a tenth of the time you've spent bitching on this mailing list. Yes Maven solves you some problems with dependecies and also si suitable for small project but at big projects it definitely fails. :-/ So Geronimo is a small project? And Jetty? And Apache Directory Server? And Wicket for that matter? And the several-hundreds-of-thousands-of- lines, 200+ dependencies projects we have here that use it? Jeez - I may have a high horse, but yours is scraping the stratosphere. Sure, it has some issues, but so does anything complex. The simple point is that for most people, Ivy or Maven 2 do what they want it to do. If you don't like any of these automated tools and insist on doing it all manually, you can't expect us to have all that much time for you, as we don't get paid to do this, you know. It's like you're complaining that there's no documentation on how to hammer in a nail using a screwdriver. So please. I know you have lot of work with wicket, and as users can see you have a good aproach. But please do spend some time to at least write one chapter about libraries, neede dependencies and so on. If you have licensing problems just make one clear site with core libs link, dep libs link and explanation what feature they are enabling and so on. And make some quick start page in which you explainn dependecies on simple sample app :-)Do not take alibistic aproach of hiding everithing besides Maven. :-) Why don't you write a wiki page for us? Despite the fact I'm not being paid to be your tech support, I've taken some time out to give you a text file exhaustively detailing the required dependencies for each of our modules, including the transitive ones. I have done the work for you (not that you've even murmured a thank you), so why are you still bitching about it? Al -- Alastair Maw Wicket-biased blog at http://herebebeasties.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Twice Behavior on the same event handler (wicket 1.2.x)
Would it make sense to have a behavior that was implemented as a Chain of Responsibility http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern Then it would just be a matter of adding that behavior to your component. On 9/6/07, Alex Objelean [EMAIL PROTECTED] wrote: I am curious, what is your use case for chaining behaviors? I think that if you have two things that you want to chain, then chain them in the same handler, or use decorator to add the client-side code. Alex paolo di tommaso wrote: Carlos, Can you provide an example of your custom implementation of chained behaviour? Thanks, Paolo On 9/6/07, Carlos Pita [EMAIL PROTECTED] wrote: Currently people will have to build it in themselves like you did. We can investigate whether this can be improved for future versions, but From my own experience I wouldn't say that wicket should support this. It's too easy to write it yourself just to fit your specific needs, and otoh seems difficult to predict and support a significant number of possible use cases in a general way that keeps everyone happy, as you remarked. Regards, Carlos Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Twice-Behavior-on-the-same-event-handler-%28wicket-1.2.x%29-tf4386351.html#a12518265 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Scott Swank reformed mathematician - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: And The Fastest Growing Web Framework Is...
Well, such charts do not make me fear to placed the bet on the wrong horse. I've taken a look at a large number of frameworks and found Wicket to be the best one for our purposes. This cannot be changed by such charts, but only by JSF being better than Wicket. In Germany, the best sold car is the VW Golf. But does this mean I should buy one? No, there are a lot of better alternatives (in the meaning of quality and design, for example). Cheers, Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: And The Fastest Growing Web Framework Is...
In Germany, the best sold car is the VW Golf. But does this mean I should buy one? No, there are a lot of better alternatives (in the meaning of quality and design, for example). really? i thought it was German Build Quality! The best there is! Are there even better? (don't mention now ofcourse other german brands ;) )
Re: Re: Wicket libraries stack trace
On 06 Sep 2007 11:44:56 +0200 (CEST), Robo [EMAIL PROTECTED] wrote: Ok Thnaks for explanation. And do not look for truth in jokes. Jokes are just jokes ;-) But you are not using Velocity panel right? Why do you include that jar in the first place? You can just include the core wicket jar. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: Re: Wicket libraries stack trace
And why not? Besides that Wicket is doing some initialization of not used libraries is there any restriction of not including not neccesary libraries in classpath? Most time I develop someting I have many libraries in my classpath even if I do not use them ... Robo - Originálna Správa - Od: \Eelco Hillenius\ Komu: Poslaná: 06.09.2007 18:09 Predmet: Re: Re: Wicket libraries stack trace On 06 Sep 2007 11:44:56 +0200 (CEST), Robo wrote: Ok Thnaks for explanation. And do not look for truth in jokes. Jokes are just jokes ;-) But you are not using Velocity panel right? Why do you include that jar in the first place? You can just include the core wicket jar. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Mozaika storočia denníka SME - http://mozaika.sme.sk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: And The Fastest Growing Web Framework Is...
really? i thought it was German Build Quality! The best there is! Are there even better? (don't mention now ofcourse other german brands ;) ) Trabant is German :) Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: Re: Wicket libraries stack trace
On 06 Sep 2007 17:23:13 +0200 (CEST), Robo [EMAIL PROTECTED] wrote: And why not? Besides that Wicket is doing some initialization of not used libraries is there any restriction of not including not neccesary libraries in classpath? Most time I develop someting I have many libraries in my classpath even if I do not use them ... Because you seem to be running into trouble with your dependencies. If you include wicket-velocity, you need Velocity (which you could have guessed from the name of the project) and any dependencies Velocity has. If don't include wicket-velocity, you don't need Velocity. It's that simple. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to set wicket's locale?
T-37 minutes until sushi time! On 9/6/07, Igor Vaynberg [EMAIL PROTECTED] wrote: sushi -igor On 9/6/07, Martijn Dashorst [EMAIL PROTECTED] wrote: new PropertyModel(Page.this, session.foo.sushi.bar); ? On 9/6/07, Gabor Szokoli [EMAIL PROTECTED] wrote: On 9/5/07, Johan Compagner [EMAIL PROTECTED] wrote: can you make an jira issue for this? https://issues.apache.org/jira/browse/WICKET-936 Any ideas on encapsulating the session as a propertymodel for components in 1.2? Gabor - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Buy Wicket in Action: http://manning.com/dashorst Apache Wicket 1.3.0-beta3 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta3/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket problem with slf4j 1.4
Tauren Mills tauren at tauren.com writes: Thanks everyone for the help. I got it working with the following jars: log4j-1.2.15.jar slf4j-api-1.4.2.jar slf4j-log4j12-1.4.2.jar Is that what others are using? I had troubles while using logback, but I may not have used the right jars or got the configuration right. It seemed that Jetty was having troubles and throwing exceptions. What is the right combination of jars to use with logback? Tauren That looks correct for the SLF4J/log4j combo. For the SLF4J/logback combo, you would need slf4j-api-1.4.3.jar (1.4.2 is OK too) logback-core-0.9.8.jar logback-classic-0.9.8.jar I hope this helps, - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: Wicket libraries
Java jars are nto at all complex beast. They become tricky in situation where you just put some of them inclasspath and they do what you normally do not expect. Lib should be lib and when not called by developer they should do nothing. Deliberatly breaking this rule makes the jars, beast ... :-) Sorry, but that is b.s. Could you point me where this 'rule' is defined? You bet you can have troubles if you just mindlessly include all kinds of jars. Furthermore, what is your whole point of having to include jars you are not using? If you would be using them, you'd need those other dependencies, period. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: Re: Re: Wicket libraries stack trace
After small troubles I had with it I know it. But from my point of view it is not correct to initiatie not used libraries just by including it in App Server classpath. From my point of view lib is lib, and when nto called by developer it sould not be initiated by App server. I runned into troubles with dependecies SELF initialized itself. I saw this behaviur several times before but everytime I`m suprised. As I said from my point of view, lib is lib. But this guides me to troubles :-) But to be concrete I need to develop demo app using fove frameworks, not using Maven :-), so I put every lib in wicket into lib dir to not to solve missing lib troubles when building demo app. But it raised contrary, unnessesary \self living\ lib problem. So Eelco we could probably close this thread as my troubles with Hello World are solved, now begins the trouble with demo app. So thanks for help and good product. Demo app will be presented week after next week so we`ll see hov wicket compares to other frameworks. Robo - Originálna Správa - Od: \Eelco Hillenius\ Komu: Poslaná: 06.09.2007 18:17 Predmet: Re: Re: Re: Wicket libraries stack trace On 06 Sep 2007 17:23:13 +0200 (CEST), Robo wrote: And why not? Besides that Wicket is doing some initialization of not used libraries is there any restriction of not including not neccesary libraries in classpath? Most time I develop someting I have many libraries in my classpath even if I do not use them ... Because you seem to be running into trouble with your dependencies. If you include wicket-velocity, you need Velocity (which you could have guessed from the name of the project) and any dependencies Velocity has. If don\'t include wicket-velocity, you don\'t need Velocity. It\'s that simple. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Sprievodca herným svetom - http://hry.sme.sk/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: Re: Re: Wicket libraries stack trace
On 06 Sep 2007 18:11:09 +0200 (CEST), Robo [EMAIL PROTECTED] wrote: After small troubles I had with it I know it. But from my point of view it is not correct to initiatie not used libraries just by including it in App Server classpath. From my point of view lib is lib, and when nto called by developer it sould not be initiated by App server. I runned into troubles with dependecies SELF initialized itself. I saw this behaviur several times before but everytime I`m suprised. As I said from my point of view, lib is lib. But this guides me to troubles :-) But to be concrete I need to develop demo app using fove frameworks, not using Maven :-), so I put every lib in wicket into lib dir to not to solve missing lib troubles when building demo app. But it raised contrary, unnessesary \self living\ lib problem. You can't really depend on libs following such rules. All sorts of frameworks do this, from Guice to Seam to logging libraries, and it can get you in trouble with XML handling as well. As a general rule, only include what you need. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Twice Behavior on the same event handler (wicket 1.2.x)
Alex: We implemented a subclass of Form that has some sophisticated validation and customized feedback panels built-in. This form automatically instruments its fields with an ajax validating behavior. But sometimes -not that often- a field needs to ajax-do a bit more than just being validated, so this extra behavior is passed as a handler that knows how to react onSubmit and onError. Well, to the point: at first we implemented this extra behavior as sort of chained behavior, but then, as we found out that this generality was adding extra complexity and didn't really pay off, we moved out to a simpler schema with a handler implementing an onSubmit/onError barebones interface, to which the only behavior delegates at last. So now there is only one behavior and nothing that resembles a chain. In part, that's the reason why I feel that such a functionality is out of the scope of a general framework/toolkit as wicket is. Regards, Carlos On 9/6/07, Alex Objelean [EMAIL PROTECTED] wrote: I am curious, what is your use case for chaining behaviors? I think that if you have two things that you want to chain, then chain them in the same handler, or use decorator to add the client-side code. Alex paolo di tommaso wrote: Carlos, Can you provide an example of your custom implementation of chained behaviour? Thanks, Paolo On 9/6/07, Carlos Pita [EMAIL PROTECTED] wrote: Currently people will have to build it in themselves like you did. We can investigate whether this can be improved for future versions, but From my own experience I wouldn't say that wicket should support this. It's too easy to write it yourself just to fit your specific needs, and otoh seems difficult to predict and support a significant number of possible use cases in a general way that keeps everyone happy, as you remarked. Regards, Carlos Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Twice-Behavior-on-the-same-event-handler-%28wicket-1.2.x%29-tf4386351.html#a12518265 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: Re: Wicket libraries
Sorry Eelco but me and also quite a lot of other developers(I know, contrary to others developers) consider same b.s. libraries which are \alive\ just because they are in classpath. It is like talking when nobody asks you ... Look at Java SDK do you need all packages to build console \Hello World!\ No. And who cares. They are just there and do their stuff when needed. So why wicket-velocity is doing job developer do not want and did not asked to. Where is writen that I cannot put mindesly tens of useles libs when they just sit there, assuming of course the packages are not duplicating. Do you understand why there are packages Eelco. Unles the class is uniqeu develioper should not be afreaid of using other class he wanted. To push your false premise to edge, why you deliberatly put all packages and classes into jar when you need just few of them also with dependencies. Isn`t it b.s.? Yes it is .. and also it is not conceptual ... Do not make zombie libraries and there will be no problem with dependecies. Got the point? If not I`m not alble not help you sorry ... Robo - Originálna Správa - Od: \Eelco Hillenius\ Komu: Poslaná: 06.09.2007 18:59 Predmet: Re: Re: Wicket libraries Java jars are nto at all complex beast. They become tricky in situation where you just put some of them inclasspath and they do what you normally do not expect. Lib should be lib and when not called by developer they should do nothing. Deliberatly breaking this rule makes the jars, beast ... :-) Sorry, but that is b.s. Could you point me where this \'rule\' is defined? You bet you can have troubles if you just mindlessly include all kinds of jars. Furthermore, what is your whole point of having to include jars you are not using? If you would be using them, you\'d need those other dependencies, period. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Najoriginalnejsie technologicke hracky - http://pocitace.sme.sk/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why the AbstractRepeater#onBeforeRender is final wicket-1.3.0-SNAPSHOT (6 sept 2007)?
because the final is there for a very important reason? -igor On 9/6/07, Johan Compagner [EMAIL PROTECTED] wrote: I take the discussion is about removing onPopulate now? why not keep onPopulate and remove the final? On 9/6/07, Igor Vaynberg [EMAIL PROTECTED] wrote: the reason for it being final is that the super.onbeforerender() call HAS to be done last, otherwise new items do not get onbeforerender called on them. so if we remove final will you remember to always call it last? i think the chances are that are pretty small, thus its final. -igor On 9/6/07, Alex Objelean [EMAIL PROTECTED] wrote: I've grabbed the latest SNAPSHOT from the repository and have noticed that AbstractRepeater#onBeforeRender is final. I wonder what is the reason for this? (I need to do something in it's subclass) /** * @see org.apache.wicket.Component#onBeforeRender() */ protected final void onBeforeRender() { if (isVisibleInHierarchy()) { onPopulate(); } super.onBeforeRender(); } Alex -- View this message in context: http://www.nabble.com/Why-the-AbstractRepeater-onBeforeRender-is-final-wicket-1.3.0-SNAPSHOT-%286-sept-2007%29--tf4391492.html#a12520558 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DIV TAG HEADER DO NOT WORK IN WICKET
I JUST LOVED HIS POST BECAUSE HE DOESNT SAY WHAT IS BROKEN. ID HATE TO SEE HIS BUG REPORTS. -IGOR On 9/6/07, cwilkes [EMAIL PROTECTED] wrote: UR RIGHT. THE DIFFERENCE BETWEEN XHTML AND HTML IS THAT ATTRIBUTES MUST BE QUOTED: http://www.w3.org/TR/xhtml1/#diffs Nino Saturnino Martinez Vazquez Wael wrote: hmm should'nt it be in or '' like this: div id=header? regards Nino bhupat parmar wrote: THE HEADER IS NOT WORKING DIV id=header -- View this message in context: http://www.nabble.com/DIV-TAG-HEADER-DO-NOT-WORK-IN-WICKET-tf4392231.html#a12525267 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to set wicket's locale?
you suck! -igor On 9/6/07, Evan Chooly [EMAIL PROTECTED] wrote: T-37 minutes until sushi time! On 9/6/07, Igor Vaynberg [EMAIL PROTECTED] wrote: sushi -igor On 9/6/07, Martijn Dashorst [EMAIL PROTECTED] wrote: new PropertyModel(Page.this, session.foo.sushi.bar); ? On 9/6/07, Gabor Szokoli [EMAIL PROTECTED] wrote: On 9/5/07, Johan Compagner [EMAIL PROTECTED] wrote: can you make an jira issue for this? https://issues.apache.org/jira/browse/WICKET-936 Any ideas on encapsulating the session as a propertymodel for components in 1.2? Gabor - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Buy Wicket in Action: http://manning.com/dashorst Apache Wicket 1.3.0-beta3 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta3/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: Re: Re: Re: Wicket libraries stack trace
Yes I know Eelco. That is why there are so much troubles in Java programming land. Misusing of basic concepts ... That is why one needs some sort of COC, because there is lot`s of b.s. around ... J2EE 1.4 countained so much of it that lots of developers refused to use it And it had to be rewriten ... Apache Struts ... JSF ... Why did you started Wicket? Did`nt you wrote that MVC is kind of missconceptin? And I ask you Who told that? Eelco Hilenius? Yes and you were probably right. And in that time you with the tapestry was alone against the JSF Struts community. So accpet pleace that someone else is seeing miisconceptions and b.s. in other aspetcs of java programming and habits. OK? :-) Can we finish? As you can see I do not share view of major java programmers but accepting the situation ... :-)) Robo - Originálna Správa - Od: \Eelco Hillenius\ Komu: Poslaná: 06.09.2007 19:08 Predmet: Re: Re: Re: Re: Wicket libraries stack trace On 06 Sep 2007 18:11:09 +0200 (CEST), Robo wrote: After small troubles I had with it I know it. But from my point of view it is not correct to initiatie not used libraries just by including it in App Server classpath. From my point of view lib is lib, and when nto called by developer it sould not be initiated by App server. I runned into troubles with dependecies SELF initialized itself. I saw this behaviur several times before but everytime I`m suprised. As I said from my point of view, lib is lib. But this guides me to troubles :-) But to be concrete I need to develop demo app using fove frameworks, not using Maven :-), so I put every lib in wicket into lib dir to not to solve missing lib troubles when building demo app. But it raised contrary, unnessesary \\\self living\\\ lib problem. You can\'t really depend on libs following such rules. All sorts of frameworks do this, from Guice to Seam to logging libraries, and it can get you in trouble with XML handling as well. As a general rule, only include what you need. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Mozaika storočia denníka SME - http://mozaika.sme.sk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why the AbstractRepeater#onBeforeRender is final wicket-1.3.0-SNAPSHOT (6 sept 2007)?
please tell me, tell me! johan On 9/6/07, Igor Vaynberg [EMAIL PROTECTED] wrote: because the final is there for a very important reason? -igor On 9/6/07, Johan Compagner [EMAIL PROTECTED] wrote: I take the discussion is about removing onPopulate now? why not keep onPopulate and remove the final? On 9/6/07, Igor Vaynberg [EMAIL PROTECTED] wrote: the reason for it being final is that the super.onbeforerender() call HAS to be done last, otherwise new items do not get onbeforerender called on them. so if we remove final will you remember to always call it last? i think the chances are that are pretty small, thus its final. -igor On 9/6/07, Alex Objelean [EMAIL PROTECTED] wrote: I've grabbed the latest SNAPSHOT from the repository and have noticed that AbstractRepeater#onBeforeRender is final. I wonder what is the reason for this? (I need to do something in it's subclass) /** * @see org.apache.wicket.Component#onBeforeRender() */ protected final void onBeforeRender() { if (isVisibleInHierarchy()) { onPopulate(); } super.onBeforeRender(); } Alex -- View this message in context: http://www.nabble.com/Why-the-AbstractRepeater-onBeforeRender-is-final-wicket-1.3.0-SNAPSHOT-%286-sept-2007%29--tf4391492.html#a12520558 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to set wicket's locale?
can you send some over? On 9/6/07, Evan Chooly [EMAIL PROTECTED] wrote: T-37 minutes until sushi time! On 9/6/07, Igor Vaynberg [EMAIL PROTECTED] wrote: sushi -igor On 9/6/07, Martijn Dashorst [EMAIL PROTECTED] wrote: new PropertyModel(Page.this, session.foo.sushi.bar); ? On 9/6/07, Gabor Szokoli [EMAIL PROTECTED] wrote: On 9/5/07, Johan Compagner [EMAIL PROTECTED] wrote: can you make an jira issue for this? https://issues.apache.org/jira/browse/WICKET-936 Any ideas on encapsulating the session as a propertymodel for components in 1.2? Gabor - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Buy Wicket in Action: http://manning.com/dashorst Apache Wicket 1.3.0-beta3 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta3/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Howto use AttributeModifier
Per, use a AbstractReadOnlyModel or a DetachableLoadableModel for the attribute value. Regards, Carlos On 9/6/07, Per Newgro [EMAIL PROTECTED] wrote: Ok. I tried the Attribute Modifier(String, String, boolean, Model) Constructor but it didn't worked. There have been exactly the same results. Thanks for your help Per Original-Nachricht Datum: Thu, 6 Sep 2007 15:34:14 +0200 Von: Gerolf Seitz [EMAIL PROTECTED] An: users@wicket.apache.org Betreff: Re: Howto use AttributeModifier you used the constructor AttributeModifer(String, String, Model), which only modifies the attribute if it's already there. if you use Attribute Modifier(String, String, boolean, Model), the attribute will be added to the tag in case it does not exist yet. gerolf -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kanns mit allen: http://www.gmx.net/de/go/multimessenger - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Howto use AttributeModifier
Or a PropertyModel. On 9/6/07, Carlos Pita [EMAIL PROTECTED] wrote: Per, use a AbstractReadOnlyModel or a DetachableLoadableModel for the attribute value. Regards, Carlos On 9/6/07, Per Newgro [EMAIL PROTECTED] wrote: Ok. I tried the Attribute Modifier(String, String, boolean, Model) Constructor but it didn't worked. There have been exactly the same results. Thanks for your help Per Original-Nachricht Datum: Thu, 6 Sep 2007 15:34:14 +0200 Von: Gerolf Seitz [EMAIL PROTECTED] An: users@wicket.apache.org Betreff: Re: Howto use AttributeModifier you used the constructor AttributeModifer(String, String, Model), which only modifies the attribute if it's already there. if you use Attribute Modifier(String, String, boolean, Model), the attribute will be added to the tag in case it does not exist yet. gerolf -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kanns mit allen: http://www.gmx.net/de/go/multimessenger - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Twice Behavior on the same event handler (wicket 1.2.x)
the problem with this stuff is that there is no single pattern that will work sometimes you want a chain where if a link fails the chain shortcircuits other times you dont want the shortcircuit sometimes you care about the order, other times you do not there are many variations of this and they are almost impossible to configure, so this isnt an easy problem. -igor On 9/6/07, Scott Swank [EMAIL PROTECTED] wrote: Would it make sense to have a behavior that was implemented as a Chain of Responsibility http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern Then it would just be a matter of adding that behavior to your component. On 9/6/07, Alex Objelean [EMAIL PROTECTED] wrote: I am curious, what is your use case for chaining behaviors? I think that if you have two things that you want to chain, then chain them in the same handler, or use decorator to add the client-side code. Alex paolo di tommaso wrote: Carlos, Can you provide an example of your custom implementation of chained behaviour? Thanks, Paolo On 9/6/07, Carlos Pita [EMAIL PROTECTED] wrote: Currently people will have to build it in themselves like you did. We can investigate whether this can be improved for future versions, but From my own experience I wouldn't say that wicket should support this. It's too easy to write it yourself just to fit your specific needs, and otoh seems difficult to predict and support a significant number of possible use cases in a general way that keeps everyone happy, as you remarked. Regards, Carlos Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Twice-Behavior-on-the-same-event-handler-%28wicket-1.2.x%29-tf4386351.html#a12518265 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Scott Swank reformed mathematician - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket libraries
You can use Ivy to resolve wicket dependencies and produce a report, if you have trouble to generate a report with maven ATM. The report details may be slightly different from what you get with m2, since Ivy is not 100% compatible with m2, but it's better than nothing. If you're interested, I can provide the build.xml to generate it (with automatic download of Ivy so that you only need ant 1.6+ on your box to test it). Would you be interested as a workaround until you get maven 2 site generation working? Xavier On 9/5/07, Martijn Dashorst [EMAIL PROTECTED] wrote: Skinning was not a problem, just generating a coherent site with just one command: cd wicket-1.x mvn site:deploy This just doesn't work (tm). Martijn On 9/5/07, Igor Vaynberg [EMAIL PROTECTED] wrote: we dont need links, just a list. and i thought the trouble was related to skinning? if thats still the case can we just put a vanilla maven site on wicket-stuff or somewhere? -igor On 9/5/07, Martijn Dashorst [EMAIL PROTECTED] wrote: Remember the troubles I had with generating the site? Tim was working on it, but it still is a long shot from being workable. And yes, it has a list of dependencies, but I don't think they generate a link to download each and every one of them :| Martijn On 9/5/07, Igor Vaynberg [EMAIL PROTECTED] wrote: why dont we generate the maven stie somewhere? doesnt that have a list of dependencies for each module? -igor On 9/5/07, Martijn Dashorst [EMAIL PROTECTED] wrote: On 9/5/07, Al Maw [EMAIL PROTECTED] wrote: That said, maybe we should provide a separate ZIP with the dependencies. I guess if you're using Ivy or Maven 2, you're not going to be downloading the ZIP at all. There may be licensing issues with this, though. What do people think? Martijn? Including the deps just doesn't increase the size to a double, but a 5 or 6 fold (iirc 65MB). The problem is with transitive deps that are test/compile/provided scope (for instance Spring includes just about the world). The best way currently is to do it as we do now IMO. The current direct deps are license compatible, but I really don't want to check all transitive deps for license compatibility. The current examples is already quite humongous in the dependency department. I have proposed a couple of weeks ago to move examples out of the main distribution, and make it a separate download, and do the same with the quickstart. The benefit would be that the license requirements for the main distribution download becomes smaller, only the stuff we include in the sources ourselves. Both the examples and quickstart would then include all necessary runtime deps for building a wicket application (as described in chapter 3 of wicket in action, and provided with wicket 1.2 until now). This makes them easier to provide a license file for. I just lack the time to make it so. In short: I don't like the idea of adding an all libs project and make it downloadable from Apache. We could make that a wicket stuff project though but the size would resemble downloading a whole maven repository. Martijn -- Buy Wicket in Action: http://manning.com/dashorst Apache Wicket 1.3.0-beta3 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta3/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Buy Wicket in Action: http://manning.com/dashorst Apache Wicket 1.3.0-beta3 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta3/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Buy Wicket in Action: http://manning.com/dashorst Apache Wicket 1.3.0-beta3 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta3/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Xavier Hanin - Independent Java Consultant http://xhab.blogspot.com/ http://incubator.apache.org/ivy/ http://www.xoocode.org/
Re: Re: Wicket libraries
On 06 Sep 2007 17:35:26 +0200 (CEST), Robo [EMAIL PROTECTED] wrote: Stop it now please Al. You take oo personal aproach. Nobody forced you in responding. heh, what you have to understand is that wicket is oss - so it IS personal. it is something we work on in our spare time so it is kind of a hobby (a demanding hobby). we do care about it a great deal. constructive criticism is always welcome, but you have to have a level of respect on the lists. You make Wicket And I`m the user. If you do not like it do not do it. But there is some responsibilities about product you develop towards product users so do not confuse roles please. wrong again. its the other way around. if you do not like it do not use it. we do not owe you anything. we put wicket out there for people to use, no strings attached. And besides that I`m also kind of customer As I paid for the book ;-) you paid for the book, but we get nothing from that. so how do you connect the dots? And besides that I several times said how Wicket is great is that not enaugh for you? :-)) thank you. And btw I thanked to Gvyn at the end of my troubles as his responcese solved them. I do not thank before my troubles gets solved ;-) I`m not teacher in the dance school. its not the missing thank you, it is more your superior attitute and your lecturing tone. so in fact you do come across as a teacher. What I`m doing now is preparing presentation to my chiefs and currrently I`m coping with five frameworks amking demo apps and have two weeks for it. That is Why I`m not writing wiki and that is why I`m sometimes upset about lack of docs, working 18-20 hours per day ... sounds like your chiefs are pretty dumb if they expect you to learn five frameworks in two weeks, find a better job. as for the issue at hand, i believe the velocity initializer should be rewritten to check if whatever it needs is actually on the classpath, and noop quietly if its not. please file a jira issue. -igor Java jars are nto at all complex beast. They become tricky in situation where you just put some of them inclasspath and they do what you normally do not expect. Lib should be lib and when not called by developer they should do nothing. Deliberatly breaking this rule makes the jars, beast ... :-) So Finishing this personal thread and thank you for much of your time ;-)) Robo - Originálna Správa - Od: Al Maw Komu: Poslaná: 06.09.2007 17:44 Predmet: Re: Wicket libraries Robo wrote: Ok, seems removing \\\wicket-velocity-1.3.0-beta3.jar\\\ from build path solved problem with velocity problem. But please explain me why removing package from build path solves the problem if nowhere in my Hello World code i call for any of the velocity packages. Is there some duplicities in packages or what? I expect because Wicket looks on the classpath for Wicket modules to initialise, finds some in that JAR, tries to and then can\'t find one of its dependencies. Modern Java apps tend to be complex beasts, with lots of dependencies. If you insist on managing these manually, you can expect to have a fair bit of work to do. That\'s why things like Ivy and Maven 2 were invented. As to Maven2. It seems that like you in some way force developers to Maven2. :-) No, not at all. But if you\'ve deliberately chosen to manage your dependencies manually when there are perfectly good ways of doing it automatically, then we\'re not going to hold your hand for you. We don\'t get paid to do this, you know. If you don\'t like Maven 2 no one is forcing you to use it. Use Ivy instead. Or use the standalone Maven 2 Ant tasks for doing dependencies. Alternatively, install Maven 2, use it to build a quickstart WAR file with all the things you need, and then grab the JARs from there. Any of these options would take you a tenth of the time you\'ve spent bitching on this mailing list. Yes Maven solves you some problems with dependecies and also si suitable for small project but at big projects it definitely fails. :-/ So Geronimo is a small project? And Jetty? And Apache Directory Server? And Wicket for that matter? And the several-hundreds-of-thousands-of- lines, 200+ dependencies projects we have here that use it? Jeez - I may have a high horse, but yours is scraping the stratosphere. Sure, it has some issues, but so does anything complex. The simple point is that for most people, Ivy or Maven 2 do what they want it to do. If you don\'t like any of these automated tools and insist on doing it all manually, you can\'t expect us to have all that much time for you, as we don\'t get paid to do this, you know. It\'s like you\'re complaining that there\'s no documentation on how to hammer in a nail using a screwdriver. So please. I know you have lot of work with wicket, and as users can see you have a good aproach. But please do spend some time to at least write one
Re: AjaxFallbackLink inside ListView
Worked like a charm, thanks Kent. You the same Kent Tong that wrote a online Tapestry book? Kent Tong wrote: pokkie wrote: My question is, how do I use this information to get the selected entity which represents a row in my listView? Try: public class Test extends WebPage { public Test() { ListString list = Arrays.asList(new String[] { a, b, c }); ListView eachItem = new ListView(eachItem, list) { @Override protected void populateItem(ListItem item) { item.add(new IndicatingAjaxFallbackLink(link) { @Override public void onClick(AjaxRequestTarget target) { handleClick(getParent().getModelObjectAsString()); } }); } }; add(eachItem); } private void handleClick(String clickedItem) { System.out.println(clickedItem); } } -- View this message in context: http://www.nabble.com/AjaxFallbackLink-inside-ListView-tf4389622.html#a12527658 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: Re: Wicket libraries
On 06 Sep 2007 18:24:44 +0200 (CEST), Robo [EMAIL PROTECTED] wrote: Sorry Eelco but me and also quite a lot of other developers(I know, contrary to others developers) consider same b.s. libraries which are \alive\ just because they are in classpath. It is like talking when nobody asks you ... Look at Java SDK do you need all packages to build console \Hello World!\ No. And who cares. They are just there and do their stuff when needed. So why wicket-velocity is doing job developer do not want and did not asked to. Where is writen that I cannot put mindesly tens of useles libs when they just sit there, assuming of course the packages are not duplicating. Do you understand why there are packages Eelco. Unles the class is uniqeu develioper should not be afreaid of using other class he wanted. To push your false premise to edge, why you deliberatly put all packages and classes into jar when you need just few of them also with dependencies. Isn`t it b.s.? Yes it is .. and also it is not conceptual ... Do not make zombie libraries and there wi ll be no problem with dependecies. Got the point? If not I`m not alble not help you sorry ... Yeah, it's not that I don't get your point, it's just that I don't agree. What I'm saying is that you don't live in that perfect world and not all software acts like you seem to expect. There is no rule that you can't what we do, and Java makes it possible. AND many other frameworks do this kind of initialization as well, so you can have the same problem in many other occasions. Not to mention problems with versioning and shared server libs you might have (especially with older app server versions) if you just include every jar you come across. Anyway, to my knowledge, wicket-velocity is the only project that initializes pulling in more dependencies. And as you're not using that, we can end this discussion now. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: Re: Re: Re: Wicket libraries stack trace
On 06 Sep 2007 18:32:44 +0200 (CEST), Robo [EMAIL PROTECTED] wrote: Yes I know Eelco. That is why there are so much troubles in Java programming land. Misusing of basic concepts ... That is why one needs some sort of COC, because there is lot`s of b.s. around ... J2EE 1.4 countained so much of it that lots of developers refused to use it And it had to be rewriten ... Apache Struts ... JSF ... Why did you started Wicket? Did`nt you wrote that MVC is kind of missconceptin? And I ask you Who told that? Eelco Hilenius? Yes and you were probably right. And in that time you with the tapestry was alone against the JSF Struts community. So accpet pleace that someone else is seeing miisconceptions and b.s. in other aspetcs of java programming and habits. OK? :-) Sure. You know, if you would just try to have a little bit more of a constructive tone... I'm sure we can patch wicket-velocity so that it avoids pulling in Velocity too early. And maybe the project tries to do too much upfront. Should be pretty easy to fix if you want to create a JIRA issue for it. About calling initializers (that's what triggers Velocity loading in this case), the feature is generally nice. We can use it to e.g. automatically register shared resources or like wicket-jmx does, register resources, so that to enable functionality in that lib is as easy as dropping in a jar. That's pretty cool functionality in my book. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Twice Behavior on the same event handler (wicket 1.2.x)
On 9/6/07, Igor Vaynberg [EMAIL PROTECTED] wrote: the problem with this stuff is that there is no single pattern that will work sometimes you want a chain where if a link fails the chain shortcircuits other times you dont want the shortcircuit sometimes you care about the order, other times you do not there are many variations of this and they are almost impossible to configure, so this isnt an easy problem. Yeah, that's the problem. Maybe if we would make the kind of chaining dependent on the attribute values? Furthermore, AttributeModifier and SimpleAttributeModifier are two convenience classes, but you can do the same by e.g. directly implementing IBehavior, not to mention the AjaxBehaviors that directly change attributes. Which makes that any chaining would be hard to get water proof. It's probably not completely impossible though. If someone can make a good proposal (with working code!) :) Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why the AbstractRepeater#onBeforeRender is final wicket-1.3.0-SNAPSHOT (6 sept 2007)?
and? why can't AbstractRepeater.onBeforeRender() be not final? If i overwrite to do what ever i want (but i do need to call onBeforeRender at some point else we generate an error) then it comes in AbstractRepeater.onBeforeRender() that first does the onPopulate so the items are created and then calls the super.. That i can never change even if onBeforeRender is not final.. johan On 9/6/07, Igor Vaynberg [EMAIL PROTECTED] wrote: since component.onbeforerender() is what cascades the onbeforerender() call to the children, when it comes to repeaters it is absolutely vital that super.onbeforerender() be called last, that way it will cascade to any new items added in repeater's onbeforerender(). -igor On 9/6/07, Johan Compagner [EMAIL PROTECTED] wrote: please tell me, tell me! johan On 9/6/07, Igor Vaynberg [EMAIL PROTECTED] wrote: because the final is there for a very important reason? -igor On 9/6/07, Johan Compagner [EMAIL PROTECTED] wrote: I take the discussion is about removing onPopulate now? why not keep onPopulate and remove the final? On 9/6/07, Igor Vaynberg [EMAIL PROTECTED] wrote: the reason for it being final is that the super.onbeforerender() call HAS to be done last, otherwise new items do not get onbeforerender called on them. so if we remove final will you remember to always call it last? i think the chances are that are pretty small, thus its final. -igor On 9/6/07, Alex Objelean [EMAIL PROTECTED] wrote: I've grabbed the latest SNAPSHOT from the repository and have noticed that AbstractRepeater#onBeforeRender is final. I wonder what is the reason for this? (I need to do something in it's subclass) /** * @see org.apache.wicket.Component#onBeforeRender() */ protected final void onBeforeRender() { if (isVisibleInHierarchy()) { onPopulate(); } super.onBeforeRender(); } Alex -- View this message in context: http://www.nabble.com/Why-the-AbstractRepeater-onBeforeRender-is-final-wicket-1.3.0-SNAPSHOT-%286-sept-2007%29--tf4391492.html#a12520558 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: @SpringBean and serialization checker
the custom serialization is already off by default for quite some time the org.apache.wicket.util.io.SerializableChecker$WicketNotSerializableException: only kicks in (so also for the default) when an IOException happens with writeObject So that you get a nice trace which field it exactly is of what object. johan On 9/6/07, Igor Vaynberg [EMAIL PROTECTED] wrote: i dont think our custom serialization works right with proxies yet is the thing -igor On 9/6/07, leok [EMAIL PROTECTED] wrote: It's a little hard for me to tear out all the @SpringBean declarations in my webapp. I could try using the standard serialization method you speak of and monitor the behavior. It seemed a little strange that this Exception would pop up with such a basic config so I figured that I was missing something. igor.vaynberg wrote: so if you remove @SpringBean dao the errors go away? it def shouldnt be happening, maybe its a problem in wicket's custom serialization. there is a way to make wicket use standard serialization...cant remember off the top of my head right now... -igor On 9/6/07, leok [EMAIL PROTECTED] wrote: Hi, I'm using the @SpringBean + SpringComponentInjector to inject daos in my Wicket web pages. With Wicket 1.3b3, I'm noticing the following exception in my Tomcat (v6.0.13) logs: org.apache.wicket.util.io.SerializableChecker$WicketNotSerializableException: Unable to serialize class: org.apache.commons.dbcp.BasicDataSource This exception occurs randomly and emerges from different page objects while browsing my webapp (probably SecondLevelSessionCache behavior?) and, if session persistence is enabled, at app shutdown. Nowhere in my application am I using the BasicDataSource class explicitly except in my beans.xml datasource configuration. My understanding was that a LazyInitProxyFactory would be serialized in place of the dao if the @SpringBean annotation were used. The page in which this occurred has a single @SpringBean private MyDao myDao; member field in it. I have no daos -- injected or otherwise -- in my WebSession instances. Is there some other configuration issue I'm missing? Or is this expected behavior? I'm relatively new to Spring and Wicket so the former is likely possible. Thanks! leo -- View this message in context: http://www.nabble.com/%40SpringBean-and-serialization-checker-tf4392171.html#a12522589 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/%40SpringBean-and-serialization-checker-tf4392171.html#a12524903 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: applicationwide datePattern
that worked - thank you Best Regards, Korbinian Francis De Brabandere schrieb: You can override newConverterLocator in your Application @Override protected IConverterLocator newConverterLocator() { ConverterLocator locator = new ConverterLocator(); locator.set(java.sql.Date.class, dateConverter); locator.set(Date.class, dateConverter); locator.set(Timestamp.class, dateConverter); return locator; } with dateConverter being something like this public final class DateTimeConverter extends DateConverter { @Override public DateFormat getDateFormat(Locale locale) { return DateFormat.getDateTimeInstance(DateFormat.MEDIUM, DateFormat.SHORT, locale); } } - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why the AbstractRepeater#onBeforeRender is final wicket-1.3.0-SNAPSHOT (6 sept 2007)?
no not for the onces that make a Repeater. Because then we aren't being able to tell that the populate should really be done before the call to super.onBeforeRender So having an onPopulate is fine. Repeaters should use that method to populate them selfs and we then also take care of the order but if somebody extends again that repeater he should be able to overwrite onBeforeRender() i think classes that implement the onPopulate should make that method final... Because that shouldn't be overridable (we don't have the check there that super is called) So just removing final of onBeforeRender (for developers who extend the real repeater again) and having an onPopulate for concreet classes that extend AbstractRepeater directly. (and those should make onPopulate final) johan On 9/6/07, Igor Vaynberg [EMAIL PROTECTED] wrote: if it was not final then there would be little point for keeping onpopulate, it would just be confusing -igor On 9/6/07, Johan Compagner [EMAIL PROTECTED] wrote: and? why can't AbstractRepeater.onBeforeRender() be not final? If i overwrite to do what ever i want (but i do need to call onBeforeRender at some point else we generate an error) then it comes in AbstractRepeater.onBeforeRender() that first does the onPopulate so the items are created and then calls the super.. That i can never change even if onBeforeRender is not final.. johan On 9/6/07, Igor Vaynberg [EMAIL PROTECTED] wrote: since component.onbeforerender() is what cascades the onbeforerender() call to the children, when it comes to repeaters it is absolutely vital that super.onbeforerender() be called last, that way it will cascade to any new items added in repeater's onbeforerender(). -igor On 9/6/07, Johan Compagner [EMAIL PROTECTED] wrote: please tell me, tell me! johan On 9/6/07, Igor Vaynberg [EMAIL PROTECTED] wrote: because the final is there for a very important reason? -igor On 9/6/07, Johan Compagner [EMAIL PROTECTED] wrote: I take the discussion is about removing onPopulate now? why not keep onPopulate and remove the final? On 9/6/07, Igor Vaynberg [EMAIL PROTECTED] wrote: the reason for it being final is that the super.onbeforerender () call HAS to be done last, otherwise new items do not get onbeforerender called on them. so if we remove final will you remember to always call it last? i think the chances are that are pretty small, thus its final. -igor On 9/6/07, Alex Objelean [EMAIL PROTECTED] wrote: I've grabbed the latest SNAPSHOT from the repository and have noticed that AbstractRepeater#onBeforeRender is final. I wonder what is the reason for this? (I need to do something in it's subclass) /** * @see org.apache.wicket.Component#onBeforeRender() */ protected final void onBeforeRender() { if (isVisibleInHierarchy()) { onPopulate(); } super.onBeforeRender(); } Alex -- View this message in context: http://www.nabble.com/Why-the-AbstractRepeater-onBeforeRender-is-final-wicket-1.3.0-SNAPSHOT-%286-sept-2007%29--tf4391492.html#a12520558 Sent from the Wicket - User mailing list archive at Nabble.com . - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: Re: Re: Re: Re: Wicket libraries stack trace
Sorry Eelco but I did not start this small personal war. In my previus of topic marked post I said lot of good about wicket and made lot of PLEASE do this ... I know you have lot of work ... IMHO ... and so on ... Also thanked to Gwyn? ... :-))) Al getted touched about my troubles with Maven, you started to talking b.s. and mindless way of something and started to solve and the same time started to solve some morality questions and so on. Gwyn started to look for truth in Joke :-)) POint me in one of my post when I said about Maven, or your work, that it is b.s. or mindless something. ... YOu will not find it. And also any personal negative sentences towards to any of the developers. I`m not trying to be polite. I`m rying to be correct to people. At the same time you are too polite and agresive ... :-) So after more than 26 hours of programming and mailing I`ll go for a Little bit of sleep. :-)) Bye Robo - Originálna Správa - Od: \Eelco Hillenius\ Komu: Poslaná: 06.09.2007 19:54 Predmet: Re: Re: Re: Re: Re: Wicket libraries stack trace On 06 Sep 2007 18:32:44 +0200 (CEST), Robo wrote: Yes I know Eelco. That is why there are so much troubles in Java programming land. Misusing of basic concepts ... That is why one needs some sort of COC, because there is lot`s of b.s. around ... J2EE 1.4 countained so much of it that lots of developers refused to use it And it had to be rewriten ... Apache Struts ... JSF ... Why did you started Wicket? Did`nt you wrote that MVC is kind of missconceptin? And I ask you Who told that? Eelco Hilenius? Yes and you were probably right. And in that time you with the tapestry was alone against the JSF Struts community. So accpet pleace that someone else is seeing miisconceptions and b.s. in other aspetcs of java programming and habits. OK? :-) Sure. You know, if you would just try to have a little bit more of a constructive tone... I\'m sure we can patch wicket-velocity so that it avoids pulling in Velocity too early. And maybe the project tries to do too much upfront. Should be pretty easy to fix if you want to create a JIRA issue for it. About calling initializers (that\'s what triggers Velocity loading in this case), the feature is generally nice. We can use it to e.g. automatically register shared resources or like wicket-jmx does, register resources, so that to enable functionality in that lib is as easy as dropping in a jar. That\'s pretty cool functionality in my book. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Najpopulárnejší blog na Slovensku - http://blog.sme.sk/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why the AbstractRepeater#onBeforeRender is final wicket-1.3.0-SNAPSHOT (6 sept 2007)?
if it was not final then there would be little point for keeping onpopulate, it would just be confusing -igor On 9/6/07, Johan Compagner [EMAIL PROTECTED] wrote: and? why can't AbstractRepeater.onBeforeRender() be not final? If i overwrite to do what ever i want (but i do need to call onBeforeRender at some point else we generate an error) then it comes in AbstractRepeater.onBeforeRender() that first does the onPopulate so the items are created and then calls the super.. That i can never change even if onBeforeRender is not final.. johan On 9/6/07, Igor Vaynberg [EMAIL PROTECTED] wrote: since component.onbeforerender() is what cascades the onbeforerender() call to the children, when it comes to repeaters it is absolutely vital that super.onbeforerender() be called last, that way it will cascade to any new items added in repeater's onbeforerender(). -igor On 9/6/07, Johan Compagner [EMAIL PROTECTED] wrote: please tell me, tell me! johan On 9/6/07, Igor Vaynberg [EMAIL PROTECTED] wrote: because the final is there for a very important reason? -igor On 9/6/07, Johan Compagner [EMAIL PROTECTED] wrote: I take the discussion is about removing onPopulate now? why not keep onPopulate and remove the final? On 9/6/07, Igor Vaynberg [EMAIL PROTECTED] wrote: the reason for it being final is that the super.onbeforerender() call HAS to be done last, otherwise new items do not get onbeforerender called on them. so if we remove final will you remember to always call it last? i think the chances are that are pretty small, thus its final. -igor On 9/6/07, Alex Objelean [EMAIL PROTECTED] wrote: I've grabbed the latest SNAPSHOT from the repository and have noticed that AbstractRepeater#onBeforeRender is final. I wonder what is the reason for this? (I need to do something in it's subclass) /** * @see org.apache.wicket.Component#onBeforeRender() */ protected final void onBeforeRender() { if (isVisibleInHierarchy()) { onPopulate(); } super.onBeforeRender(); } Alex -- View this message in context: http://www.nabble.com/Why-the-AbstractRepeater-onBeforeRender-is-final-wicket-1.3.0-SNAPSHOT-%286-sept-2007%29--tf4391492.html#a12520558 Sent from the Wicket - User mailing list archive at Nabble.com . - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: Re: Wicket libraries
If you care about the product of your own work, it 's personal. O.S.S. is based on self motivated developers who, by definition, care about their work. On 06 Sep 2007 19:36:36 +0200 (CEST), Robo [EMAIL PROTECTED] wrote: No Igor. Software is never personal. war is personal, dying of my mother, father and youg brother bombed by army aircraft is personal but software sure not ;-) If you can point me please to ANY of the disrespect sentences, except AL`s \why are you still bitching about it\ please do it ... :-) Robo - Originálna Správa - Od: \Igor Vaynberg\ Komu: Poslaná: 06.09.2007 19:36 Predmet: Re: Re: Wicket libraries On 06 Sep 2007 17:35:26 +0200 (CEST), Robo wrote: Stop it now please Al. You take oo personal aproach. Nobody forced you in responding. heh, what you have to understand is that wicket is oss - so it IS personal. it is something we work on in our spare time so it is kind of a hobby (a demanding hobby). we do care about it a great deal. constructive criticism is always welcome, but you have to have a level of respect on the lists. You make Wicket And I`m the user. If you do not like it do not do it. But there is some responsibilities about product you develop towards product users so do not confuse roles please. wrong again. its the other way around. if you do not like it do not use it. we do not owe you anything. we put wicket out there for people to use, no strings attached. And besides that I`m also kind of customer As I paid for the book ;-) you paid for the book, but we get nothing from that. so how do you connect the dots? And besides that I several times said how Wicket is great is that not enaugh for you? :-)) thank you. And btw I thanked to Gvyn at the end of my troubles as his responcese solved them. I do not thank before my troubles gets solved ;-) I`m not teacher in the dance school. its not the missing thank you, it is more your superior attitute and your lecturing tone. so in fact you do come across as a teacher. What I`m doing now is preparing presentation to my chiefs and currrently I`m coping with five frameworks amking demo apps and have two weeks for it. That is Why I`m not writing wiki and that is why I`m sometimes upset about lack of docs, working 18-20 hours per day ... sounds like your chiefs are pretty dumb if they expect you to learn five frameworks in two weeks, find a better job. as for the issue at hand, i believe the velocity initializer should be rewritten to check if whatever it needs is actually on the classpath, and noop quietly if its not. please file a jira issue. -igor Java jars are nto at all complex beast. They become tricky in situation where you just put some of them inclasspath and they do what you normally do not expect. Lib should be lib and when not called by developer they should do nothing. Deliberatly breaking this rule makes the jars, beast ... :-) So Finishing this personal thread and thank you for much of your time ;-)) Robo - Originálna Správa - Od: Al Maw Komu: Poslaná: 06.09.2007 17:44 Predmet: Re: Wicket libraries Robo wrote: Ok, seems removing \\\wicket-velocity-1.3.0-beta3.jar\\\ from build path solved problem with velocity problem. But please explain me why removing package from build path solves the problem if nowhere in my Hello World code i call for any of the velocity packages. Is there some duplicities in packages or what? I expect because Wicket looks on the classpath for Wicket modules to initialise, finds some in that JAR, tries to and then can\\\'t find one of its dependencies. Modern Java apps tend to be complex beasts, with lots of dependencies. If you insist on managing these manually, you can expect to have a fair bit of work to do. That\\\'s why things like Ivy and Maven 2 were invented. As to Maven2. It seems that like you in some way force developers to Maven2. :-) No, not at all. But if you\\\'ve deliberately chosen to manage your dependencies manually when there are perfectly good ways of doing it automatically, then we\\\'re not going to hold your hand for you. We don\\\'t get paid to do this, you know. If you don\\\'t like Maven 2 no one is forcing you to use it. Use Ivy instead. Or use the standalone Maven 2 Ant tasks for doing dependencies. Alternatively, install Maven 2, use it to build a quickstart WAR file with all the things you need, and then grab the JARs from there. Any of these options would take you a tenth of the time you\\\'ve spent bitching on this mailing list. Yes Maven solves you some problems with dependecies and also si suitable for small project but at big projects it definitely fails. :-/ So
Basic Wicket, and form submit question
Ok when the user press the submit button on a wicket form, how do you make it go to another page? onSubmit has a void return - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why the AbstractRepeater#onBeforeRender is final wicket-1.3.0-SNAPSHOT (6 sept 2007)?
thats why i said the concreet repeaters that implement onPopulate should make them final also what do you mean with funny errors, you only get funny errors when you override both or 1 and start calling the other. calling super on different times in your onBeforeRender doesn't create anything funny except one thing. Before the onBeforeRender you have the old items after it the new onces. johan On 9/6/07, Jan Kriesten [EMAIL PROTECTED] wrote: i think onPopulate() is there for just about 2 or 3 weeks and before the docs stated that calling super() would be vital. so, i really don't see a benefit in having a onpopulate() _and_ a non-final onbeforerender(). actually, if i override both, i could get funny errors changing a call to super.onbeforerender() at the end of an overridden onbeforerender() to the beginning - since code in onpopulate() would be called on different initialization stages. having no onpopulate() would move the responsability back into the onbeforerender() again. i would prefer to get lost of onpopulate() in favor of onbeforerender(). my 2c regards, --- jan. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Displaying images and Test from DB
Is there something like listview that I configure for displaying text and images? I do not need any sorting .. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Creating a disableable AjaxSubmitLink
Hi, I'm trying to create a disableable AjaxSubmitLink. When a user clicks on the link further clicks must not result in anything until the 'submission' is complete. This call be achieved by adding return false; in a call decorator. However I'm stuggling with the re-enabling. I need to strip the return false and put the original destination back. form.add(new AjaxSubmitLink(randomise, form) { protected void onSubmit(AjaxRequestTarget target, Form form) { somethingLong(); } protected IAjaxCallDecorator getAjaxCallDecorator() { return new AjaxCallDecorator() { public CharSequence decorateScript(CharSequence script) { return return false; + script; } public CharSequence decorateOnSuccessScript(CharSequence script) { // NEED TO RESET TO PREVIOUS STATE } public CharSequence decorateOnFailureScript(CharSequence script) { // NEED TO RESET TO PREVIOUS STATE } }; } }); Any help would be most appreciated. Thanks in advance Anthony
Re: Why the AbstractRepeater#onBeforeRender is final wicket-1.3.0-SNAPSHOT (6 sept 2007)?
ok, i don't like to have onBeforeRender final because we have the whole i called the super check for that. But i do like the onPopulate because that makes much more clear that the repeaters do there there work because why should that happen in onBeforeRender? The api does speak for them self then So i will remove the final of the onBeforeRender() but make all onPopulate implementations final because that just for the implementors The only exception being RepeatingView because thats just an empty implementation thats is supposed to be overwritten again.. by the way, these discussion do drain you, but your are happily contributing to threads like Wicket Libraries :) On 9/6/07, Igor Vaynberg [EMAIL PROTECTED] wrote: i will leave it up to you guys as to what you want to do and how. honestly discussions like this drain my attention span. the only reason i introduced onpopulate is so that i could make onbeforerender final. -igor On 9/6/07, Johan Compagner [EMAIL PROTECTED] wrote: thats why i said the concreet repeaters that implement onPopulate should make them final also what do you mean with funny errors, you only get funny errors when you override both or 1 and start calling the other. calling super on different times in your onBeforeRender doesn't create anything funny except one thing. Before the onBeforeRender you have the old items after it the new onces. johan On 9/6/07, Jan Kriesten [EMAIL PROTECTED] wrote: i think onPopulate() is there for just about 2 or 3 weeks and before the docs stated that calling super() would be vital. so, i really don't see a benefit in having a onpopulate() _and_ a non-final onbeforerender(). actually, if i override both, i could get funny errors changing a call to super.onbeforerender() at the end of an overridden onbeforerender() to the beginning - since code in onpopulate() would be called on different initialization stages. having no onpopulate() would move the responsability back into the onbeforerender() again. i would prefer to get lost of onpopulate() in favor of onbeforerender(). my 2c regards, --- jan. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Problem with DropDownChoice and AjaxFormComponentUpdatingBehavior
I am using Wicket 1.2.6. I have 3 DropDownChoices (and some other fields) on a form. The first DropDownChoice resets the selections in the other DropDownChoices using AjaxFormComponentUpdatingBehavior(onchange). All the DropDownChoices use PropertyModels. This all works fine until the form is submitted and validation fails. In this (normal) situation the form is still visible, with the feedback messages displayed, but the 2nd and 3rd DropDownChoices no longer react to the first DropDownChoice. I have verified that the properties on which DropDownChoices depend are being correctly set. Is there anything I can do to make them behave properly? Any help is appreciated. Thanks, Julian -- View this message in context: http://www.nabble.com/Problem-with-DropDownChoice-and-AjaxFormComponentUpdatingBehavior-tf4394596.html#a12531138 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Displaying images and Test from DB
you can build your own component very easily. listview can contain labels and/or images in any way you desire. Aaron Hutchings wrote: Is there something like listview that I configure for displaying text and images? I do not need any sorting .. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Basic-Wicket%2C-and-form-submit-question-tf4394056.html#a12531233 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why the AbstractRepeater#onBeforeRender is final wicket-1.3.0-SNAPSHOT (6 sept 2007)?
who? that overrides onBeforeRender? why should those call super last? that depends on what they want. On 9/6/07, Igor Vaynberg [EMAIL PROTECTED] wrote: because we are going in circles here even with onpopulate you still have to make sure you call super last! -igor On 9/6/07, Johan Compagner [EMAIL PROTECTED] wrote: ok, i don't like to have onBeforeRender final because we have the whole i called the super check for that. But i do like the onPopulate because that makes much more clear that the repeaters do there there work because why should that happen in onBeforeRender? The api does speak for them self then So i will remove the final of the onBeforeRender() but make all onPopulate implementations final because that just for the implementors The only exception being RepeatingView because thats just an empty implementation thats is supposed to be overwritten again.. by the way, these discussion do drain you, but your are happily contributing to threads like Wicket Libraries :) On 9/6/07, Igor Vaynberg [EMAIL PROTECTED] wrote: i will leave it up to you guys as to what you want to do and how. honestly discussions like this drain my attention span. the only reason i introduced onpopulate is so that i could make onbeforerender final. -igor On 9/6/07, Johan Compagner [EMAIL PROTECTED] wrote: thats why i said the concreet repeaters that implement onPopulate should make them final also what do you mean with funny errors, you only get funny errors when you override both or 1 and start calling the other. calling super on different times in your onBeforeRender doesn't create anything funny except one thing. Before the onBeforeRender you have the old items after it the new onces. johan On 9/6/07, Jan Kriesten [EMAIL PROTECTED] wrote: i think onPopulate() is there for just about 2 or 3 weeks and before the docs stated that calling super() would be vital. so, i really don't see a benefit in having a onpopulate() _and_ a non-final onbeforerender(). actually, if i override both, i could get funny errors changing a call to super.onbeforerender() at the end of an overridden onbeforerender() to the beginning - since code in onpopulate() would be called on different initialization stages. having no onpopulate() would move the responsability back into the onbeforerender() again. i would prefer to get lost of onpopulate() in favor of onbeforerender(). my 2c regards, --- jan. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why the AbstractRepeater#onBeforeRender is final wicket-1.3.0-SNAPSHOT (6 sept 2007)?
sure no problem, just point them out :) On 9/6/07, Igor Vaynberg [EMAIL PROTECTED] wrote: well, whenever those emails comein...why doesnt onbeforerender is getting called...you can answer them :) -igor On 9/6/07, Johan Compagner [EMAIL PROTECTED] wrote: who? that overrides onBeforeRender? why should those call super last? that depends on what they want. On 9/6/07, Igor Vaynberg [EMAIL PROTECTED] wrote: because we are going in circles here even with onpopulate you still have to make sure you call super last! -igor On 9/6/07, Johan Compagner [EMAIL PROTECTED] wrote: ok, i don't like to have onBeforeRender final because we have the whole i called the super check for that. But i do like the onPopulate because that makes much more clear that the repeaters do there there work because why should that happen in onBeforeRender? The api does speak for them self then So i will remove the final of the onBeforeRender() but make all onPopulate implementations final because that just for the implementors The only exception being RepeatingView because thats just an empty implementation thats is supposed to be overwritten again.. by the way, these discussion do drain you, but your are happily contributing to threads like Wicket Libraries :) On 9/6/07, Igor Vaynberg [EMAIL PROTECTED] wrote: i will leave it up to you guys as to what you want to do and how. honestly discussions like this drain my attention span. the only reason i introduced onpopulate is so that i could make onbeforerender final. -igor On 9/6/07, Johan Compagner [EMAIL PROTECTED] wrote: thats why i said the concreet repeaters that implement onPopulate should make them final also what do you mean with funny errors, you only get funny errors when you override both or 1 and start calling the other. calling super on different times in your onBeforeRender doesn't create anything funny except one thing. Before the onBeforeRender you have the old items after it the new onces. johan On 9/6/07, Jan Kriesten [EMAIL PROTECTED] wrote: i think onPopulate() is there for just about 2 or 3 weeks and before the docs stated that calling super() would be vital. so, i really don't see a benefit in having a onpopulate() _and_ a non-final onbeforerender(). actually, if i override both, i could get funny errors changing a call to super.onbeforerender() at the end of an overridden onbeforerender() to the beginning - since code in onpopulate() would be called on different initialization stages. having no onpopulate() would move the responsability back into the onbeforerender() again. i would prefer to get lost of onpopulate() in favor of onbeforerender(). my 2c regards, --- jan. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DetachableContactModel question
Hello, In the repeteater samples, the one with ajax capability you have DetachableContactModel. My question is why protected Object load() { // loads contact from the database return getContactsDB().get(id); } does not just return the Contact object? It is already determined by the constructor. public DetachableContactModel(Contact c) { this(c.getId()); contact = c; } [this is the one called by SortableDataProvider] Why the extra roundtrip to the database? Sorry if this is a silly question. Thks in advance.
Re: AjaxFallbackLink inside ListView
pokkie wrote: Worked like a charm, thanks Kent. You the same Kent Tong that wrote a online Tapestry book? Yep. -- View this message in context: http://www.nabble.com/AjaxFallbackLink-inside-ListView-tf4389622.html#a12534270 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]