...
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.