Re: Ajax Update failing because of model
On 03/03/2014 19:48, Sven Meier wrote: I can't think of a reason for this. A quickstart would help to identify the problem. Cheers - attempting to produce a quickstart I managed to identify much better what was actually happening and as you might expect it's not really a wicket problem at all. Plus ca change. The actual issue is that the use of my ajax component that is causing problems is on a form with only that component on it. (The different models were changing the way Wicket changed the page version numbers - which I had mistakenly assumed meant to no ajax update was happening). If I update the text field by entering some text and then moving the focus elsewhere, the ajax update works just fine. But if I enter the text and hit enter - implicit form submission takes place as per the defacto html standard. And because the ajax behaviour is on the control and not the form the page performs a full update, not an ajax update. I assume that the best way to handle that is to put an AjaxFormSubmitBehaviour on the form - and that then it will handle the form submission with ajax as well. But if there is a better way to capture the implicit form submission, I'd love to hear it! Matt Pennington. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Turning off one-pass-render for a single page
I have an application which needs to accept a POST request from an outside server, to confirm payment. I don't want to break the default wicket render strategy (REDIRECT_TO_BUFFER) which is serving to give the users a nicer experience than ONE_PASS_RENDER would, however, the external service is not happy with the 302, and keeps retrying until it gives up. Is there some sensible way that I can tell wicket to use ONE_PASS_RENDER for only the specific page that handles this request? Matt Pennington - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Reading
Hi I've got a small wicket app that is using paypal to take payments. On reciept of payment, paypal posts a notification back to the website. If I intercept this with a filter and look at the request parameters all the information I would expect is there, transaction details, item details etc. But the wicket page that I've got set up to process the post back can't see any parameters. Which is to say the PageParameters value appears to be empty even though I know there are parameters in the request header. Is this because wicket isn't translating the request parameters into PageParameters? I realize I can just write a servlet to catch and handle the post back, but I wondered if I was doing something wrong, or how I could get my wicket page to be able to access the information that is in the header of the request? Matt Pennington. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: [VOTE] Behavior of CheckBox With Respect to setRequired(true)
On 06/04/2011 16:53, James Carman wrote: As the voting stands right now, it looks like option 2 is the winner (I counted Matthew as +1 for option 1 even though he didn't really cast a vote, but his response indicated support for option 1): I was convinced by Igor's comments to change my mind if that helps at all (vote for option 2). But it's a pretty busy mailing list and I felt if I posted just to say Having thought about it, I now agree with eveyrone who is arguing for consistency of framework that would be unhelpful. I was hoping to just keep quiet and avoid drawing any more attention to the imbalance between the size of my ego and the size of my experience with Wicket. ;) Matt - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: [VOTE] Behavior of CheckBox With Respect to setRequired(true)
1. The current approach is correct, requiring a checkbox means requiring that it be checked. 2. A checkbox shouldn't be able to be required. You can't *not* provide a value (it's binary) for a checkbox, so therefore it always should satisfy the required requirement. (1) I can't think of any useful benefit to (2) but I *can* think of a very useful benefit for (1) The classic tick this box to indicate that you have read and agreed to sell us your soul EULA would be the obvious time to use a checkbox and setRequired(true) if it worked as per (1). - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: [VOTE] Behavior of CheckBox With Respect to setRequired(true)
On 01/04/2011 19:34, Igor Vaynberg wrote: that can be accomplished using a validator. Is that not true of all form components? Matt -igor On Fri, Apr 1, 2011 at 11:33 AM, Matthew Pennington m...@profounddecisions.co.uk wrote: 1. The current approach is correct, requiring a checkbox means requiring that it be checked. 2. A checkbox shouldn't be able to be required. You can't *not* provide a value (it's binary) for a checkbox, so therefore it always should satisfy the required requirement. (1) I can't think of any useful benefit to (2) but I *can* think of a very useful benefit for (1) The classic tick this box to indicate that you have read and agreed to sell us your soul EULA would be the obvious time to use a checkbox and setRequired(true) if it worked as per (1). - 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: Set all form fields to output markup id automatically
On 30/03/2011 19:44, Martin Grigorov wrote: @Bruno: this is interesting question. You should ask it in scala-users@. I think this should be possible with some implicit declaration. @Matthew: Do you use org.apache.wicket.markup.html.form.FormComponentLabel ? Going through the app and changing all the non-functioning plain html form labels to wicket FormComponentLabels is on my job list to do before it's finished! So yeah, I'm aware of it, but while that component helps reduce the coding burden it still means that every single form component now needs a second wicket component creating and adding to the form *just to make the html work the way you would expect it to work.* That is tedious and it's additional plumbing code just for the sake of making things work so it strikes me as inherently undesirable. Wicket is fantastic at keeping code out of the html, it just seems to fly in the face of that ethos that it then forces me to write the html labels in the code. Given that at some point in the processing cycle Wicket must be setting the ID of the form component labels, it seems a shame that it can't also detect any label that has a for attribute for the id it's altering and update the for attribute as well. I'm sure there are many good reasons why that wouldn't work but to my inexperienced mind it's a real pity! You'd still have the gotcha of discovering that Wicket was changing your ID values, but you'd never have to worry about keeping their attendant HTML labels in sync because Wicket could just do that for you? Matt - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Set all form fields to output markup id automatically
I personally would suggest *not* having that second line component.setMarkupId(component.getId()) there. Let Wicket generate the IDs for you so that they're all unique on a page. Your approach above breaks using two EmailAddressTextField (fake example class) components on the same page. Designers should use css class to style. An occasional ID that isn't attached to a Wicket component can also help (div surrounding content section, etc). The only problem with this argument is that ID fields are a part of the HTML syntax, via the for attribute of a html label... I've only recently started using wicket and I think it's *fantastic* but the only thing I don't like is the way it changes the ID value of elements. I'm sure it's necessary for the way Wicket works and I'm sure it's an issue that's been discussed by wicket people before, but it came as a pretty nasty surprise to me when I discovered it half way through writing my first application (it doesn't seem to me to be very well flagged up for such a major issue). Obviously I'm a newb, but the the only solution I am aware of to the problem is to rewrite every label on every form as a wicket component. That seems to run against the wicket philosophy of keeping the html and the code separate. I realize nothing in life is perfect, but so far it's the *only* thing about wicket that *isn't* perfect... :) - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
