re-call and client transactions

re-call is more flexible than is visible in the example. re-store does not depend on re-call.

re-call creates client transactions for each form the user opens. This, however, is just the default behavior for what programmers typically want, not a requirement that is hard-coded into re-call. The programmer has a lot of control over when client transactions are created, even with very little extra work. What's more, re-store is completely independent from re-call and does not know anything about it. re-motion applications that use re-store's client transactions, but have no web interface, do exist – our own PhoneBook.Sample application is a small example for this. In the wild, such applications typically migrate data or generate reports, use client transactions in a manner very similar to our PhoneBook.Sample application.

Both re-call and re-store give you much more control over transactions than visible in the example.

User interface geeks will sneer at our design of waiting with the update of the fax number until the entire stack of forms has been carried off by Miss Quackfaster. Why not store it right away? Doesn't re-call or re-store pretty much suck, UI-wise? The answer is: the choice, the design, is all yours, dear UI-programmer. OF COURSE you can create a new root transaction instead of a sub-transaction for the fax form. Then you can store the fax number right away when Miss Quackfaster clicks Save. This would be more pleasant for her, but much less pleasant for the author who wants to illustrate units of work, root transactions and sub-transactions. Miss Quackfaster is imaginary, while the author is not. We leave a more convenient enterprise resource planning system as an exercise for the user, but will return to usability issues later.