Johan, But isn't wicket _very_ different in that it keeps a representation of the page on the server? So in frameworks other than Wicket, Echo and Tapestry if the request cycle fails the page state can't get contaminated?
Cheers Sam Johan Compagner wrote: > > so you want to have the commit cylce around the request not the response > (so in onBeforeRender() of a page the commit (or rollback) should be done > so > that all the data that is used in the response is valid) > > But i guess with a filter (session in view and the sort) around what ever > framework you use, you have these problems all the time.. > > johan > > > On Jan 24, 2008 10:32 AM, Sam Hough <[EMAIL PROTECTED]> wrote: > >> >> Hello Johan, >> >> The simplest case I can think of is the one where the user clicks to >> create >> a new record and I want to put a link in the page to that new record. As >> I >> understand it I need to be careful not to add the link to the page until >> after the commit was successful. If there was an error and the user >> managed >> to load that page again I don't want them linking to an object that >> wasn't >> created. >> >> We are currently using pretty fine grained interactions with the model so >> it >> would be quite easy to forget and modify the page too early when the db >> transaction might be rolled back. >> >> Cheers >> >> Sam >> >> >> >> Johan Compagner wrote: >> > >> > So you are worried about double submit, when using backbutton, of the >> > same page that has invalid data? >> > But if that happens then the second time has the same error as the >> first >> > time. >> > >> > On 1/24/08, Sam Hough <[EMAIL PROTECTED]> wrote: >> >> >> >> Igor, >> >> >> >> Am I at least correct that we shouldn't only commit at the end of >> request >> >> processing as you might in struts? (because I need to know if the >> commit >> >> was >> >> good before updating the page) >> >> >> >> I'm not really saying that you can't safely handle transactions and >> page >> >> state in Wicket just sanity checking that I need to take more care? eg >> If >> >> calling a method that may fail I shouldn't pass an argument that is >> >> attached >> >> to the page that might be modified by that method before the commit >> >> works? >> >> >> >> I take your point that quite often we would just show the user an >> error >> >> page >> >> but assuming we get the back button to work properly I think I need to >> >> ensure the server side page is in a valid state. >> >> >> >> Thanks for the tip about Spring annotations, we were just using a >> single >> >> commit at the end of the request. >> >> >> >> Cheers >> >> >> >> Sam >> >> -- >> >> View this message in context: >> >> http://www.nabble.com/db-transaction-boundary-tp15042959p15060686.html >> >> 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/db-transaction-boundary-tp15042959p15061342.html >> 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/db-transaction-boundary-tp15042959p15061897.html Sent from the Wicket - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
