Announcement

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

    FilterBuilder assignment of operators for each FieldType is not working properly / 13.0-p20230304

    For "FieldDataSource" of "FilterBuilder",
    we are calling com.smartgwt.client.data.DataSource#setTypeOperators(com.smartgwt.client.types.FieldType, com.smartgwt.client.types.OperatorId[])
    to restrict the list of operators for each FieldType.

    Unfortunately, this doesn't seem to be working as expected.
    The operators drop-down is losing some of the assigned operators when changing field selection while the primary operation group is missing the "Match All", "Match Any", "Match None" entries.

    This is reproducible in version 13.0-p20230304

    Is this a bug or are we missing something?

    #2
    Hi there Elias,

    We can't tell just from this prose description of the issue. In general, yes, you can restrict or expand the operators for a given or for a given field type using setTypeOperators() and related APIs.

    If something isn't behaving as expected, could you maybe provide a code snippet that tries to restrict a given operator, and explain what you expected vs what actually happened?

    Comment


      #3
      You can use the attached files to reproduce the problem.

      The top level operators group is wrong
      Click image for larger version

Name:	TopLevelGroupIncorrect.PNG
Views:	102
Size:	9.6 KB
ID:	269793
      The assigned operators are not displayed properly
      Click image for larger version

Name:	AssignedOperatorsNotDisplayed.PNG
Views:	98
Size:	4.5 KB
ID:	269794
      The default operators are displayed properly
      Click image for larger version

Name:	DefaultOperatorsDisplayed.PNG
Views:	97
Size:	10.0 KB
ID:	269792
      Attached Files

      Comment


        #4
        Hi there Elias, it looks like you've built a system for retrieving the valid operators for a given field from the server, which is interesting. However, we can't actually run this code since it's based on a database we don't have.

        However, if there's a problem with our setTypeOperators() API, you should be able to demonstrate this with a much, much simpler approach: just a single Java file that calls that API, without doing any server queries or anything of the kind. That would make it clear that the API is not behaving according to its documentation, if that is indeed the problem.

        Can you please isolate the behavior here from your server code, and post a simple test case if you still think that setTypeOperators() is misbehaving?

        Comment


          #5
          There is no database, all the fields are produced by FieldTypeOperatorsDataSource server side class.

          The set of valid operators is defined on the client side, in FieldTypeOperators client side class.

          In our view, the API is not behaving according to its documentation.

          The most productive approach, for both of us, would be sharing with you our Maven project that reproduces the problem accurately.
          The files and screenshots I gave you came from the same Maven project.

          We will share this with you soon.
          Last edited by eliasbalasis; 9 Mar 2023, 14:43.

          Comment


            #6
            Hi Elias,

            Right below where you type in your post, you can see instructions for what constitutes a test case. Those instructions say not to provide a Maven test case, and explain why.

            It looks like you're concerned about just a client-side API, so, per the guidelines below, the expected test case in this situation would generally be just one .java file, showing an attempt to use the API and the unexpected result. We would not generally expect to also receive code that does a server request, and having this additional code makes it unclear whether the problem is really with a client-side API or just issues elsewhere.

            So, we definitely do not need a Maven-based test case and that is in fact moving in the wrong direction!

            Please let us know when you have an appropriate test case - if there's a problem here, we want to solve it!

            Comment


              #7
              Under special conditions when a problem is not reproducible otherwise, a Maven-based test case is the last option, as it has happened for us in case 268066.

              However, I accept that a client-server interaction does make the source of the problem unclear.

              I will transform the test case accordingly and send again soon.

              Comment


                #8
                As promised, you can find attached the transformed test case without server-side interactions.

                This should make the source of the problem clear.

                However, even though server-side interactions have been removed, the problematic behaviors have remained unchanged.

                This proves that the problem is most certainly with a client-side API.
                Attached Files

                Comment


                  #9
                  Hi Elias,

                  Thanks for the revised test case. This shows that there's an interaction between your settings and the defaults for operator visibility (operator.hidden), and we're looking at the best approach here - framework changes, or perhaps just clarified docs, or both.

                  However, a couple questions about your approach here:

                  1. you are trying to show the isNull operator, and not showing the isBlank operator. isBlank was created because typical end users don't immediately understand the distinction between a true "null" and the empty string (""), and isBlank covers both.

                  So we're not sure if you intentionally tried to switch back to isNull (presumably because of very sophisticated users) or just didn't realize that isBlank was available. For normal end users, we would recommend having isBlank available, and not showing isNull.



                  2. overall, can you tell us what you're trying to accomplish here - are you trying to expand options for very sophisticated users (e.g. we noticed you are trying to enable regexps) or trying to eliminate options that your server can't support, or a bit of both? This will help us figure out what framework changes might be indicated.

                  Comment


                    #10
                    Hello.

                    Overall our effort is driven by the need to explicitly reflect the server side semantics for each operator and field type so that our users can express the filters accurately.

                    For example, we could use isBlank and isNotBlank for TEXT type but we use isNull and isNotNull to signify presence or absence of the associated value which is conceptually different.

                    Even though most users would understand "isBlank" and "isNotBlank" as equivalent to "isNull" and "isNotNull" we do need to be explicit because our server implementation semantics are different and our users need to be exposed to this difference in order to express the filters accurately.

                    Similarly we implement certain operators for certain field types on our server-side, hence the need to limit the set of displayed operators by FieldType.
                    We are practically, as you correctly suspected, eliminating options that our server implementation is not supporting and allowing only options that are supported by our server implementation.

                    I hope this helps you.
                    Last edited by eliasbalasis; 11 Mar 2023, 08:31.

                    Comment


                      #11
                      Hi Elias,

                      Thanks for confirming - we've addressed the flaw underlying this misbehavior and you can try out the fix in today's builds, dated March 12 or later.

                      Please let us know if you see any other issues.

                      Comment


                        #12
                        The problem is still reproducible with 13.0-p20230312

                        Comment


                          #13
                          We see the issue, it's specific to fields from a fieldDataSource (fields from FilterBuilder.dataSource work as expected) - we'll update here when it's been fixed.

                          Comment


                            #14
                            The issue has been addressed and you can try out the fix in today's upcoming builds, dated March 14.

                            Comment


                              #15
                              13.0-p20230312 seems to be working.
                              The operators list is now populated as expected.

                              However, the top level operators group is still wrong.
                              Click image for larger version

Name:	Capture1.PNG
Views:	76
Size:	9.7 KB
ID:	269826
                              Last edited by eliasbalasis; 14 Mar 2023, 10:15. Reason: better screenshot

                              Comment

                              Working...
                              X