martin/static-mapper

[martinohansen]

This is a draft of my proposed way to solve the issues we've been seeing in various places including #10

An alternative solution could be to use the reflect package and allow the user complete control over the mappings. I tried to hack a bit on it but I could not get anything reasonable to work. I'd be very interested in seeing others' attempts at true dynamic mapping.

[martinohansen]

This would still mean static mapping between different banks in source code. Just Finland alone has close to 20 bank ids let alone the rest of SEPA area. I really don't wish for such a maintenance hurdle for you.

Besides, this also means that if there ever is a user who wants something different for a hard coded bank, it would not work for him/her.

@hpernu I updated the code slightly, please check again. To your point, firstly, I don't think this will be a maintenance hurdle on just me, it's an open-source project and the maintenance is fundamentally on every user as they see fit. But one does not exclude the other, we can have static mappings for some banks but strive to keep as many banks as possible in the default mapper, for as long as it's feasible.

By the looks of it, we can simply add additionalInformatin field into the already existing search for a Payee field.

[hpernu]

This would still mean static mapping between different banks in source code. Just Finland alone has close to 20 bank ids let alone the rest of SEPA area. I really don't wish for such a maintenance hurdle for you.
Besides, this also means that if there ever is a user who wants something different for a hard coded bank, it would not work for him/her.

@hpernu I updated the code slightly, please check again. To your point, firstly, I don't think this will be a maintenance hurdle on just me, it's an open-source project and the maintenance is fundamentally on every user as they see fit. But one does not exclude the other, we can have static mappings for some banks but strive to keep as many banks as possible in the default mapper, for as long as it's feasible.

By the looks of it, we can simply add additionalInformatin field into the already existing search for a Payee field.

Yes, I think so too. It would be fairly trivial to just put it as one of the options for payee source.
Although, I recommend either typing it correctly or shortening it to just something like 'info' .

When I initially implemented this feature, I'd never have guessed that additionalInformation field could have held just the actual payee. In all of my banks (five or so) it either contains the freeform message input by the payer in bank software or a collection of more verbose information (which is often too much) neither of which is useful as payee by itself.

[hpernu]

Tried this with my banks and it just works as previously.

So the changes look okay to me but please check the changes to READMEs.

[hpernu]

Seems okay although some of the README stuff still might be better but then documentation can always be improved.