You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The Definition object holds all the information needed to process the parsed input string and create a set of clauses that are used to query the provided relation.
Creating a definition by hand is tedious, and would benefit from some abstraction. How can we allow a developer or designer to define the definition for an index table? Some sort of minimal DSL would allow us to define abstractions for useful behavior. We could provide methods like filter that would create an ExpressionFilter, or a method like search to create a KeywordSearch. A user would be able to specify options or configuration using the DSL.
This is closely tied to #12 where we would like to allow a user to name a filter such that it could be referenced when generating a UI and enumerate a set of options for the filter.
In eeb51ac I removed the basic DSL we had been creating as it was not the right abstraction. This may be a good starting point for this issue.
Whatever DSL we create should ultimately produce a Query::Definition. Using the DSL should not be required, but should provide a significantly improved experience over defining the Definition manually.
The text was updated successfully, but these errors were encountered:
The Definition object holds all the information needed to process the parsed input string and create a set of clauses that are used to query the provided relation.
Creating a definition by hand is tedious, and would benefit from some abstraction. How can we allow a developer or designer to define the definition for an index table? Some sort of minimal DSL would allow us to define abstractions for useful behavior. We could provide methods like
filter
that would create anExpressionFilter
, or a method likesearch
to create aKeywordSearch
. A user would be able to specify options or configuration using the DSL.This is closely tied to #12 where we would like to allow a user to name a filter such that it could be referenced when generating a UI and enumerate a set of options for the filter.
In eeb51ac I removed the basic DSL we had been creating as it was not the right abstraction. This may be a good starting point for this issue.
Whatever DSL we create should ultimately produce a
Query::Definition
. Using the DSL should not be required, but should provide a significantly improved experience over defining the Definition manually.The text was updated successfully, but these errors were encountered: