Unplanned
Last Updated: 07 Sep 2020 07:45 by ADMIN
Aaron
Created on: 27 Aug 2020 20:23
Category: Grid
Type: Feature Request
2
Add Support for Non-String Fields in Grid's Search Panel with ServerOperation(true)

Per the documentation for the Grid's Search Panel:

"When the server operations are enabled, you can search only by using string fields."

 

This is an oddly-specific limitation to have that causes an awkward user experience. Grids in some areas with limited data might use client operations and, as a result, the Search Panel is capable of searching all columns in a Grid. Other areas, however, might have grids with significantly more data and be using server operations for performance reasons. A side-effect of this would mean the Search Panel is incapable of filtering on non-string fields. This not only might lead to unexpected results to an end-user, but also requires the developer to explicitly list each string field that can be searched. If a developer forgets to list only string fields, the default action will be for it to attempt to filter on all fields. If any fields happen to not be strings, you still get a loading indicator as if it's attempting to filter, but the Ajax request silently fails and returns an error 500 behind the scenes.

There are some manual workarounds discussed here, as well as some information as to why this limitation exists. It seems like the problems causing these limitations are known, as are some rough workarounds to get around it. It would be great if we could get some official support to address this limitation so developers aren't left to either work around it on their own or avoid using this feature altogether. This feature would be great if it weren't for this limitation. A single place to quickly and easily type in something to filter on, and have that filter applied against all columns could definitely save some time and be very useful, but with this limitation with a pretty technical explanation (from an end-user perspective), the unexpected mixed results could instead lead to confusion and frustration, and distrust of this feature.

4 comments
ADMIN
Alex Hajigeorgieva
Posted on: 07 Sep 2020 07:45

Hello, Aaron,

Thank you very much for the provided in depth explanations and examples.

Once the feature request gains popularity, we will take a deeper look on how we can implement it and the potential drawbacks it may have. 

We will then update this post.

Kind Regards,
Alex Hajigeorgieva
Progress Telerik

Five days of Blazor, Angular, React, and Xamarin experts live-coding on twitch.tv/CodeItLive , special prizes and more, for FREE?! Register now for DevReach 2.0(20).

Aaron
Posted on: 31 Aug 2020 18:04
Also, I forgot to mention, we have looked into using the Filter widget as well as a few other things, and plan on using them in addition to the search panel. The great part about the search panel is the ease of use: a single place to type something in that will search across all columns. The Filter widget, by contrast, serves a different (but equally important) purpose of giving the user the functionality to apply a more specific type of filter to the results (ex. Status column equals "open" or "pending" and Updated before today's date).
Aaron
Posted on: 31 Aug 2020 17:59

Thanks for the quick response! For the silent error, something like that could be helpful. When I was testing the search panel specifically, it was pretty obvious that it wasn't working as expected since my results weren't getting filtered. Thinking ahead, however, if I were just setting up a new grid and had an invalid configuration, I wouldn't necessarily test the search panel specifically since my focus would probably be more on the data pulling through and displaying correctly (and I would assume the search panel, column-level filtering, etc. all worked fine). For these reasons, it would be nice if the grid and/or search panel configuration would be checked upfront and if there were problems, it would be very evident (ex. display an error instead of the grid, JavaScript alert, etc.). If this is what you had in mind, then yes, I think this would be pretty helpful and could help catch problems while still in development instead of after code goes into production and end-users have problems using the search panel.

 

As for expanding the configuration of the search panel, I would think that ideally, by default you would want the functionality to be the same across all types, whether server or client operations are being used (to maintain a consistent user experience from an end-user perspective). Having the ability to customize this on a per-field basis would definitely be a step in the right direction even if the functionality wasn't necessarily the same between server and client operations, because at least that way developers could still make the data searchable (and perhaps in a more useful way than what the default might offer). In a perfect world :) it would be great if the field-specific customizations could be specific to the original types. For example, it would be nice if it could be specified that a DateTime value of 08/01/2020 1:45 PM should also match on "8/1" and "13:45" (so somewhat of a "contains" type of search, with the awareness of how dates/times may or may not have leading zeros, be in 12 or 24 hour format, etc.). This would also allow a user to enter 08/01 in the search panel and see all results on that particular day (even if they don't know the exact time). I'm not sure how exactly this might be implemented, and this might be kind of an "icing on the cake" kind of thing, but I just thought I'd mention it. If the data was at least searchable (even if not this "fancy"), we could at least explain to users why entering "8/1" isn't matching on "08/01" much easier than server vs. client operations and data types.

ADMIN
Alex Hajigeorgieva
Posted on: 31 Aug 2020 13:51

Hello, Aaron,

Indeed the limitation is harder to understand for end-users than it is for developers and we absolutely see the points of having grids with server-side operations and local operations in the same application and how this may seem confusing for users.

After a discussion with the team, we could potentially expand the configuration of the search panel to allow developers to change the filter operator for a specific field. For example, you could configure the dates and numbers to use "lte", "gte" or another operator of your choice. As far as the silent error is concerned when date fields are not excluded, we could throw some runtime invalid configuration error perhaps to warn the developers, do you think that would be helpful?

Another improvement could be to visualize the filter expression like we have in the Filter widget.

Let me know what you think.

Kind Regards,
Alex Hajigeorgieva
Progress Telerik

Five days of Blazor, Angular, React, and Xamarin experts live-coding on twitch.tv/CodeItLive , special prizes and more, for FREE?! Register now for DevReach 2.0(20).