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?
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
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
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!
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
