Liquid es un lenguaje de plantillas que puedes usar en Looker para crear contenido más dinámico. Por ejemplo, puedes crear URL para herramientas externas basadas en los resultados de una consulta o cambiar la tabla de la base de datos que se consulta en función de la selección del usuario.
Las declaraciones líquidas se crean a partir de variables, filtros y etiquetas. Las variables contienen la información que desea utilizar, y las variables que proporciona Looker se describen en esta página. Puede modificar aún más esos valores mediante filtros y etiquetas, que puede obtener más información en esta Guía sobre líquidos.
Existen varios lugares en LookML en los que puede usar líquidos:
- El parámetro
action
- El parámetro
description
de un campo (pero no de Explorar) - El parámetro
html
- Parámetros de etiquetas a nivel de campo, incluidos los parámetros
label
,view_label
,group_label
ygroup_item_label
- El parámetro
link
- Parámetros que comienzan con
sql
(comosql
ysql_on
) - El parámetro de filtro del panel
default_value
- El parámetro del elemento del panel
filters
Usa variables líquidas
El uso básico de variables líquidas es sencillo. Una vez que haya identificado la variable que desea utilizar (consulte la siguiente lista), simplemente insértela en un parámetro de LookML válido. A continuación, se definen las variables líquidas específicas que puede usar en parámetros específicos de LookML.
Dos tipos de uso de líquidos
Existen dos maneras de usar una variable líquida:
- Sintaxis de salida: Este tipo de uso puede insertar texto y es, probablemente, la forma más común de usar líquido en Looker. En este método, encierra la variable líquida entre llaves. Por ejemplo:
{{ value }}
- Sintaxis de etiquetas: Por lo general, este tipo de uso no inserta texto; en cambio, es para comparaciones lógicas y otras operaciones de Líquido. En este método, encierra la variable líquida con una llave y un signo de porcentaje único. Por ejemplo:
{% dynamic if value > 10000 %}
Ejemplos básicos
En este ejemplo de uso de HTML, se inserta un ID de producto en una etiqueta <img>
para generar imágenes del producto:
dimension: product_image {
sql: ${product_id} ;;
html: <img src="https://www.brettcase.com/product_images/{{ value }}.jpg" /> ;;
}
En este ejemplo de uso de URL, se inserta un nombre de artista en una URL para generar una búsqueda de Google para ese artista.
dimension: artist_name {
sql: ${TABLE}.artist_name ;;
link: {
label: "Google"
url: "https://www.google.com/search?q={{ value }}"
icon_url: "https://google.com/favicon.ico"
}
}
En este ejemplo de uso de SQL, la tabla de la base de datos se determina en función de los campos que elige el usuario. La sintaxis usa una estructura if
, de lo contrario, (denotada como elsif
), else
, para verificar y reaccionar a los campos incluidos en la consulta.
sql_table_name:
{% dynamic if event.created_date._in_query %}
event_by_day
{% elsif event.created_week._in_query %}
event_by_week
{% dynamic else %}
event
{% dynamic endif %} ;;
En este ejemplo de uso de la etiqueta, la dimensión email
cambia su valor label
según el nombre del modelo de LookML. Esto cambiará de forma dinámica el nombre del campo en el selector de campos y en cualquier resultado de consulta que incluya la dimensión email
:
dimension: email {
label: "{% dynamic if _model._name == 'thelook' %} Looker Registered Email Address {% dynamic else %} External Email Address {% dynamic endif %}"
type: string
sql: ${TABLE}.email ;;
}
Para ver más ejemplos de uso, consulta la página de parámetros individuales de LookML que te interesa.
Accede a variables desde otros campos
Por lo general, las variables líquidas se basan en el campo en el que se usan. Sin embargo, también puedes acceder a los valores de otros campos si es necesario.
Usa el formato {{ view_name.field_name._liquid-variable-name }}
para acceder a otros campos desde la misma fila en el resultado de la consulta. Reemplaza _liquid-variable-name
por cualquiera de las variables líquidas de Looker. Asegúrate de que el nombre de la variable esté precedido por un guion bajo si no es normal, como se muestra a continuación:
{{ view_name.field_name._value }}
{{ view_name.field_name._rendered_value }}
{{ view_name.field_name._model._name }}
En este ejemplo, se muestra este tipo de uso para acceder a una URL del sitio web desde un campo diferente:
dimension: linked_name {
sql: ${name} ;;
html: <a href="{{ website.url._value }}" target="_blank">{{ value }}</a> ;;
}
Cuando haces referencia a otro campo con la sintaxis de variable líquida
{{ field_name._value }}
, el campo al que se hace referencia se agrega a la cláusulaSELECT
de la consulta de SQL y se agrega como una columna adicional en la cláusulaGROUP BY
. Esto es necesario para recuperar correctamente los valores en el campo al que se hace referencia. Sin embargo, puede generar resultados inesperados en las medidas agregadas. Para obtener más información, consulte la sección Cómo usar variables líquidas en medidas agregadas en esta página.
Definiciones de las variables líquidas
En la siguiente tabla, se describen las variables líquidas que puedes usar con LookML. La columna Uso indica con qué parámetros de LookML se puede usar cada variable líquida y, además, incluye las siguientes opciones:
A = Funciona con el parámetro action
DV = Funciona con el parámetro default_value
(para paneles)
DE = Funciona con el parámetro description
a nivel de campo, pero no funcionará con description
a nivel de Explorar.
F = Funciona con el parámetro filters
(para elementos del panel)
H = Funciona con el parámetro html
LA = Funciona con los parámetros de etiqueta a nivel de campo, incluido el parámetro label
, el parámetro view_label
, el parámetro group_label
y el parámetro group_item_label
, pero no funcionará con los parámetros de etiqueta a nivel del modelo, Explorar, Ver o hacer referencia, o con label
como subparámetro de link
LI = Funciona con el parámetro link
S = Funciona con todos los parámetros de LookML que comienzan con sql
(p. ej., sql
, sql_on
y sql_table_name
).
Variable | Definición | Uso | Resultado de ejemplo |
---|---|---|---|
Valores de campo | |||
value | El valor sin procesar del campo que muestra la consulta de la base de datos. Puede hacer referencia a un valor de campo dinámico. Además de los parámetros que se muestran en la columna Uso, se admite value en el subparámetro label de los parámetros action y link . | A H LI | 8521935 |
rendered_value | El valor del campo con el formato predeterminado de Looker. Puedes consultar la sintaxis de formato de fecha en rendered_value , como se muestra en el artículo Formato de fecha sencillo con Liquid del Centro de ayuda.Además de los parámetros que se muestran en la columna Uso, rendered_value es compatible con el subparámetro label de los parámetros action y link . | A H LI | USD 8,521,935.00 |
filterable_value | El valor del campo con formato para usar como filtro en una URL de Looker. Por ejemplo, cuando filtras por un valor de string que incluye una coma como “Periaptly, Inc”, la variable value muestra dos strings diferentes, “Periaptly” y “Inc”. Para corregir esto, la variable filterable_value escapa caracteres especiales y muestra una sola string, en este ejemplo, "Periaptly, Inc". | A H LI | 8521935 |
Vínculos | |||
link | La URL al vínculo del taladro predeterminado de Looker. Ten en cuenta que algunos campos no tendrán ningún vínculo predeterminado. | A H LI S | /explore/thelook/orders?fields=orders.order_amount&limit=500 |
linked_value | El valor del campo con el formato y la vinculación predeterminados de Looker. Las medidas no tienen vinculaciones predeterminadas, por lo que requieren una configuración del parámetro drill_fields para funcionar con linked_value . | A H LI | USD 8,521,935.00 |
Filtros | |||
_filters['view_name.field_name'] | Los filtros de usuario que se aplican al campo que solicitas con view_name.field_name ._filters['view_name.field_name'] también es compatible con el parámetro sql de una tabla derivada, pero no es compatible con otros parámetros sql . Para usar _filters['view_name.field_name'] en una tabla derivada, el parámetro sql requiere el filtro líquido sql_quote . | A DE H LA LI | NO NULOS |
{% date_start date_filter_name %} | La fecha de inicio de un filtro de fecha que solicites con date_filter_name . Consulta la sección Uso de date_start y date_end para obtener más información. | S | 2017-01-01 |
{% date_end date_filter_name %} | La fecha de finalización en un filtro de fechas que solicitas con date_filter_name . Consulta la sección Uso de date_start y date_end para obtener más información. | S | 2017-01-01 |
{% condition filter_name %} sql_or_lookml_reference {% endcondition %} | El valor del filtro que solicitas con filter_name aplicado al sql_or_lookml_reference como SQL. Esta variable se usa con filtros de plantilla y uniones condicionales. | S | Consulta la página de documentación Filtros de plantilla y la sección Uniones condicionales de la página de documentación sql_on para ver ejemplos. |
{% parameter parameter_name %} | El valor del filtro de parámetros que solicitas con parameter_name . | DE LA S | Consulta la página de documentación de parámetros de parameter para ver ejemplos. |
parameter_name._parameter_value | Incorpora el valor del filtro de parámetro que solicitas con parameter_name en una instrucción lógica. | DE H LA LI S | Consulta la página de documentación de parámetros de parameter para obtener detalles y ejemplos importantes. |
Atributos de usuario | |||
_user_attributes['name_of_attribute'] | El valor del atributo de usuario que solicitas con name_of_attribute para el usuario específico que ejecuta la consulta, si se usan atributos de usuario. La variable _user_attributes['name_of_attribute'] también se puede usar en la sintaxis de filtro avanzado. | A DE H LA LI S DV F | noreste (si, por ejemplo, el atributo de usuario era "region") Consulte el artículo del Centro de ayuda Cómo usar los atributos de usuario para la inserción dinámica de nombres de tablas y esquemas. |
_localization['localization_key'] | Muestra el valor asociado a la clave de localización definida en el archivo de strings del modelo según la configuración regional del usuario. | DV F | Consulta la página de documentación Localiza tu modelo de LookML para ver un ejemplo. |
Objetos de LookML | |||
_model._name | El nombre del modelo para este campo. | A DE H LA LI S | el estilo |
_view._name | El nombre de la vista para este campo. | A DE H LA LI S | orders |
_explore._name | El nombre de la sección Explorar de este campo. | A DE H LA LI S | pedido_artículos |
_explore._dashboard_url | ADDED 22.12 La URL relativa para el panel actual. | H LI | /dashboards/5 |
_field._name | El nombre del campo en sí, en formato view_name.field_name . | A DE H LA LI S | pedidos.total_order_amount |
Queries | |||
_query._query_timezone | La zona horaria en la que se ejecutó la consulta. | A DE H LA LI S | America/Los_Angeles |
view_name._in_query | Muestra true si se incluye algún campo de la vista en la consulta. | DE LA LI S | true |
view_name.field_name._in_query | Muestra true si el campo que solicitas con view_name.field_name aparece en la tabla de datos de la consulta, se incluye en un filtro para una consulta o se incluye en una consulta a través del parámetro required_fields . | DE LA LI S | true |
view_name.field_name._is_selected | Muestra true si el campo que solicitas con view_name.field_name aparece en la tabla de datos de consulta. | DE LA LI S | true |
view_name.field_name._is_filtered | Muestra true si el campo que solicitas con view_name.field_name se incluye en un filtro para la consulta. | DE LA LI S | true |
Uso de date_start
y date_end
Las variables líquidas date_start
y date_end
son muy útiles para dialectos de bases de datos que particionan datos en varias tablas por fecha, como BigQuery. Ten en cuenta que debes usar la sintaxis de la etiqueta {% date_start date_filter_name %}
o {% date_end date_filter_name %}
. No puedes usar la sintaxis de salida {{ date_start date_filter_name }}
{{ date_end date_filter_name }}
Por ejemplo, puedes crear estos campos en una vista:
filter: new_filter_test{
type: date
}
dimension: filter_start{
type: date
sql: {% date_start new_filter_test %} ;;
}
dimension: filter_end{
type: date
sql: {% date_end new_filter_test %} ;;
}
Si filtras por un elemento new_filter_test
el período del 1 de abril de 2022 al 25 de mayo de 2022, la dimensión filter_start
se evaluaría como 1 de abril de 2022; la filter_end
se evaluaría como 25 de mayo de 2022.
Ten en cuenta lo siguiente sobre date_start
y date_end
:
Si el usuario no filtra la consulta con el filtro que se especifica en la parte
date_filter
de la variable líquida,{% date_start date_filter %}
y{% date_end date_filter %}
se evaluarán como NULL.Si el usuario filtra la consulta con un rango abierto en el filtro que se especifica en la parte
date_filter
de la variable líquida, el extremo abierto del rango se resolverá en NULL. Por ejemplo, si usas el ejemplo, si en la sección Explorar un usuario establecenew_filter_test
en antes del 07/06/2022, el resultado de{% date_start date_filter %}
será NULL, ya que el usuario especificó un rango que tiene una fecha de finalización, pero no una fecha de inicio. Si un usuario establecenew_filter_test
en después de 7/06/2022, el resultado de{% date_end date_filter %}
será NULL.
En cualquiera de estos casos en los que la salida líquida pueda mostrar un resultado de NULL, asegúrate de incluir una función SQL en el parámetro sql
para tener en cuenta los valores NULL, como IFNULL
o COALESCE
, según el dialecto de tu base de datos.
Consulta el tema Cómo usar date_start y date_end de la comunidad de Looker para obtener una explicación detallada sobre cómo usar las variables líquidas date_start
y date_end
a fin de tratar con tablas particionadas por fecha.
Consulte el artículo del Centro de ayuda sobre el Análisis flexible entre períodos del bloque de estadísticas para ver un ejemplo de cómo usar date_start
y date_end
para el análisis flexible entre períodos.
Uso de _in_query
, _is_selected
y _is_filtered
Ten en cuenta que las variables _in_query
, _is_selected
y _is_filtered
proporcionan un valor verdadero o falso, como se muestra en este ejemplo. En consecuencia, es importante elegir el tipo adecuado de referencia de variable líquida.
Si desea determinar si se incluye o no algún elemento en su consulta, y luego insertar cierto texto basado en eso, debería usar un patrón como este:
{% dynamic if view_name.field_name._in_query %}
something to insert if true
{% dynamic else %}
something to insert if false
{% dynamic endif %}
Si deseas insertar literalmente la palabra "true" o "false", usa un patrón como el siguiente:
{{ view_name.field_name._in_query }}
Algunos dialectos de SQL no admiten las palabras literales "true" y "false". En ese caso, puedes agregar el filtro sql_boolean
para obtener los valores verdaderos y falsos que necesitas:
{{ view_name.field_name._in_query | sql_boolean }}
Los mismos patrones se aplican a las variables _is_selected
y _is_filtered
.
Uso de variables líquidas con el parámetro label
Puedes usar variables líquidas en el parámetro label
de un campo para cambiar dinámicamente la apariencia del campo en el selector de campo y en las visualizaciones. Consulta la sección tabla de esta página para ver qué variables líquidas funcionan con el parámetro label
.
Las variables líquidas funcionan con parámetros de etiqueta a nivel de campo, incluido el parámetro
label
, el parámetroview_label
, el parámetrogroup_label
y el parámetrogroup_item_label
, pero no funcionarán con los parámetros de etiqueta a nivel del modelo, Explorar, ver o hacer referencia, ni con la etiqueta como subparámetro delink
.
Las siguientes variables se pueden usar con label
para afectar el selector de campo, los encabezados de columna en la sección de datos de Explorar y las visualizaciones:
_model._name
_view._name
_explore._name
_field._name
_user_attributes['name_of_attribute']
Las otras variables líquidas marcadas con LA en la tabla anterior, como las que muestran un valor basado en un filtro (como _filters
) o requieren que se ejecute una consulta antes de que se pueda determinar el valor de la variable (como in_query
), no cambiarán el nombre del campo en el selector de campos. En esos casos, el nombre del campo solo se cambiará en la visualización resultante.
Cuando usas la variable líquida parameter
con label
, label
recibe el valor del subparámetro value
.
Uso de variables líquidas con el parámetro description
Puedes usar variables líquidas con el parámetro description
para cambiar de forma dinámica la descripción de un campo. Esta descripción aparece cuando los usuarios se desplazan sobre el ícono de información del campo en el selector de campo, el nombre de columna del campo en la sección de datos de Explorar o el nombre de columna del campo en un gráfico de tabla. Consulta la tabla en la sección Definiciones de las variables líquidas de esta página para ver qué variables líquidas funcionan con el parámetro description
.
Las variables líquidas funcionan con el parámetro
description
solo a nivel del campo. No funcionarán con el parámetrodescription
en el nivel Explorar.
Las siguientes variables se pueden usar con description
para afectar el selector de campo, la sección de datos de Explorar y el encabezado de columna en un gráfico de tabla:
_model._name
_view._name
_explore._name
_field._name
_user_attributes['name_of_attribute']
Las otras variables líquidas marcadas con DE en la tabla anterior, como las variables líquidas que muestran un valor basado en un filtro (como _filters
) o requieren que una consulta se ejecute antes de que se pueda determinar el valor de la variable (como in_query
), no se modificará la descripción en el selector de campos ni en la sección de datos de Explorar. Estas variables líquidas solo afectan la descripción que se muestra cuando un usuario se desplaza sobre el encabezado de columna del campo de un gráfico de tabla.
Para ver ejemplos de cómo usar líquido en el parámetro description
, consulta la página de documentación del parámetro description
.
Aspectos para tener en cuenta
Haz referencia a campos yesno
Para hacer referencia al valor de un campo yesno
, este distingue entre mayúsculas y minúsculas. Usa Yes
o No
Por ejemplo:
{% dynamic if value == 'Yes' %}
Usa operadores lógicos con variables líquidas
Puedes usar los operadores lógicos and
, or
y not
con variables líquidas. En Líquido, los operadores lógicos distinguen mayúsculas de minúsculas y deben escribirse en minúsculas. Por ejemplo:
{% dynamic if value == "Shirt" or value == "Shoes" %}
This is a shirt or shoes.
{% dynamic endif %}
Cómo obtener el error "Variable no encontrada"
Uno de los motivos por los que puedes recibir este error en Liquid es si usas {{ }}
y {% %}
al mismo tiempo, de la siguiente manera:
{% if value > {{ search_latency_top_hr.limit_95._value }} %}
En su lugar, haz lo siguiente:
{% dynamic if value > search_latency_top_hr.limit_95._value %}
Si utiliza un filtro con plantilla, verifique si hace referencia a un nombre de tabla que no haya unido a la tabla derivada.
Las convenciones de nombres pueden afectar la agrupación de consultas
Si hay un campo con el nombre value, este campo se incluirá en la cláusula GROUP BY de una consulta de exploración siempre que se haga referencia a la variable líquida value
en otro campo dentro de la misma vista.
Por ejemplo:
dimension: id {
primary_key: true
type: number
sql: ${TABLE}.id ;;
html:
{% dynamic if value > 10 %}
<font color="darkgreen">{{ rendered_value }}</font>
{% elsif value > 11 %}
<font color="goldenrod">{{ rendered_value }}</font>
{% dynamic else %}
<font color="darkred">{{ rendered_value }}</font>
{% dynamic endif %} ;;
}
dimension: value {
sql: ${TABLE}.status ;;
type: string
}
Esto generará el siguiente SQL cuando solo se seleccione id en Explorar:
SELECT
orders.id AS orders.id,
orders.status AS orders.value
FROM order_items
LEFT JOIN orders ON order_items.order_id = orders.id
GROUP BY 1,2
ORDER BY orders.id
LIMIT 500
Para evitar este comportamiento de agrupación, asegúrate de definir el alcance de la variable value
con el nombre del campo que haga referencia explícita al campo:
dimension: id {
primary_key: true
type: number
sql: ${TABLE}.id ;;
html:
{% dynamic if value > 10 %}
<font color="darkgreen">{{ id._rendered_value }}</font>
{% elsif value > 11 %}
<font color="goldenrod">{{ id._rendered_value }}</font>
{% dynamic else %}
<font color="darkred">{{ id._rendered_value }}</font>
{% dynamic endif %} ;;
}
El uso de _filters['view_name.field_name']
en una tabla derivada requiere sql_quote
Cuando defines una tabla derivada basada en SQL, si usas la variable líquida _filters['view_name.field_name']
en la que el valor se renderiza en SQL y el filtro muestra un valor de string, debes agregar comillas simples alrededor del resultado. Para ello, incluye el filtro de líquido sql_quote
.
Por ejemplo, si usas cualquiera de estas variables líquidas en el parámetro sql
de un parámetro derived_table
:
{{ _filters['view_name.field_name'] }}
o
{% assign foo = _filters['view_name.field_name'] %} foo
Puedes agregar el filtro de líquido | sql_quote
a la declaración de la variable líquida:
{{ _filters['view_name.field_name'] | sql_quote }}
y
{% assign foo = _filters['view_name.field_name'] | sql_quote %} foo
A continuación, se muestra una tabla derivada de ejemplo que usa la variable _filters['view_name.field_name']
:
view: users_sql_based_dt {
derived_table: {
sql:
SELECT
users.id AS id,
(DATE(users.created_at)) AS created_date,
users.city AS city,
COUNT(*) AS user_count
FROM
public.users AS users
{% dynamic if users_sql_based_dt.city._is_filtered %}
WHERE
users.city = {{ _filters['users_sql_based_dt.city'] | sql_quote }}
{% dynamic endif %}
GROUP BY
1,
2,
3
ORDER BY
2 DESC
;;
}
El campo city
es una string que se enviará a SQL, por lo que el filtro líquido sql_quote
es necesario para asegurarse de que el resultado de SQL esté entre comillas simples. En la Explorar resultante, cuando un usuario especifica el nombre de una ciudad como filtro, Looker encierra la string del nombre de la ciudad entre comillas. Looker envía este SQL a la base de datos si un usuario filtra la consulta Explorar en el valor de ciudad New York
:
WHERE
users.city = 'New York'
Si usas la variable líquida
_filters['view_name.field_name']
para un campo de string en una tabla derivada en la que el valor se renderiza en SQL, recibirás la siguiente advertencia de LookML si no anexas| sql_quote
a la variable líquida:
Using "_filters[]" in Derived Table SQL without "sql_quote" is discouraged.
También puedes usar sql_quote
con esta sintaxis para citar varios valores en un arreglo:
{{ _filters['view_name.field_name'] |split(",") | sql_quote |join(",") }}
En este ejemplo, se usa la salida líquida como entrada para una declaración IN
:
WHERE
users.city IN({{ _filters['users_sql_based_dt.city'] |split(",") | sql_quote |join(",") }})
Con esta sintaxis, la salida Líquida tendrá comillas alrededor de cada valor individual ('value1','value2','value3'
) en lugar de comillas alrededor de la lista completa ('value1, value2, value3'
).
Las variables líquidas en las mediciones agregadas afectan la agrupación
Cuando usas la sintaxis {{ view_name.field_name._value }}
o {{ field_name._value }}
en el parámetro link
o html
de una medida para hacer referencia a un valor de otro campo, Looker extrae ese campo en la consulta de SQL para tomar el valor del campo. Debido a esto, Líquido puede afectar cómo se generan las consultas de SQL y cuántas columnas usa la cláusula GROUP BY
, lo que puede causar un comportamiento inesperado cuando se trabaja con medidas agregadas, como las de type: count
.
Por ejemplo, supongamos que tienes las dos medidas siguientes:
measure: count_without_liquid {
type: count
}
measure: count_with_liquid {
type: count
link: {
label: "Status Count"
url: "https://www.google.com/search?q={{ status._value }}"
}
}
Cuando generas una consulta con la medida count_without_liquid
, obtienes los siguientes resultados:
En este caso, la consulta muestra un solo recuento para cada mes. A continuación, se muestra el SQL que se genera para los resultados anteriores:
SELECT
TO_CHAR(DATE_TRUNC('month', order_items.created_at ), 'YYYY-MM') AS "order_items.created_month",
COUNT(*) AS "order_items.count_without_liquid"
FROM order_items AS order_items
GROUP BY DATE_TRUNC('month', order_items.created_at )
ORDER BY 1 DESC
LIMIT 500
Sin embargo, cuando generas una consulta con la medida count_with_liquid
, obtienes los siguientes resultados:
En este ejemplo, se muestra que en lugar de un recuento por cada mes de la consulta, se recibe un recuento por cada mes y por cada estado. Esto se debe a que, en el SQL generado, se agregó el campo status
a la consulta para que se pudiera recuperar su valor. Y, como se agregó a la consulta, también se agregó a la cláusula GROUP BY
:
SELECT
TO_CHAR(DATE_TRUNC('month', order_items.created_at ), 'YYYY-MM') AS "order_items.created_month",
order_items.status AS "order_items.status",
COUNT(*) AS "order_items.count_without_liquid"
FROM order_items AS order_items
GROUP BY DATE_TRUNC('month', order_items.created_at ),2
ORDER BY 1 DESC
LIMIT 500
Una opción para evitar que esto suceda es usar la función row[]
con la variable líquida, que extrae su valor de los resultados procesados en el navegador y, por lo tanto, no agrega el campo al que se hace referencia en la consulta de SQL:
link: {
label: "{% dynamic if row['view_name.field_name'] %} some_label {% dynamic endif %}"
url: "https://www.google.com/search?q={{ row['view_name.field_name'] }}"
}
Cuando uses esta sintaxis, ten en cuenta que el parámetro link
solo funciona si el campo está seleccionado o incluido en la consulta por otros medios.
En resumen, el uso de la sintaxis row[]
no hará que el campo se agregue a la consulta como lo hace {{ field_name._value }}
. La etiqueta dinámica hará que el vínculo no tenga ninguna etiqueta si el campo no está disponible, lo que hace que el vínculo desaparezca del menú de vínculos.