ewbi

The Kendo UI DataSource uses JQuery's unique $.param serialization style for its server-side sorting query string parameter, which on the surface doesn't seem to lend itself to deserialization by the standard ASP.NET model binder. It looks like this:

sort[0][field]=FieldName1&sort[0][dir]=asc&sort[1][field]=FieldName2&sort[1][dir]=desc

However, it turns out it can be deserialized into an array of two-element Dictionaries:

public Dictionary<string, string>[] Sort { get; set; } = [];

Each resulting Sort Dictionary will contain two elements, with the keys "field" and "dir".

Nearly twenty years ago I cranked out some JavaScript that parsed Excel formulas into their constituent tokens based on some simple syntactic rules without needing a full BNF grammer or even a complete list of Excel functions and parameters. I attached that code to a text input field in a post on the old ewbi.develops blog (now long gone) and it became quite popular. I later implemented similar logic in a C# library and used it for a client project for bulk evaluation of thousands of Excel workbooks. The JavaScript and C# sampler were free to use, and given a legitimate MIT license in 2016, so others picked it up and implemented it in still more languages. All these years later I still get inquiries about that logic, and there are numerous references to the original blog post and its follow-ups scattered around the web, so I thought I might save everyone some time by rolling up the relevant links here.

My Code

• Original JavaScript version (view source)
• C# implementation and sample client (ZIP)

Other Languages

• Robin Macharg's Python implementation
• Robin's Python implementation in PyPI's Pycel (Dirk Gorissen's repo)
• Maarten Balliauw's PHP implementation
• Rob van Gelder's VBA implementation
• Lishen's C++ implementation
• Tony Roberts' C++ xlfparser implementation
• Hartmut David's Delphi XE Pascal implementation (ZIP)
• Ri Xu's Go implementation

There aren't many examples of how to use the Graph SDK for .NET to perform Graph search/query API calls, and even fewer showing how to "page" through the sets of hits it returns. In short, the SearchRequest includes From and Size properties, the former generally starting at 0 and the latter (per Microsoft's recommendation) starting with a small number like 25. The QueryPostResponse returns a hit count, and indication of whether there are more hits available, and a Value property with a collection of SearchResponse items. In most examples found on the webs, "paging" amounts to enumerating the hits in the response and if there are more hits available, then bumping the SearchRequest From by the Size (and then generally increasing Size, like to 200), posting the request again, and repeating until there are no more hits. This differs considerably from the other Graph collection results, which rely on a special PageIterator to walk the @odata.nextLink URLs found in the responses. In this case, there's no connection, no "next" URL, between calls, each call is independent. And this works fine until you add a sort via the SearchRequest SortProperties. When sorted, the SearchRequest (or perhaps the QueryPostRequestBody that it's enveloped in, I never could find the link) winds up with some state that results in an unhelpful "The call failed, please try again." exception if it's posted again with different From/Size properties. So, create a new one each time. And be prepared to deal with duplicates, because even with trimDuplicates there's no guarantee that the search index won't change between calls.

Make a request with a session-scoped HTTP-only no-expiration domain cookie, response comes back without it, but the cookie goes missing. Hook all kinds of bits into the page response to figure out where the cookie is lost. No joy. Finally look at all the requests made by the page. Ta da. There's a (bad) request for a cross-subdomain image, starting from test.domain.com, but requesting an image from www․domain.com. Not a problem, per se, it's a domain-scoped cookie, but the cookie's existence depends on a prior authentication, which the other (www) site doesn't have, so it cleared the cookie in its response. Let's hope I can figure that out quicker next time.