Browse Prior Art Database

Pushdown parsers to enable filtering of all columns in a table

IP.com Disclosure Number: IPCOM000233251D
Publication Date: 2013-Dec-04
Document File: 4 page(s) / 46K

Publishing Venue

The IP.com Prior Art Database

Abstract

Disclosed is a method applied to filtering capabilities in a table that establishes an interface between the perspective of the user and that of the backend processing in a way that is extensible and scalable. The method extends the standard instantiation procedure to optionally include a push-down parser.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 51% of the total text.

Page 01 of 4

Pushdown parsers to enable filtering of all columns in a table

It is common for web applications to provide data in tabular form with the ability for the user to customize the view to perform a variety of actions such as showing (or hiding) columns, reordering columns, and filtering the rows such that only a subset of the data set is shown to the user. Addressed herein is the ability to filter a set of rows in a complex table with a basic filter string.

Typically, columns represent different types of data. For example, in a single table, the following values can be represented: (column names are examples)


• Name column is a simple text string


• Status column is an enumeration (can be Normal, Warning, Error, etc.)


• Alerts column contains numbers


• Database column shows a capacity (e.g., 23.0 GB)


• Last Database Backup and Uptime columns are represented as durations (e.g., one month, two days, etc.)


• Columns for selection are Boolean (e.g., checked is true, and blank is false)

Typically, for table implementations, the data is represented internally in a native format (e.g., JavaScript* Object Notation (JSON)

with known semantics -- enumerations, normalized capacity, dates, etc.) and then formatted into an easy to read, humanized string for display purposes.

For efficiency purposes, it is preferable to perform filter operations in the back end as close to the data source possible (often a Structured Query Language (SQL) query). This means that the language of the filter operation uses these native information formats; however, the user does not know or care about these internal formats. The user just wants to type in something that is meaningful (e.g., 5 hours, 23 GB, etc.).

A method is needed to interface between the perspective of the user and that of the backend processing in a way that is

extensible and scalable.

When the table is instantiated (defined), the structure of the table is defined. This includes column definitions, default sort ordering, hidden vs. visible columns, etc. Also provided is a formatter (i.e., a piece of JavaScript code) that renders the native values into the human-readable output.

The novel contribution is a method to extend this instantiation procedure to optionally include a push-down parser.

First, the push-down parser validates a filter string against the type of data for which it is responsible. For example, having a push-down parser named Duration (to represent the type of data seen in the Uptime column), the parser validates "5 mins" as

1


Page 02 of 4

OK, but "300 yen" returns as not-OK (as it is not a valid duration). These push-down parsers can be as simple or complex as desired by the implementer. For example, the implementer can also check for dates (e.g., July 3, 1012) to indicate that the system was born at that time; the decision is dependent upon the context that best fits the use cases.

Second, if the push-down parser indicates a valid string (for the data type for which it...