Parameters in views.yaml

[mzeinstra]

In my use case I have a staging and production environment. I want to parameterise the queries differently for these environments.

E.g. I have items on my wikibase that are marked as 'draft' (Q123) and others that are marked as 'published' (Q456)

I want my staging environment to show drafts, while my production shows published

To have something like this config for staging:

metadata:
    status: "Q123"

views:
  - output: "index.html"
    query: "index.rq ${{ metadata.status }}"
    template: "index.html"

Even better to allow parameters from snowman.yaml into views.yaml, since that would be true separation of the config per environment.

See 'variable reuse' on https://learn.microsoft.com/en-us/azure/devops/pipelines/process/templates?view=azure-devops for inspiration.

Is something like this possible?

[Abbe98]

For single page views it could done by invoking the query inline, rather than in views.yaml:

views.yaml

views:
 - output: "index.html"
   template: "index.html"

index.html

{{ $status := config.Metadata.status }}
{{ $query_result = (query "name_of_parameterized_query.rq" $status) }}

For multipage views I do not think there is a way currently.

I kinda like the idea of views.yaml being able to "resolve" variables defined in snowman.yaml, preferably in any strings so that one could also swap queries/output paths, etc. Given such a feature I think we could avoid adding support for parameterized queries in views.yaml as one could pass in another query altogether:

snowman.yaml

sparql_client:
  endpoint: "https://query.wikidata.org/sparql"

metadata:
  generator_query: "production_query.rq"

views.yaml

views:
 - output: "index.html"
   query: "${{ metadata.generator_query }}"
   template: "index.html"

Overall, it's an interesting use case which I believe mainly differs from other environment separation use cases by having a shared datastore for data targeting more than one environment. I think any string in views.yaml should able to "resolve" variables defined in snowman.yaml. Parameterized queries in views.yaml I'm more skeptical about for now (always happy to be convinced!).

[mzeinstra]

I think having parameterised queries would also solve my use case, as then I could configure the building in snowman.yaml.

I don't fully understand how parameterizing queries differs substantially from this approach.

At this stage I am still exploring if snowman is fit for purpose for my goals. I like the approach and ease in which I could make a tech demonstrator!

[Abbe98]

I don't fully understand how parameterizing queries differs substantially from this approach.

The benefit as I see it is that the approach above should cover the use case while being very flexible as one can actually make anything defined in views.yaml configurable from snowman.yaml(templates, output paths, etc).

From a maintenance perspective parameterised queries in views.yaml would introduce the same amount of complexity for just the parameter-injection alone.

At this stage I am still exploring if snowman is fit for purpose for my goals. I like the approach and ease in which I could make a tech demonstrator!

Thank you! It's very valuable to hear about use cases and suggestions like yours.