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
One of the key features needed to support m30pm self-adapting to any m30ml-based language and to support creation of rich view generation from projects is a robust query system.
I have been experimenting with the use of njk as the query language (our selected templating language) with much success. My concept is that a query uses njk to render a json or yaml file (something I would not ordinarily endorse, but in this case the reuse of njk for both queries and view definitions justifies the round about process of templating a data formatted file).
One might ask why we need a query run command instead of using the cli tool in the dof kasm image. After experimenting with that tool, I feel its UX is way too convoluted to make it a practical way for users to rely on for the following reasons.
It requires json as the text format for the model file (which means converting the yaml to json).
It requires the model data be placed within a json construct compiler.context. So, not only do users have to convert the yaml to json, they must place the yaml content under compiler.context. All of which can be done with yq, but it is a set of extra steps that I don't think should be required.
I want to define a query class in the core schema that can be used to define queries within projects. This query class should have the following data.
name [string]
queriedObject [object]
queryParameters [parameterDefinition references]
queryNjkFile [filePath]
The query run command will take a required argument of the query's name the user wants to run. The command would take an optional key that is a string of a dictionary (json format) of values to pass into the queryParameters. If there are required queryParameters and the key is not provided the command will ask the user to provide them through interaction.
The run command would then use the njk library, the query definition, and the fully built model file to execute the query and generate a yaml result file that can be used by m30pm or view generation for a variety of views.
The text was updated successfully, but these errors were encountered:
One of the key features needed to support m30pm self-adapting to any m30ml-based language and to support creation of rich view generation from projects is a robust query system.
I have been experimenting with the use of njk as the query language (our selected templating language) with much success. My concept is that a query uses njk to render a json or yaml file (something I would not ordinarily endorse, but in this case the reuse of njk for both queries and view definitions justifies the round about process of templating a data formatted file).
One might ask why we need a query run command instead of using the cli tool in the dof kasm image. After experimenting with that tool, I feel its UX is way too convoluted to make it a practical way for users to rely on for the following reasons.
I want to define a query class in the core schema that can be used to define queries within projects. This query class should have the following data.
The query run command will take a required argument of the query's name the user wants to run. The command would take an optional key that is a string of a dictionary (json format) of values to pass into the queryParameters. If there are required queryParameters and the key is not provided the command will ask the user to provide them through interaction.
The run command would then use the njk library, the query definition, and the fully built model file to execute the query and generate a yaml result file that can be used by m30pm or view generation for a variety of views.
The text was updated successfully, but these errors were encountered: