How about changing the widget setup box to only display āprependā and āappendā boxes, if/when it loads an existing feedvalue (recognised by the ābefore/afterā field) it uses the ābefore/afterā field to populate either the āprependā or āappendā box with the existing unit text (leaving the other box blank). And on save it removes the 2 old fields and saves the 2 new fields. So only on editing and saving an existing feedvalue is the change made (we can recommend users resave their widgets anyway) . Old feedvalues remain as is until edited/saved and new feedvalues get the new fields only. This would keep backwards compatibility and only keep 2 fields (for this job), either position and unit or prepend and append, the changes would happen behind the scenes without the user having to do anything.
Likewise in the dashboard view, the feed value would display one of 2 ways depending in whether it has a before/after field, ie it still uses āappendā and āprependā variables, but they are populated when the dash loads by either using the before/after to populate one of those vars, or it populates them directly if it has āappendā and āprependā args.
Do you have an example feedvalue config? Iām guessing blind here as I cannot recall looking at these that closely, I just know itās a JSON object, not a database table
Its not easy to control which options are shown in the editor, but it is relatively straight forward to render widgets with old attributes if they are present and the new ones are not configured. Iāve now done this for the feedvalue widget giving the prepend and append options, pushed to the master branch: backwards compatibility of units Ā· emoncms/dashboard@05ea5a1 Ā· GitHub
goes without saying, options that donāt effect existing dashboards are the way.
Thought. could have a new āfeedvalue2ā and leave the old one with minor changes.
@TrystanLea sorry but I realized one thing else that would be useful is a thousands separator option (commas or spaces), it would make big numbers much easier to readā¦
Also I am using the .org platform so just want to know how long changes like these take to migrate to the online version?
Noting that a dot is commonly used in Europe as the thousands separator, and the comma as the decimal marker.
Options for a thousands separator would be pleasant.
Not all are using this format. We have a different format #ā###,## here in Switzerland. As someone working at a Swiss bank I have to deal with this annoyance every day
If you want to do it correctly I would suggest the ISO country code (2digits is enough) and the values and formats marked here on this page: https://www.thefinancials.com/Default.aspx?SubSectionID=curformat
This way, the format is dependent on the currency and always correct.
I did write ācommonlyā, not āuniversallyā and especially as your link shows all the Euro currencies using #,###.##
Is the same format always used for non-currency numbers? Iāve very often seen #.###,### format used in Engineering documents from continental Europe - though my experience is largely limited to German sources.
@TrystanLea are any of the above mentioned thousand separators possible? Will these updates be integrated into the .org platform?
Emoncms.org is now running the latest version of the Dashboard module. I will look into the thousands separator option, I have created an issue for it here number formatting: thousands separator option Ā· Issue #170 Ā· emoncms/dashboard Ā· GitHub