Transaction support in UIs

[Milan Babuskov]

Anastasios Hatzis wrote:
> I guess that some of you also build user-interfaces for a 
> transaction-sensitive database in the one ore other project?

I have, it's my "day job".

> Example: You have a Foo class (or table) with the attribute (column) 
> name. You want the end-user to be able to edit any Foo object (or 
> record). So there is some "Edit Foo" dialog with a text entry widget for 
> the name, a "Save" button, and a "Cancel" button, yes?

Yes.

> But what about transactions spanning multipe calls on a single object, 

I usually put this into stored procedure on server. Simplifies the 
client code a lot, and allows me to combine web and desktop applications 
with less duplication of code.

> calls on multiple objects (including creating or linking them), or even 
> on objects of multiple components (databases)? How is it transparent for 
> an end-user which of the activities made in the UI are in a single 
> transaction or in different ones?

Users don't care. They just want to click and have their data safely stored.

> Do you put anything inside a 
> transaction into a single dialog?

Depends on the amount of data and application itself. For web apps I do 
have multi-dialog stuff and I either pass the data via hidden variables 
or store as variable in user session on the server (PHP). For 
GUI/desktop apps. I usually have a data structure that holds the info 
until user typed everything. I didn't find tabs too useful, but if you 
have a lot of data for a single thing, perhaps a multipage dialog 
(wxWizard) is appropriate.

One of the approaches I also used is to have small dialogs to enter some 
details. For example, if you type some document which has shipping info, 
on the main dialog I only shows the city name (usually read-only), and 
user can click the "Details" button which opens a small dialog where he 
can enter the complete address, country, etc. When he clicks on "Save" 
the small dialog closes and data is stored in some in-memory object. 
When all data is entered for entire document, the user clicks final 
"Save" on the main dialog and all the helper objects data gets saved in 
a single transaction.

Whatever you choose, keeping short transactions is a very good idea, 
esp. in multi-user environment.


-- 
Milan Babuskov
http://www.guacosoft.com
http://www.flamerobin.org