> -----Original Message----- > From: Keith Bacon [mailto:[EMAIL PROTECTED]] > Sent: donderdag 13 december 2001 12:03 > To: Struts Users Mailing List > Subject: RE: How do you pass a data object for editing? > > > Tom, > In that case as you are doing now is the best way. > Maybe store the key on the form so you can check the > key on the incoming form matches the key of the data > held in the session (to guard against bugs & hacking). > > Then (big pain) - before updating check the data on > the DB is the same as what you originally saved in the > session (guard against intervening updates (optimistic > locking I think they call this)). > This involves a lot of code!
I once learned a trick that simplifies this process a lot: in your DB, add a field "VERSION". On a select, you save the VERSION. On update, you say UPDATE mytable SET version=<newversion> [and other fields] WHERE [criteria] AND VERSION=<oldversion> where <oldversion> is the version you saved, and <newversion>=<oldversion>+1. So you don't have to check against all fields, only one dedicated one. > --- > There is another way which I prefer - but not so often > used. > eg. Opening a bank account online involves many forms. > On your customer & account tables have a status field. > Values:- > INCO - Incomplete data. > ACTV - Active > BLKD - Blocked > DEL - Deleted > Each form writes the data to the DB as INCO indicating > data from a multi-form interaction. > After all forms are complete final validation is done > & the status set to ACTV. > Most functions treat INCO the same as DEL - ie. ignore > it - the INCO value isn't a lot extra to add. > > Advantage - in a complex long interaction every submit > saves data on the DB - so lost sessions, internet > problems don't lose the users data. > > Disadvantage - possibly large amounts of INCO data > from people messing about - extra hits on database. Another disadvantage I see: if one of the fields the user has to enter is (part of) the primary key, you won't be able to store it until he fills it out. > Any use? Stored in my "patterns to remember" memory in any case. Thanks. tomK > Keith > > > --- "Tom Klaasen (TeleRelay)" > <[EMAIL PROTECTED]> wrote: > > But what if you're crossing request boundaries (i.e. > > user edits form, > > presses "edit", has to review her data, presses > > "save")? You'll have to > > keep the information in the session AFAICS. > > > > Please correct me if I'm wrong. It would simplify my > > life a lot :) > > > > tomK > > > > > -----Original Message----- > > > From: Keith Bacon > > [mailto:[EMAIL PROTECTED]] > > > Sent: donderdag 13 december 2001 10:41 > > > To: Struts Users Mailing List > > > Subject: RE: How do you pass a data object for > > editing? > > > > > > > > > I agree with Ryan. An old rule from way back:- > > > > > > Pass Keys Round Not Data > > > > > > It's simpler to only keep keys across user > > > interactions (either stored on the form or in the > > > session). Otherwise you have 3 versions of data > > > 1 - what's on the database. > > > 2 - what you've saved in the session (or on the > > form) > > > 3 - new values coming in from the form > > > > > > Not having the 2nd set of data is a big > > > simplification. Some might say re-reading the > > database > > > more frequently is inefficient. ie. Your database > > > caching is less efficient than your server's > > caching > > > of session info. Maybe - but can serializing data > > to > > > the client form be faster than you DB?. > > > > > > Keith. > > > > > > --- Stephen Owens <[EMAIL PROTECTED]> wrote: > > > > Ryan, > > > > > > > > I usually just discard the data object, other > > than > > > > properties on the > > > > form, either displayed or hidden, that I need to > > > > identify it or populate > > > > it. Then I reload it, update it, and finally > > update > > > > the DB when/if the > > > > form is submitted. > > > > > > > > -----Original Message----- > > > > From: Ryan Cornia [mailto:[EMAIL PROTECTED]] > > > > Sent: Wednesday, December 12, 2001 4:36 PM > > > > To: [EMAIL PROTECTED] > > > > Subject: How do you pass a data object for > > editing? > > > > > > > > > > > > I'm interested in finding out how other people > > are > > > > passing data objects > > > > between requests for updating. > > > > > > > > For instance - > > > > > > > > User clicks "Edit Record" > > > > I load the data object from the database, copy > > the > > > > properties to the > > > > form, and put the data object in the session. > > > > When the users presses save on the form, I get > > the > > > > data object from the > > > > session, try and do a consistency check to make > > sure > > > > the key fields > > > > match what is on the form, and do the update. > > > > > > > > Is there a way to pass the data object with the > > > > form? Maybe via > > > > serialization? That would keep it out of the > > > > session, and remove the > > > > consistency check. > > > > > > > > Thanks, > > > > Ryan > > > > > > > > -- > > > > To unsubscribe, e-mail: > > > > > > <mailto:[EMAIL PROTECTED]> > > > > For additional commands, e-mail: > > > > <mailto:[EMAIL PROTECTED]> > > > > > > > > > > > > > __________________________________________________ > > > Do You Yahoo!? > > > Check out Yahoo! Shopping and Yahoo! Auctions for > > all of > > > your unique holiday gifts! Buy at > > http://shopping.yahoo.com > > > or bid at http://auctions.yahoo.com > > > > > > -- > > > To unsubscribe, e-mail: > > > <mailto:struts-user-> > > [EMAIL PROTECTED]> > > > For > > > additional commands, > > > e-mail: > > <mailto:[EMAIL PROTECTED]> > > > > > > > > > > -- > > To unsubscribe, e-mail: > > <mailto:[EMAIL PROTECTED]> > > For additional commands, e-mail: > > <mailto:[EMAIL PROTECTED]> > > > > > __________________________________________________ > Do You Yahoo!? > Check out Yahoo! Shopping and Yahoo! Auctions for all of > your unique holiday gifts! Buy at http://shopping.yahoo.com > or bid at http://auctions.yahoo.com > > -- > To unsubscribe, e-mail: > <mailto:struts-user-> [EMAIL PROTECTED]> > For > additional commands, > e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
