Announcement

Collapse
No announcement yet.
X
  • Filter
  • Time
Clear All
new posts

    RadioGroupItem sorts the value Map according to the Keys in value map

    We are using SmartClient Version: v9.0p_2013-10-17/PowerEdition Deployment (built 2013-10-17).

    We have a radio button group where we want to display its values in a particular order so we pass the value map based on some ordering logic. But its key is different from that sort order.

    for e.g.:
    We have following fruits-

    ID Name Sort_Order
    1 Apple 1
    4 Mango 2
    3 Banana 3
    2 Kiwi 4

    This is happening on Mozilla, Chrome and not on IE8

    We want to display these fruits as per the sort order given. Thus i create a LinkedHashMap in that order. But when the rdio group is rendered, it always displays the radio items sorted by its ID which is the key in the map.
    Here is the sample code snippet :

    Code:
    public void onModuleLoad() {
        VLayout vlayout = new VLayout();
        DynamicForm form= new DynamicForm();
        vlayout.addMember(form);
    
        RadioGroupItem radioBtn = new RadioGroupItem("Fruits", "Fruits");
        LinkedHashMap<Integer, String> map = new LinkedHashMap<Integer, String>();
            map.put(1, "Apple");
            map.put(4, "Mango");
            map.put(3, "Banana");
            map.put(2, "Kiwi");
            radioBtn.setValueMap(map);
    
       radioBtn.setDefaultValue(1);
       form.setItems(radioBtn);
       vlayout.draw();
    }
    Result is(sorted by the keys):
    o Apple o Kiwi o Banana o Mango

    We want the linked hash map order to be maintained when the radio group is drawn which is
    o Apple o Mango o Banana o Kiwi
    Last edited by mchoudhary; 13 Nov 2013, 02:18. Reason: Added browser specific behavior

    #2
    This is an issue with Chrome and IE where JavaScriptObjects that use property names that are parsable as numbers will force the order of iteration to numeric sequence.

    The workaround is to use property names that are not numeric (for example, "1A", "2A" etc).

    Comment


      #3
      In my case the key is the primary key to a record in a database. We can't really just change the IDs.

      Comment


        #4
        You don't need to change the IDs in the database, but to work around this Chrome issue, you'll need to either add a prefix/suffix that you automatically strip off in your server code, or use optionDataSource instead of valueMaps.

        Comment


          #5
          Wouldn't it be less taxing on SmartGWT's users if the order was stored in the object to avoid this problem?

          Everything that I have read indicates that the key order in a JavaScript Object is not guaranteed to be in the order at which they are added or defined. Wouldn't that mean SmartGWT is misusing the object? Meaning this is no different than if I, as a java developer, was to use a HashMap and expect that the values stay in the order that I add them. A HashMap does not guarantee order so I can't blame the HashMap when the values are read out in a different order than they are added.

          Thanks for your response,
          Pat

          Comment


            #6
            Actually, all browsers are consistent about iteration order *except* for keys that happen to be parsable as numbers (a very weird behavior), and all browsers were also consistent about iteration order of numeric keys until Chrome made the order random a couple of years ago. The standards bodies have not decided what to standardize yet.

            Since the current situation is obviously very surprising and framework-level workarounds would have performance consequences and some complexity consequences that would bubble through to users, we are recommending use of optionDataSource or non-numeric keys until the standards issue is resolved.

            Comment

            Working...
            X