There has been a long thread about currency fields in webservice calls. The philisophy right now is that a developer should format the currency fields to a user format and send them in like that. While that seems like to correct approach for 'new inputs', where totally fresh data is input into the application, it creates more work for the webservice developer when sending existing data back into the application. This is because you receive the data in DB format, then you'd have to format it to fit your needs, taking into account the currency format of the user your webservice application uses and send it back user-formatted. If your application, like mine, uses the entire record (as it came from a 'Retrieve' call), alters some fields that have nothing to do with currency fields and sends back the entire record with only the modifications and no further formatting, you'll get unexpected behaviour because coreBOS expects the data to be user-formatted and since I didn't alter the currency fields at all and just send them back as they were they get multiplied by a million (6 decimals, right?).
While I understand this choice and can understand the use-cases in which such behaviour could be desireable, I think it can also create some extra work for the developer on the client side in certain cases. Without going into this debate, that has pro's and cons and where arguments can be made on either side, I'd like to investigate a more practical solution.
The 'convertToDBFormat' method of the CurrencyField class has the option to skip the conversion and thus just leave the value as it is. What if we implemented a 'special field' in the 'Update' and 'Revise' Webservice methods (something like '__cbws_skipcurrencyconversion') that tells the webservice methods to set this flag? This way, when you develop a client application you can safely send your fields as you received them without having to worry about converting the currency fields. This would of course mean you'd have to send ALL fields back in DB format, but I think having the choice to select one behaviour or the other would be nice.
UPDATE
Ah, I see I've misread the 'skipConversion' flag. It doesn't specify whether conversion happens to DB format, it specifies whether conversion to dollars will be done....
UPDATE 2
I created a PR that allows a client to set a flag that prevents DB conversion on the currency fields on productlines.
While I understand this choice and can understand the use-cases in which such behaviour could be desireable, I think it can also create some extra work for the developer on the client side in certain cases. Without going into this debate, that has pro's and cons and where arguments can be made on either side, I'd like to investigate a more practical solution.
The 'convertToDBFormat' method of the CurrencyField class has the option to skip the conversion and thus just leave the value as it is. What if we implemented a 'special field' in the 'Update' and 'Revise' Webservice methods (something like '__cbws_skipcurrencyconversion') that tells the webservice methods to set this flag? This way, when you develop a client application you can safely send your fields as you received them without having to worry about converting the currency fields. This would of course mean you'd have to send ALL fields back in DB format, but I think having the choice to select one behaviour or the other would be nice.
UPDATE
Ah, I see I've misread the 'skipConversion' flag. It doesn't specify whether conversion happens to DB format, it specifies whether conversion to dollars will be done....
UPDATE 2
I created a PR that allows a client to set a flag that prevents DB conversion on the currency fields on productlines.