Re: [jmoney-devel] the new account entries panel

[Johann G. <jo...@gy...>]

Nigel,

> Your idea solves this.  I assume your intention is that the account
> properties page appears as a tab at the bottom.  Allowing reports etc.
> to remain open while viewing accounts will be a big advantage.

This is exactly my idea. I plan to provide an extension point so that 
contributors can add their own tabs to a capital account editor and so 
on. What I don't know until know is how to cope with the "pages" 
extension point. I might have to change it to adapt to the new concept.

> Somehow I feel that adding or modifying one accounting transaction
> should be one database transaction.  I have no argument as to why that
> should be so, except this is the example always used when introducing
> database transactions.  On the other hand, there may be situations 
> where
> multiple accounting transactions must be taken together and it is 
> better
> to put them into a single database transaction.

Let's have a look at the implications:

1) accounting transaction == database transaction

As you already stated, the old JMoney GUI doesn't support accounting 
transactions since there is no "Commit" button. One could solve this by 
providing a modal entry edit dialog where the "OK" would be the commit 
operation. That way, a user must first select the entry from the table, 
click the "Edit..." button, and confirm his changes with "OK". 
Personally, I don't like modal dialogs but they would solve the issue. 
The major disadvantage is that it is not efficient for experienced 
users and one loses the browsing capability: since the dialog must be 
modal to support transactions one cannot switch to another account.

> In the usual open-save-close lifecycle, a file is the item being 
> edited,
> and each file contains separate data.  However, the list of entries in
> an account are not independent.  A transaction may have entries in more
> than one account, and edit conflicts may occur when the same 
> transaction
> is edited from two different accounts.  I have been thinking for a 
> while
> that we may need support for object locks, with edit controls being
> disabled when someone else has an object locked.  However, if many
> transaction modifications are left uncommitted in an account entries
> panel then the potential for locked transactions in other panels
> substantially increases.

2) accounting transacion != database transaction

Having a "flat" UI allows browsing very easily. It is, however, 
complicated to implement because we really would need object locks and 
so on.

Yet another idea: What about forcing the user to save/commit an account 
when he wants to switch to another account? If a specific account 
editor loses the focus, the user would be prompted to save or discard 
the changes. This approach would avoid modal dialogs and object locks. 
Of course, the browsing capability would be constrained but this could 
be solved by providing an optional auto-commit when an account editor 
loses his focus.

> If we change to the open-save-close lifecycle of editors (one database
> transaction is one save), then I agree.  I had been thinking about how
> we can hide partial transactions from others.  Now you are thinking
> about how to show them.  Should we hide them or should we show them?  
> In
> my view, other tabs at the bottom should see un-committed changes but
> the other tabs at the top should not.  This is how the plug-in editor
> works.

In that case, they shouldn't be shown, you're right.

> On the other hand, if a database transaction is the smallest change 
> that
> keeps the database valid, then it does not make sense to allow an 
> 'undo'
> change to be smaller than the database transaction.

In my opinion, an undo operation smaller than a database transaction is 
not a big problem: If it leads to an inconsistent state the user simply 
can't safe (commit) the account. Perhaps we are talking about different 
things. Do you have a concrete example for JMoney where an operation is 
smaller than a database transaction?

Johann