Announcement

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

    FieldOperatorCustomizer in FilterBuilder does not work when using FieldDataSource

    Hi,

    We are using customized FilterBuilder to build criterias. There seems to be an issue when configuring the FilterBuilder to use a data source for fields and at the same time, overriding setFieldOperatorCustomizer to provide operators for these fields. The select item used to choose the operator gets stuck with incorrect operators when changing the field in the criteria.

    We've debugged this a bit and it seems that the problem might lie in the logic how SelectItem's "updateValueMap" function determines values as valid or not: When the optionDataSource for the item is set, it accepts all values as valid and this results in wrong operators in the item.

    Reproducible with the following code. Run the code, change the field from "field a" to "field b" and vice-versa and observe that the operator selector gets invalid values stuck from time to time.

    Code:
            viewport = new VLayout();
            viewport.setWidth100();
            viewport.setHeight100();
    
            FilterBuilder fb = new FilterBuilder();
            fb.setRetainValuesAcrossFields(false);
    
            DataSource fds = new DataSource();
            Record a = new Record();
            a.setAttribute("name", "a");
            a.setAttribute("title", "field a");
            a.setAttribute("type", "text");
            Record b = new Record();
            b.setAttribute("name", "b");
            b.setAttribute("title", "field b");
            b.setAttribute("type", "text");
            fds.setTestData(a, b);
            fds.setClientOnly(true);
    
            fb.setFieldDataSource(fds);
            fb.setFieldOperatorCustomizer(new FieldOperatorCustomizer() {
                @Override
                public OperatorId[] getFieldOperators(String fieldName, OperatorId[] defaultOperators, FilterBuilder filterBuilder) {
                    if("a".equals(fieldName)) {
                        return new OperatorId[] { OperatorId.EQUALS, OperatorId.NOT_EQUAL };
                    } else if("b".equals(fieldName)) {
                        return new OperatorId[] { OperatorId.IN_SET, OperatorId.NOT_IN_SET };
                    }
                    return defaultOperators;
                }
            });
    
            viewport.addMember(fb);
            viewport.draw();
    Using SmartGWT 6.1p (v11.1p_2018-04-23/LGPL Development Only (built 2018-04-23))

    #2
    This has been fixed for builds dated May 3 and later.

    Comment


      #3
      We are still experiencing this issue with 6.1p / 11.1p 2018-05-14 build. Is the fix incorporated to this branch?

      Comment


        #4
        Yes, it was - we just retested your sample as-is against latest 6.1 and we see no issues - we can switch between the two fields many times and both fields retain their expected 2 entries.

        Note also that this issue was caused by a bug in the underlying SmartClient code and we're seeing it fixed there also.

        Is there something more that needs to be done to reproduce?

        Comment


          #5
          We'll investigate further but we still see this issue in our application code. We'll try to debug further and see if the test case needs refining.

          Comment


            #6
            Sorry, this was a false positive. We found some old legacy JSNI-based patches in our code which we had for trying to go around the original issue with operators. By removing these patches your fix works correctly.

            Comment

            Working...
            X