[jmoney-devel] GNUCash file format

[Nigel W. <ja...@mi...>]

Olivier,

 

None of new, open, save, or save as work for me.  I have been testing
against accounts in my SQL database, so I don't need them, but this is
serious so at some time I will get around to debugging it to see where
and why the Eclipse RCP is dropping the menu items.

 

I agree that it would be much better if the GNUCash format were the
datastore itself, rather than a means of importing data into and
exporting data from a datastore.  JMoney loads the datastore that was
open when JMoney lasted closed, so you would not have to create a new
session and import data each time.  However, this is not trivial to do
properly.  What I suggest is that I split the serializeddatastore
plug-in into two.  One plug-in would be the base plug-in for any
datastore where the entire data is read into memory from a file.  The
plug-in would add the 'new', 'open', 'save', and 'save as' commands.
That plug-in would define an extension point to which other plug-ins can
add file format implementations.  The extension point would require a
class be provided that can do the loading of the data and the saving
back to file.  The extension point would also provide the file
extension.  When the 'open' or 'save as' commands are run, the file
dialog box would show as file types all extensions supported by
plug-ins.

 

There are a few complications to consider:

1.	What happens if more than one file format has the same file
extension.  This is likely if the extension is xml.  One solution would
be to try reading the file using each plug-in until one is successful.
2.	The existing serializeddatastore and jdbcdatastore plug-ins are
capable of storing any additional properties or property sets added by
plug-ins.  I don't think this is possible with the GNU Cash format.
Maybe we can put lots of XML inside one of the GNU Cash text fields, but
that would look confusing in GNU Cash.  If there is no solution then
data may be lost.  Perhaps we could figure out a way of warning the user
about data loss when the file is saved.  Better yet would be if we could
warn the user at the time data is entered that cannot be saved.
3.	The API for modifying an existing datastore is different from
the API for creating a new datastore.  Ultimately switching the GNU cash
code to the other API will probably be an improvement, but it will
involve some work.

 

Nigel

 

-----Original Message-----
From: Olivier Faucheux [mailto:ol...@fa...] 
Sent: Saturday, January 29, 2005 12:13 AM
To: wes...@us...
Subject: Re: [jmoney-devel] replacing CellEditor classes

 

Ok Nigel, I don't change anything in this direction anymore. I had the
same problem as you with the sevral accounts.

 

An other question: I can't save my session with the normal "save"
method: I become a file (text.jmx), but can't read it back with the
"open" item. Does it work for you?

 

As you perhaps have seen, I implemented the export as GnuCash XML File.
I works well : I can export and re-import under JMoney. My aim is to
propose the Gnucash XML format as a save-method: I can't accept to have
my dataes stored in a binary format: if sthg get wrong, everything is
lost.

 

The better will be an option, so that the user can choose between the
save format he wants use. But I would like know at first if the current
"save" method really runs...

 

 

Olivier

----- Original Message ----- 

From: Nigel Westbury

To: jmo...@li... 

Sent: Friday, January 28, 2005 6:44 PM

Subject: [jmoney-devel] replacing CellEditor classes

 

Olivier,

 

Thanks for completing the implementation of the cell editor for account
and currency selection.

 

On trying out the account selection, it became obvious that the
combo-box implementation of the cell editor will be inadequate.  It only
allows me to type a single letter.  If I type the first two letters of
an account name, it jumps to accounts starting with the second letter!
As I have over 400 accounts, this made account selection very slow.

 

However, I had noticed in the tree table example, which I had used while
implementing the tree table, that editing was not done using CellEditor
classes but was implemented by intercepting the MouseDown event and
creating the control.  This approach gives us a lot more control.  

 

It allows different control types in the same column for different rows.

It allows a wider selection of controls.

It avoids the need to have two sets of methods into the PropertyAccessor
object for creating and managing property controls (one for normal
Control objects and one for CellEditor objects).

 

I am in the process of converting the Table and TreeTable
implementations, and it is working well.  I have even been able to
incorporate the date picker from the swtcalendar SourceForge project,
which I do not believe would have been possible using the CellEditor
classes.  It might be a day or two before I am ready to commit the
changes, but I thought I would let you know now so you do not waste time
on getting the CellEditor code completed.

 

Nigel Westbury