VMware {code} Community
ChrisSmith2
Enthusiast
Enthusiast
Jump to solution

VSphere 6.5U1 filter Comparator type

In the vSphere Client 6.5U1 UI, there is a standard "Filter" box on the top-right of the built-in lists, including the built-in lists for custom objects. However, this filter does not work for the SDK samples and our plugin.

In the "dataservice.log", it appears that using the filter causes a query to be built using a CompositeConstraint for all of the displayed columns with a Comparator type of "CONTAINS". This comparator is not handled by the samples - only "TEXTUALLY_MATCHES".

Is the "CONTAINS" comparator functionally equivalent to "TEXTUALLY_MATCHES"? The SDK documentation lists the various Comparator enums, but doesn't seem to contain any details about what they mean. For example, should "CONTAINS" be case-sensitive? Are any of the other Comparator values used by the default vSphere UI and/or VMWare-provided tools and need to be supported by plugins?

Reply
0 Kudos
1 Solution

Accepted Solutions
_vladi_
VMware Employee
VMware Employee
Jump to solution

Hi Chris,

Indeed, samples currently don't support filtering in the list. You can try using CONTAINS in your provider which is a substring search (unlike TEXTUALLY_MATCHES which does pattern matching). In a way they are similar but not functionally equivalent.

Instead of this, going forward we plan to demonstrate building a custom plugin-owned list that better fits the UX of the HTML Client and gives the needed flexibility to plugins.

Cheers,

Vladi

View solution in original post

Reply
0 Kudos
3 Replies
_vladi_
VMware Employee
VMware Employee
Jump to solution

Hi Chris,

Indeed, samples currently don't support filtering in the list. You can try using CONTAINS in your provider which is a substring search (unlike TEXTUALLY_MATCHES which does pattern matching). In a way they are similar but not functionally equivalent.

Instead of this, going forward we plan to demonstrate building a custom plugin-owned list that better fits the UX of the HTML Client and gives the needed flexibility to plugins.

Cheers,

Vladi

Reply
0 Kudos
ChrisSmith2
Enthusiast
Enthusiast
Jump to solution

Thanks. The 'chassisb' sample does implement TEXTUALLY_MATCHES, but as a case-insensitive substring search (using indexOf), not pattern matching.

Unless there is a formal definition of the pattern matching rules and it is required to be supported as such, or you advise otherwise, we'll keep the existing sample behaviour for TEXTUALLY_MATCHES and just add CONTAINS to use the same implementation - that is what I already did to prove and resolve the issue, but wanted to confirm it was a valid solution.

Thanks for the feedback!

Reply
0 Kudos
_vladi_
VMware Employee
VMware Employee
Jump to solution

Great you have resolved the issue. I think what you did is completely viable solution (and also actual fix rather than a workaround). Good job!

Cheers,

Vladi

Reply
0 Kudos