JQuery .ajax Call Breaks In 6.18
We have some client side js that constructs a new FormData() object, adds fields to it including a file and posts it to a Wicket behavior using a $.ajax() call. In the behavior's onRequest(), we get the fields and file from the MultipartServletWebRequest object. This worked perfectly until 6.18. Now the behavior gets called but no fields from the constructed DataForm object are in the requestParameters and the getFiles() call is empty. Any thoughts or ideas for a workaround? -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/JQuery-ajax-Call-Breaks-In-6-18-tp4668393.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: JQuery .ajax Call Breaks In 6.18
That did the trick. Thank you! -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/JQuery-ajax-Call-Breaks-In-6-18-tp4668393p4668395.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Netbeans and Compile On Save
I'm pretty sure I had the problem with 6.13. Unfortunately I've been working around it for so long that I can't really say when it started happening. It's possible I was using a different version of Netbeans or maybe it was when I ported from Wicket 1.4 to 6 (although I don't think so). I haven't had any luck finding a solution. I'm using Tomcat, BTW. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Netbeans-and-Compile-On-Save-tp4665159p4665210.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Netbeans and Compile On Save
I used to be able to make code changes in Netbeans, save and test the results immediately. For some time now, this compile on save functionality no longer works unless I first log out of my web app. It seems the session is invalid after the intermediate compile. I'm getting a NoClassDefFoundError for the current page (ultimately originating out of DefaultPageFactory.newPage line 65 in wicket 6.14). I've ignored the problem for awhile now but I'd like to get it resolved. If I forget to sign out after save, I have to restart the entire application to continue. Has anyone seen this and found a workaround? I'm using Netbeans 8 but the problem also existed in 7.4. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Netbeans-and-Compile-On-Save-tp4665159.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Problems with Page Expiration
Martin Grigorov-4 wrote If the login page is really stateless then it will never throw PageExpiredException. It seems some component/behavior in the login page is stateful. Use org.apache.wicket.devutils.stateless.StatelessChecker (wicket-devutils) or debug org.apache.wicket.Page#isPageStateless() to find why the page is stateful Thanks for the response. I suspected as much but when I put a breakpoint in isPageStateless(), it always returns true for each call made when I refresh the login page. Again, with setRecreateMountedPagesAfterExpiry set to false, pressing the login button always takes me to the timout page set by setPageExpiredErrorPage. I don't get it. Initially I thought it was something in our templating mechanism. Our platform allows an advanced user to design the login screen. I skipped that and reduced my test to just a StatelessForm on a page. Same result. The page is a subclass and makes use of wicket:extend but the parent class doesn't do anything but set the page title. I've checked my authorization strategy and I don't see anything problematic. No doubt it will be something silly but at the moment I'm perplexed. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Problems-with-Page-Expiration-tp4664774p4664807.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Problems with Page Expiration
Martin Grigorov-4 wrote Try to reproduce it in a quickstart and attach it to Jira. Martin Grigorov Wicket Training and Consulting I created a quickstart using the Wicket Examples statelessform page as the home page. If setRecreateMountedPagesAfterExpiry is false, the page expires on form submit. I'll submit the quickstart but I still find it hard to believe it's a bug. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Problems-with-Page-Expiration-tp4664774p4664820.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Problems with Page Expiration
When setRecreateMountedPagesAfterExpiry is true in our app, redirecting to a custom timeout page either through setPageExpiredErrorPage or via catching a PageExpiredException isn't working (the exception never makes it to onException in IRequestCycleListener). When set to false, the redirect works fine but my stateless login page immediately throws a PageExpiredException when the login form is submitted. If I make the form stateful, everything works but of course my login page eventually expires. This is something we want to avoid. We're using Wicket 6.14. Any thoughts? -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Problems-with-Page-Expiration-tp4664774.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Resource.getResourceStream() called twice in 1.4.15
To follow-up it appears getResourceStream is being called multiple times per request for other shared resources like generated images (even under 1.4.12). This can be extremely inefficient depending on the amount of work done. I'm wondering if there's something wrong with my configuration. Any thoughts? I'm basically extending Resource and overriding getResourceStream to return either a generated image (via AbstractResourceStream) or text information (via StringResourceStream). -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Resource-getResourceStream-called-twice-in-1-4-15-tp3225454p3227876.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Resource.getResourceStream() called twice in 1.4.15
Thanks. I submitted an issue in Jira with a quickstart . https://issues.apache.org/jira/browse/WICKET-3357 -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Resource-getResourceStream-called-twice-in-1-4-15-tp3225454p3228511.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Resource.getResourceStream() called twice in 1.4.15
Not too long ago I built a url-based api into our web app. I basically mounted a shared resource and then hooked into getResourceStream to process information from the url parameters and insert the result into our data store. Under 1.4.15 I'm getting duplicate records because getResourceStream is being called twice for every request. This doesn't happen in 1.4.12. Is there any way to avoid the duplication? I'm hesitant to rollback to 1.4.12 for other reasons. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Resource-getResourceStream-called-twice-in-1-4-15-tp3225454p3225454.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket 1.4.14 Bug with panels updated by Ajax rendering a CSS
Let me know how it goes. I can't help but think this bug is related to the problem I'm seeing. -Original Message- From: Antoine Angénieux Sent: Tuesday, November 30, 2010 7:05 AM To: users@wicket.apache.org Subject: Re: Wicket 1.4.14 Bug with panels updated by Ajax rendering a CSS Nobody has any idea on the subject ? OK, I'll come up with a quickstart this WE ! Cheers, Antoine. Le 29/11/2010 15:42, Antoine Angenieux a écrit : Hi all, I have just upgraded my dev environment from Wicket 1.4.13 to 1.4.14 this morning and discovered a bug related to CSS. On a page, I have a panel containing a listview, itself populated with panels that have in their constructor: add(CSSPackageResource.getHeaderContribution(CSS)); When browsing to this page, the listview is initially empty. When the panel is updated by an Ajax Link making the listview model list not empty, the list view contents are rendered, but the CSS is not (and the reference to the css script does not appear in the Wicket Ajax Debug Window), and thus the presentation is all messed up. I just downgraded back to Wicket 1.4.13, and all is fine. I don't have time to prepare a Quickstart yet, but if anyone who has been fixing bugs on Wicket 1.4.14 has a brilliant intuition on what can cause this regression, it would be great ;) Otherwise, I'll try to find sometime later this week to file a JIRA issue with a Quickstart. Cheers, Antoine. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket 1.4.14 and WiQuery Tabs
This is from another thread but it sounds like the devs have found the problem (and a fix). I'm hopeful anyway! http://apache-wicket.1842946.n4.nabble.com/Re-svn-commit-r1031432-wicket-branches-wicket-1-4-x-wicket-src-main-java-org-apache-wicket-ajax-Ajaxa-tt3067178.html - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket 1.4.14 and WiQuery Tabs
I managed to get wiquery 1.1.1 working (under 1.4.12). Unfortunately I'm still getting inconsistent behavior with Wicket 1.4.14. I'm looking at the diffs to try and find the culprit...not sure how else to pin this down. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket 1.4.14 and WiQuery Tabs
When I look at a diff from the ajax debug window between the failed 1.4.14 request and the 1.4.12, it's obvious the wiquery javascript resources aren't being contributed in the error scenarios. Any thoughts on where to look in Wicket to see why these contributions are failing? -Original Message- From: Brian Topping Sent: Tuesday, November 30, 2010 11:54 AM To: users@wicket.apache.org Subject: Re: Wicket 1.4.14 and WiQuery Tabs On Nov 30, 2010, at 12:30 PM, Brad Grier wrote: not sure how else to pin this down. If it were me, I would diff the generated HTML, then narrow down which component(s) is/are causing the headache, THEN diff changes in those components. As well because it's a great way to learn more about the code in the process instead of just being numbed by the volume of changes... - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket 1.4.14 and WiQuery Tabs
I actually did a bit of what you described. I found where wiquery contributes the js files. I was hoping it would be as simple as some evaluation preventing that call in 1.4.14. Of course not. The contribution from wiquery happens regardless. I even stepped forward to the point where renderJavascriptReference is called on IHeaderResponse...happens regardless. After that I was in Wicket code and it became difficult to know what was happening. I wonder if there's some place in my code where I could save a stack trace and then just compare the working and non-working method calls. If they were different, I'd know where to look. Unfortunately I'm not sure how to create a quickstart when this problem seems to reveal itself in the way we're dynamically creating our pages. The quickstart would likely end up being not-so-quick. I'll look at it a bit more before giving up and hoping someone else will report the bug in an (easily) reproducible way. Thanks for all the help. -Original Message- From: Brian Topping Sent: Tuesday, November 30, 2010 5:02 PM To: users@wicket.apache.org Subject: Re: Wicket 1.4.14 and WiQuery Tabs Maybe find the contributions in the source tree, look for references in the code to that filename. Set a breakpoint on the code that normally contributes it, run the old code that works. When you hit the breakpoint, set more breakpoints a reasonably relevant distance back up the call chain (the caller, the caller's caller, etc). Now run it with the broken code and the breakpoints in the same places and see what decisions are being made differently, why the call chain never makes it as deep as the working configuration. You can do all this statically (i.e. with find usages searches), but the use of interfaces with multiple implementations can obscure the food chain unless you really know what to look for. On Nov 30, 2010, at 5:49 PM, Brad Grier wrote: When I look at a diff from the ajax debug window between the failed 1.4.14 request and the 1.4.12, it's obvious the wiquery javascript resources aren't being contributed in the error scenarios. Any thoughts on where to look in Wicket to see why these contributions are failing? -Original Message- From: Brian Topping Sent: Tuesday, November 30, 2010 11:54 AM To: users@wicket.apache.org Subject: Re: Wicket 1.4.14 and WiQuery Tabs On Nov 30, 2010, at 12:30 PM, Brad Grier wrote: not sure how else to pin this down. If it were me, I would diff the generated HTML, then narrow down which component(s) is/are causing the headache, THEN diff changes in those components. As well because it's a great way to learn more about the code in the process instead of just being numbed by the volume of changes... - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket 1.4.14 Bug with panels updated by Ajax rendering a CSS
Since upgrading the tabs from wiQuery 1.02 no longer work in my application. Could be related as the CSS isn't being picked up at all. These are tabs on panels displayed via ajax. -Original Message- From: Antoine Angenieux Sent: Monday, November 29, 2010 8:42 AM To: users@wicket.apache.org Subject: Wicket 1.4.14 Bug with panels updated by Ajax rendering a CSS Hi all, I have just upgraded my dev environment from Wicket 1.4.13 to 1.4.14 this morning and discovered a bug related to CSS. On a page, I have a panel containing a listview, itself populated with panels that have in their constructor: add(CSSPackageResource.getHeaderContribution(CSS)); When browsing to this page, the listview is initially empty. When the panel is updated by an Ajax Link making the listview model list not empty, the list view contents are rendered, but the CSS is not (and the reference to the css script does not appear in the Wicket Ajax Debug Window), and thus the presentation is all messed up. I just downgraded back to Wicket 1.4.13, and all is fine. I don't have time to prepare a Quickstart yet, but if anyone who has been fixing bugs on Wicket 1.4.14 has a brilliant intuition on what can cause this regression, it would be great ;) Otherwise, I'll try to find sometime later this week to file a JIRA issue with a Quickstart. Cheers, Antoine. -- Antoine Angénieux Associé Clinigrid 5, avenue Mozart 75016 Paris, France +336 60 21 09 18 aangeni...@clinigrid.com - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Wicket 1.4.14 and WiQuery Tabs
After 1.4.14 wiquery tab components no longer render in my application. These tabs are sitting on panels displayed via ajax so perhaps it’s something to do with the css/javascript contribution. Interestingly the wiquery accordions still work fine.
Re: Wicket 1.4.14 and WiQuery Tabs
Hey thanks for trying it. My tabs are on panels that get swapped in and out via ajax. Are you using this approach? Since our app creates these tabs dynamically via ListViews, I thought maybe it was my implementation. As a test I took the most basic tab example from the wiQuery site and put it on a panel displayed via ajax when a link is clicked. It's not working either. If I go back to 1.4.12, it works fine. I'll poke around a little with Firebug but I'm guessing the css and perhaps javascript aren't being contributed in my scenario. -Original Message- From: Brian Topping Sent: Monday, November 29, 2010 12:27 PM To: users@wicket.apache.org Subject: Re: Wicket 1.4.14 and WiQuery Tabs On Nov 29, 2010, at 12:04 PM, Brad Grier wrote: After 1.4.14 wiquery tab components no longer render in my application. These tabs are sitting on panels displayed via ajax so perhaps it’s something to do with the css/javascript contribution. Interestingly the wiquery accordions still work fine. Since I was due to upgrade this as well and am using both wiquery accordions and tabs, I thought I would give it a try. My tabs are on panels that are triggered by selections in the accordions (hey, are we working on the same source tree? ;-)). But I'm unable to replicate this, everything is rendering fine. If I can assist by checking any specific rendering or you want a snippet of the HTML that's being generated on my end to help you debug, feel free to contact me off-list. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket 1.4.14 and WiQuery Tabs
Okay, well...it's more than a contribution problem. It looks like the tab's associated div, ul and li tags do not get modified by wiquery in 1.4.14. WiQuery assigns classes to these tags (ui-tabs, ui-tabs-nav, ui-state-default, etc). Those are all missing when I run in Wicket 1.4.14. Since it works fine for you, I'm not sure where to look. -Original Message- From: Brian Topping Sent: Monday, November 29, 2010 2:04 PM To: users@wicket.apache.org Subject: Re: Wicket 1.4.14 and WiQuery Tabs On Nov 29, 2010, at 3:02 PM, Brian Topping wrote: On Nov 29, 2010, at 2:39 PM, Brad Grier wrote: My tabs are on panels that get swapped in and out via ajax. Are you using this approach? They are ajax, but I haven't bothered looking at how it works. Here's what I use in populateItem(): mainContentPanel = cp.loadComponentInstance(mainContentPanel); mainContentPanel.setOutputMarkupId(true); AdminPage.this.replace(mainContentPanel); target.addComponent(mainContentPanel); Erm, that should have been what I use in my onClick()... - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket 1.4.14 and WiQuery Tabs
Sadly, none of my wiquery components seem to work under 1.1.1. Previously, I had to disable auto-import of jquery resources because I was having conflicts with other jquery-based components (jgrowl, custom stuff). Maybe that's why. I assume 1.1.1 is backwards compatible and setup is the same? Anyway, tabs do work in *certain* places using 1.03. A panel with a broken tab will work if placed on a different page/panel. (In other words, if I use the app's cms interface to position the panel somewhere else). Once tabs start working, they work everywhere in the application until logout. I can't figure out what's different between the working and non-working instances of the same panel. It's odd. I suppose I need to debug into wiquery and/or wicket. If I switch to 1.4.12, no problems at all. -Original Message- From: Brian Topping Sent: Monday, November 29, 2010 3:48 PM To: users@wicket.apache.org Subject: Re: Wicket 1.4.14 and WiQuery Tabs Ah, great point. I am already using 1.1.1! On Nov 29, 2010, at 4:34 PM, julien roche AKA indiana_jules wrote: Hi all, Can you try tabs with the last release of wiquery ? (the 1.1.1). A lot of changes and refactoring were don into the core. Maybe that will solved your problems. Can you give me your feedbacks please . Thank you Regards Julien Roche On Mon, Nov 29, 2010 at 9:33 PM, Brad Grier brad.gr...@salusnovus.comwrote: Okay, well...it's more than a contribution problem. It looks like the tab's associated div, ul and li tags do not get modified by wiquery in 1.4.14. WiQuery assigns classes to these tags (ui-tabs, ui-tabs-nav, ui-state-default, etc). Those are all missing when I run in Wicket 1.4.14. Since it works fine for you, I'm not sure where to look. -Original Message- From: Brian Topping Sent: Monday, November 29, 2010 2:04 PM To: users@wicket.apache.org Subject: Re: Wicket 1.4.14 and WiQuery Tabs On Nov 29, 2010, at 3:02 PM, Brian Topping wrote: On Nov 29, 2010, at 2:39 PM, Brad Grier wrote: My tabs are on panels that get swapped in and out via ajax. Are you using this approach? They are ajax, but I haven't bothered looking at how it works. Here's what I use in populateItem(): mainContentPanel = cp.loadComponentInstance(mainContentPanel); mainContentPanel.setOutputMarkupId(true); AdminPage.this.replace(mainContentPanel); target.addComponent(mainContentPanel); Erm, that should have been what I use in my onClick()... - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Memory Leak in 1.4.13?
I recently upgraded our app from 1.4.12 to 1.4.13. Our app has an admin screen that shows the current session size using Session’s getSizeInBytes method. This screen is just a panel that gets replaced/refreshed via Ajax when a link is clicked. Today I noticed that every time I clicked the link to reload the panel the session size grows by around 3000 KB and never does a gc. If I roll back to 1.4.12 and the problem goes away. In the Netbeans profiler, the only thing I see spiraling out of control are byte[] objects (serialized objects?). Nothing unusual appears with the size or number of my application specific objects. For now I’m rolling back to 1.4.12 as I’m not sure how this is affecting things outside this specific screen. Thanks.
Re: Memory Leak in 1.4.13?
Hopefully I can recreate in a quickstart. The pages in our app are dynamically created. If this leak is somehow related to how the layout engine works it might be difficult. I'll see what I can do. -Original Message- From: Jeremy Thomerson Sent: Wednesday, November 10, 2010 5:23 PM To: users@wicket.apache.org Subject: Re: Memory Leak in 1.4.13? On Wed, Nov 10, 2010 at 5:57 PM, Brad Grier brad.gr...@salusnovus.comwrote: I recently upgraded our app from 1.4.12 to 1.4.13. Our app has an admin screen that shows the current session size using Session’s getSizeInBytes method. This screen is just a panel that gets replaced/refreshed via Ajax when a link is clicked. Today I noticed that every time I clicked the link to reload the panel the session size grows by around 3000 KB and never does a gc. If I roll back to 1.4.12 and the problem goes away. In the Netbeans profiler, the only thing I see spiraling out of control are byte[] objects (serialized objects?). Nothing unusual appears with the size or number of my application specific objects. For now I’m rolling back to 1.4.12 as I’m not sure how this is affecting things outside this specific screen. Thanks. Please create a quickstart and see if you can reproduce this. If you can, attach it to a JIRA. We'll fix it. -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org* - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
TinyMCE in ModalWindow
I've implemented TinyMCE in my app and all is well with one exception. I can't get it to work in a ModalWindow (TinyMCE works the first time but subsequently opens in an blank, uneditable state). Someone suggested using the TinyMCE javascript functions mceRemoveControl and mceAddControl to work around this issue. If that's the answer, I can't get it to work (likely because I'm missing something). Has anyone found a workaround to this problem?
Re: Replacing Contents of ModalWindow
I found the solution/problem. The default form submit logic was adding the form to the AjaxRequestTarget. Skipping this when the form is in a modal window and needs to be replaced allows the panel to be swapped out. Also, setContent on the ModalWindow doesn't seem to work here. I had to replace the form (actually it's enclosing panel) with replaceWith(newPanel). -- From: Brad Grier brad.gr...@salusnovus.com Sent: Tuesday, August 10, 2010 10:38 PM To: users@wicket.apache.org Subject: Replacing Contents of ModalWindow We allow users to define custom triggers on a form submit (an ajax submit). These triggers can send an email or take the user to another form/panel (basically a panel-swap via Ajax). This panel-swap works fine until circumstances land the form in a ModalWindow. I can't get the ModalWindow to replace it's contents once it's showing. I've tried setContent() and replace(). I've tried closing the window, setting the content and opening it. Nothing works. And yes, I do have the ModalWindow embedded in another form per the javadoc. Something is odd because I also have a custom Link class that swaps out its parent panel via ajax and those links work fine in a ModelWindow. Does anyone have any insight? Is there something about form processing that prevents this from working? Thanks! - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Replacing Contents of ModalWindow
We allow users to define custom triggers on a form submit (an ajax submit). These triggers can send an email or take the user to another form/panel (basically a panel-swap via Ajax). This panel-swap works fine until circumstances land the form in a ModalWindow. I can't get the ModalWindow to replace it's contents once it's showing. I've tried setContent() and replace(). I've tried closing the window, setting the content and opening it. Nothing works. And yes, I do have the ModalWindow embedded in another form per the javadoc. Something is odd because I also have a custom Link class that swaps out its parent panel via ajax and those links work fine in a ModelWindow. Does anyone have any insight? Is there something about form processing that prevents this from working? Thanks!
Validators on Required Fields
I'm using EmailAddressValidator on a form field with setRequired(false). The validator is triggering an invalid format message when the field is left blank. I'm having the same problem with RangeValidator against a custom currency class I've created. Shouldn't validation be skipped when the field is empty? When I use RangeValidator with Longs or Doubles, it behaves like I'd expect. I'm sure I'm missing something obvious but I've been scratching my head longer than I care to admit! Thanks.
Big Problem with TinyMCE
I'm trying to use a TinyMCE editor on a form (itself belonging to a panel added to a page via Ajax). The form is submitted via an AjaxButton. From other posts here and elsewhere I found I had to call tinyMCE.triggerSave(true,true); before the submit to get the data into the textarea's model and then tinyMCE.idCounter=0; after the submit. I used an IAjaxCallDecorator to add these functions to the submit button. The problem is that the form only submits with every other press of the button. When it fails, it looks like no script appended after the triggerSave runs. Can anyone help me out? I'm stuck. Thanks, Brad
Choose One Text Without Property File?
I'd like to be able to change the Choose One text for a DropDownChoice without using a property file. I have a dynamic form generator and I need the user to be able to designate the verbiage. Is this possible? Thanks, Brad
Wicket Forms on PS3 Browser
I just tried out my Wicket-based site on the PS3's native browser. The strange thing is that none of the forms worked. It's as if the onSubmit is never called. I went to the Wicket home page and confirmed this behavior. I don't recall seeing this happen with other forms. I suppose it's not a big deal but it makes me wonder what's going on.
Re: Wicket Forms on PS3 Browser
Good link. I didn't really expect the app to work but I thought the form submit would be the least of my problems. I still find it interesting that forms seem to work for other sites. -- From: Alex Rass a...@itbsllc.com Sent: Saturday, March 13, 2010 5:57 PM To: users@wicket.apache.org Subject: RE: Wicket Forms on PS3 Browser Perhaps has to do with: ..., the PS3 browser reports nothing except a user-agent of Mozilla/5.0 (PLAYSTATION 3; 1.00). Everything else is blank. The PS3 apparently does not send an HTTP-Accept header to the server. It supports Javascript but will not divulge which version. Finally, it reports no mime types, no plugins, and no Javascript errors That and more here: http://www.design215.com/read.php?title=playstation%203%20browser%20specs - Alex. -Original Message- From: Brad Grier [mailto:brad.gr...@salusnovus.com] Sent: Saturday, March 13, 2010 6:24 PM To: users@wicket.apache.org Subject: Wicket Forms on PS3 Browser I just tried out my Wicket-based site on the PS3's native browser. The strange thing is that none of the forms worked. It's as if the onSubmit is never called. I went to the Wicket home page and confirmed this behavior. I don't recall seeing this happen with other forms. I suppose it's not a big deal but it makes me wonder what's going on. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: FeedbackPanel for Dynamic Form
Thanks for the tip on the reuseItems method. The solution to my problem was to call setLabel with a component specific name for each dynamic FormComponent. -- From: Sergey Olefir solf.li...@gmail.com Sent: Wednesday, March 03, 2010 4:36 AM To: users@wicket.apache.org Subject: Re: FeedbackPanel for Dynamic Form I'm not 100% sure what exactly is your issue, but have you taken a look at subclasses of IFeedbackMessageFilter ? They allow filtering messages based on component instance, for example. You will have to use reuseItems=true in ListView though most likely. Brad Grier wrote: I've written a dynamic form engine which does its work using a ListView and Fragment subclasses representing the various form fields. Everything works great including saving and retrieving form information. Now that the fun is over, I've run into a problem adding validation. In the markup for the fragment subclasses, the wicket:id is always field. That's okay...until I try to add a FeebackPanel to the form to report validation errors. Since the identifier for every form field is the same, the messages displayed in the panel are useless. Any advice? -- View this message in context: http://old.nabble.com/FeedbackPanel-for-Dynamic-Form-tp27764535p27766528.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 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
