Ability to load additional CSV readers at runtime

[GoogleCodeExporter]

Imagine the situation where someones develops a new reader (i.e. CSV
parser) using the abstract class *TransactionReader*.

Currently all available readers are *hard-coded* into TransactionReader, so
that one can not use a new CSV reader until mdcsvimporter is compiled and
deployed again.

Thus, do you think it should be possible to load at runtime JAR libraries
in the classpath containing additional readers (i.e. extending
TransactionReader)?

Original issue reported on code.google.com by rodrigo....@gmail.com on 11 Apr 2010 at 11:47

[GoogleCodeExporter]

Plug-in for plug-in? :-) Interesting.

In theory it is possible, and should not be too hard. However, at this stage I
believe it is more important to keep the codebase flexible. Both because I had 
to
significantly refactor the code including base TransactionReader, and also 
because
possibly significant changes will be required moving to Moneydance 2010.

Allowing plug-ins would mean introducing innertia that will stop me from 
offering
people flexibility. Once we get to (if we get to) a dozen or more formats, then 
the
work of refactoring all readers will become too hard, and properly fixing the 
base
class will be required. Only then I think it will yield big benefits.

If you wish to contribute any reader, you are most welcome to. You can even 
fork and
make your own version of the plugin. I really do not mind (plus it is quite 
possible
under LGPL). My point is, it's a small helper, not a serious project we should 
spend
days labouring on. :-) I think we're at 10 or so users if so... I just wanted to
share what I had to do for myself.

Original comment by Jovanovi...@gmail.com on 12 Apr 2010 at 3:13

[GoogleCodeExporter]

Miki:
Would it be possible to leverage the Text File Importer GUI?  It is rather 
elegant 
to be able to tell the tool to map delimited "columns" to Moneydance fields, 
including the option to ignore certain fields.

Perhaps this GUI could be used to "memorize" unrecognized mappings and add them 
to 
the existing labeling system using an external text file as the storage 
mechanism.

Thank you,

- Brad

Original comment by Fuzzy.Ch...@gmail.com on 14 Apr 2010 at 6:10

[GoogleCodeExporter]

I see where you are coming from. When I started this project I had the same 
idea. It
actually appeals to the geek in me. :-) You know, being able to tweak the 
import and
handle any format...

However then I examined couple of formats. In some, you have a plain "amount" 
field,
which you convert to float. In another I saw two columns, one credit one debit, 
both
values positive but different meaning depending on column. Other changes as 
well. For
example how do I create a unique transaction ID, which Moneydance uses to 
identify
already imported transactions. I wont go into too much detail. But it was clear 
to me
that the UI would have to be more complicated then simple match column to 
property.
It would be a simple graphical programming language. Thus complicated for your
non-programmer types. In addition, how would I handle adding more functionality 
in
the future, new meaning for the column, new operation? I mean how would I 
preserve
the settings users who used old version use?

Any way, as you can see, so many questions. Then I thought about this approach. 
Yes,
not elegant in the geeky sense, but actually think about it, you select a file, 
it
detects the format, date, nothing for you to do. In addition, the user knows 
that
someone else has actually tried this if it already exists in the menu.

It's just a design choice.

Let me ask you, is there a particular reason you wish more formats? All people I
spoke to had only a single CSV format they needed. I would be surprised if 
adding the
format you need is hard.

Also, as a disclaimer, I come from the Mac background. Since switching from 
Windows I
learned to appreciate the "less choice" approach. In everyday work, I realised 
I did
not need all that "control" I had while I hacked Windows to death.

Regards,

Miki.

Original comment by Jovanovi...@gmail.com on 14 Apr 2010 at 5:29

[GoogleCodeExporter]

Hi,

I don't know if you have looked here lately, but I just looked at your issue 
now myself and think that what I did will help with what you want. See issue # 
10 (and #11). There is a new beta 15.5

Stan Towianski

Original comment by stashu....@gmail.com on 2 Nov 2011 at 3:17

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

Unless you think this is still needed since I created all the custom Reader 
code, I will close this at some point and call it fixed, ok?

Original comment by stashu....@gmail.com on 28 Jan 2012 at 8:48

[GoogleCodeExporter]

Original comment by stashu....@gmail.com on 30 Aug 2014 at 8:28

• Changed state: Done