if the rendering of the page (the response phase) always uses a committed transaction then that wouldn't happen
But if a commit fails, shouldn't you report that to the user anyway?? johan On Jan 24, 2008 10:59 AM, Sam Hough <[EMAIL PROTECTED]> wrote: > > 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] > >
