Re-ordered targets for flasher.

[mikeller]

This moves the selection of Unified / legacy target from the board list into the version list:

This should address the main reason for user confusion, but there are a couple more things to be cleaned up and improved in the firmware flasher tab:

• remove the use of the global variables, stick option list related data into jQuery data;
• improve the 'Release info' display;
• add support for changeset ids for Unified Target configurations.

[Docteh]

remove the use of the global variables, stick option list related data into jQuery data;

Can we put a pin in that one? If we move away from jQuery we might need to rework it anyways. Embedding a bunch of data into the DOM seemed dirty to me.

[mikeller]

@Docteh:

Can we put a pin in that one? If we move away from jQuery we might need to rework it anyways.

After the experience I had reworking the existing code I'd rather keep the momentum going and clean this up a bit, lest somebody will have to reverse engineer the mess that it is now again next time we change something.

Embedding a bunch of data into the DOM seemed dirty to me.

It is not my preferred approach either, but:

• we are already doing it for the versions drop down - consistency makes working with the code easier;
• it is less 'dirty' than having a global variable that is driven by the contents of a drop down.

[McGiverGim]

To me is ok!!

[McGiverGim]

Not your code, but to me is a little strange continue supporting the RC versions and only starting with the RC1. But I suppose is needed to not break things...

[Docteh]

I can check tomorrow but at the time it seemed best. 4.1.0 is newer than 4.1.0-RC1 so if we specified 4.1.0 we wouldn't have had unified targets with any RC. Specifying something like gte 4.0.9999 would have worked but then it's not clear to the humans as to what is going on.

[mikeller]

@McGiverGim: This is not so much about 'supporting 4.1.0-RC1', but about making sure that we are not trying to use custom defaults with any (released) versions that do not support this. And 4.1.0-RC1 is the first released version to support custom defaults.

[McGiverGim]

Again not your code, but I prefer to add a class and not a style, to maintain it in the css files.

[mikeller]

@McGiverGim: I made it all classy now.

[Docteh]

This might be dumbassery on my end, but initial tab contents without a saved board might be worth a look.

First item under boards should be this key instead of blank

     "firmwareFlasherOptionLabelSelectBoard": {
        "message": "Choose a Board"
    },

[mikeller]

@Docteh: Well spotted, thanks for testing. Turns out I inadvertently removed some calls to i18n.localizePage(). Also, turns out that re-localising the entire page instead of getting and adding the localised messages is wasteful, so I removed it.

[Docteh]

Looks good to me

[Docteh]

Maybe 'Choose a Firmware Version' should be initially blanked out, to respect the way it worked before? Start from the top and work your way down is sensible enough for me.

[mikeller]

@Docteh:

Maybe 'Choose a Firmware Version' should be initially blanked out, to respect the way it worked before? Start from the top and work your way down is sensible enough for me.

Actually both texts are loaded from the beginning in the UI in master.
And I am not sure about this, to me an empty drop-down looks 'broken'. So if anything the version drop down should be 'Choose a Board first' or similar, and that is very much going out on a limb I think.

[Docteh]

Actually both texts are loaded from the beginning in the UI in master.

Yeah I've stared at this tab enough to misremember things.

If we get lots of complaints later on we could make "Choose a Board first" the second option

[mikeller]

@Docteh:

Yeah I've stared at this tab enough to misremember things.

You might have seen it - the use of i18n.localizePage() to translate the options resulted in the options being rendered empty first, and the translations being added with a bit of delay. But that's fixed now.