Re: Works in Development Mode but not in Production Mode
Shortly after we discovered this issue we made the same modification to our application. While not absolutely fool proof (and what is anyway?) it does shorten the loop on discovering these issues. However, I have actually seen this create its own problems when developing with a heavy use of panels and custom components. A lot of times it is useful to see where those wicket: tags are in the fully rendered document so you can figure out what parts of the html belong where so as to allow your css ninja to create the correct layout for you because the designers don't think in terms of the same kind of components us wicket developers do. In any case your suggestion is an excellent one and I recommend it to anyone developing anything but the most trivial of applications. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Works-in-Development-Mode-but-not-in-Production-Mode-tp2300335p2302610.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Works in Development Mode but not in Production Mode
We had a similar problem with some heavy javascript for resizing things on the screen. Since then in on our application init we call: getMarkupSettings().setStripWicketTags(true); So on both Development and Deployment mode we have a similar HTML output and we don't risk trying Ajax refresh on a wicket:container On Fri, Jul 23, 2010 at 6:30 PM, Adam Bender [via Apache Wicket] ml-node+2300335-1309396158-293...@n4.nabble.comml-node%2b2300335-1309396158-293...@n4.nabble.com wrote: Greetings, I recently ran into an issue involving the swapping of fragments on an ajax event. The scenario looks roughly like this: 1) User comes to page with a form on it 2) User fills in form and clicks submit 3) Form is validated and accepted and a confirmation message is shown In this case the form and the confirmation message are both fragments and in order to achieve the visual effect desired the confirmation is swapped with the form during the execution of the onSubmit event handler for an AjaxButton. The effective wicket looks like this: wicket:container wicket:id=feedbackContainer/wicket:container wicket:fragment wicket:id=feedbackForm ... relevant html to display form... /wicket:fragment wicket:fragment wicket:id=feedbackConfirmation ... relevant html to display confirmation... /wicket:fragment and the Java for swapping is something like this: feedbackForm.replaceWith(feedbackConfirmation); target.addComponent(feedbackConfirmation); Now when I run this in Development mode everything works exactly as expected. However, when I switch to Production mode (or suppress wicket tags during application configuration) this fails. In hindsight the reason is obvious - wicket:container will be removed from the page when Wicket tags are suppressed - but the only error message that appeared was in the ajax debugger (not usually where I find out about missing components). And while the error messages were telling me that the feedbackContainer wasn't on the screen this didn't make sense to me because I could plainly see it in my source. I ran around making sure I had setOutputMarkupId(true) on everything I could think of but to know avail - there just didn't seem to be any good feedback on what was wrong. Of course one could argue that I could have gotten to the bottom of this problem quicker if I just viewed the source of the page, or if I was more reliant on the ajax debugger and I agree. What is really at issue here is that we had a working feature in our test environment that - though no code was changed - started failing in our staging environment and no good information to diagnose it. Now to the feature request. As I said, in hindsight the problem here was obvious and the solution was very simple: change the wicket container into a real html element. What confounded me is that a subtle change to my runtime configuration actually broke a feature that was otherwise working fine. The change to the configuration happened at a time and place far removed from when the code was written and so the debugging process was very frustrating (a bit of that spooky action at a distance). Usually, the error messages and feedback from wicket are tremendous and I have often bragged about them to my peers using other less 'human friendly' frameworks. I have come to so rely on the error messages produced that when I dont see one I generally assume all is working well. For this reason it was quite difficult to track down the actual cause of the problem. So I ask: is it possible to provide a warning in the logs that a situation has been created that may not work in production mode because of the use of fragments in conjunction with a wicket:container? Or perhaps a more general message that captures the general issue of using wicket containers in production mode? I realize this may be a long shot of a request for any number of reasons (perhaps I am the only one foolish enough to put wicket:containers in my html) but I just spent half a day trying to sort out this problem and I was hoping to keep someone else from wasting their time. Thanks, Adam -- View message @ http://apache-wicket.1842946.n4.nabble.com/Works-in-Development-Mode-but-not-in-Production-Mode-tp2300335p2300335.html To start a new topic under Wicket - User, email ml-node+1842947-1647783149-293...@n4.nabble.comml-node%2b1842947-1647783149-293...@n4.nabble.com To unsubscribe from Wicket - User, click herehttp://apache-wicket.1842946.n4.nabble.com/subscriptions/Unsubscribe.jtp?code=YXZyYWhhbXJAZ21haWwuY29tfDE4NDI5NDd8LTEwNzY0NzQ1ODc=. -- []'s Avraham Rosenzweig avrah...@gmail.com
Works in Development Mode but not in Production Mode
Greetings, I recently ran into an issue involving the swapping of fragments on an ajax event. The scenario looks roughly like this: 1) User comes to page with a form on it 2) User fills in form and clicks submit 3) Form is validated and accepted and a confirmation message is shown In this case the form and the confirmation message are both fragments and in order to achieve the visual effect desired the confirmation is swapped with the form during the execution of the onSubmit event handler for an AjaxButton. The effective wicket looks like this: wicket:container wicket:id=feedbackContainer/wicket:container wicket:fragment wicket:id=feedbackForm ... relevant html to display form... /wicket:fragment wicket:fragment wicket:id=feedbackConfirmation ... relevant html to display confirmation... /wicket:fragment and the Java for swapping is something like this: feedbackForm.replaceWith(feedbackConfirmation); target.addComponent(feedbackConfirmation); Now when I run this in Development mode everything works exactly as expected. However, when I switch to Production mode (or suppress wicket tags during application configuration) this fails. In hindsight the reason is obvious - wicket:container will be removed from the page when Wicket tags are suppressed - but the only error message that appeared was in the ajax debugger (not usually where I find out about missing components). And while the error messages were telling me that the feedbackContainer wasn't on the screen this didn't make sense to me because I could plainly see it in my source. I ran around making sure I had setOutputMarkupId(true) on everything I could think of but to know avail - there just didn't seem to be any good feedback on what was wrong. Of course one could argue that I could have gotten to the bottom of this problem quicker if I just viewed the source of the page, or if I was more reliant on the ajax debugger and I agree. What is really at issue here is that we had a working feature in our test environment that - though no code was changed - started failing in our staging environment and no good information to diagnose it. Now to the feature request. As I said, in hindsight the problem here was obvious and the solution was very simple: change the wicket container into a real html element. What confounded me is that a subtle change to my runtime configuration actually broke a feature that was otherwise working fine. The change to the configuration happened at a time and place far removed from when the code was written and so the debugging process was very frustrating (a bit of that spooky action at a distance). Usually, the error messages and feedback from wicket are tremendous and I have often bragged about them to my peers using other less 'human friendly' frameworks. I have come to so rely on the error messages produced that when I dont see one I generally assume all is working well. For this reason it was quite difficult to track down the actual cause of the problem. So I ask: is it possible to provide a warning in the logs that a situation has been created that may not work in production mode because of the use of fragments in conjunction with a wicket:container? Or perhaps a more general message that captures the general issue of using wicket containers in production mode? I realize this may be a long shot of a request for any number of reasons (perhaps I am the only one foolish enough to put wicket:containers in my html) but I just spent half a day trying to sort out this problem and I was hoping to keep someone else from wasting their time. Thanks, Adam
