Cette page présente des façons utiles d'utiliser le champ parameter de Looker avec certains des sous-paramètres label qui acceptent les variables Liquid.
Les exemples de cette page nécessitent une connaissance de Liquid. Pour en savoir plus sur l'utilisation de Liquid dans Looker, consultez la page de documentation Documentation de référence sur les variables Liquid.
Utiliser view_label pour les noms d'affichages dynamiques
Le paramètre view_label de Looker permet de regrouper des dimensions sous un nom plus contextuel et plus convivial dans le sélecteur de champ d'exploration. Pour en savoir plus sur les libellés de vue, consultez la page de documentation view_label (pour les champs).
Attribuer la même view_label aux dimensions simplifie les explorations pour les utilisateurs. Des groupes de champs clairs et descriptifs permettent aux utilisateurs de trouver les données dont ils ont besoin.
Exemple: Écrire du code DRY (Don't Repeat Yourself) avec un view_label Liquid
Par exemple, supposons que vous ayez des champs organisés sous view_label Finance et comptabilité
dans une exploration intitulée Éléments de l'inventaire:
dimension: cost {
view_label: "Finance & Accounting"
type: number
sql: ${TABLE}.COST ;;
}
dimension: cost_ex_vat {
view_label: "Finance & Accounting"
type: number
sql: ${TABLE}.COST_EX_VAT ;;
}
dimension: cost_eur {
view_label: "Finance & Accounting"
type: number
sql: ${TABLE}.COST_EUR ;;
}
Que se passe-t-il si vous souhaitez remplacer Finance et comptabilité
par Zone d'argent
pour les utilisateurs ?view_label L'utilisation de Liquid peut éviter de réécrire le code de manière répétitive.
Vous pouvez créer un type de pseudo-variable du nom de la vue souhaitée à l'aide du champ parameter de Looker. Une fois que vous avez modifié le nom de la vue dans parameter, tous les champs sont mis à jour.
parameter: view_label {
type: string
default_value: "The Money Zone"
}dimension: cost {
view_label: "{% parameter view_label %}"
type: number
sql: ${TABLE}.COST ;;
}
dimension: cost_ex_vat {
view_label: "{% parameter view_label %}"
type: number
sql: ${TABLE}.COST_EX_VAT ;;
}
dimension: cost_eur {
view_label: "{% parameter view_label %}"
type: number
sql: ${TABLE}.COST_EUR ;;
}
Remarque:Si vous ne souhaitez pas que les guillemets apparaissent dans le menu, parameter doit être défini sur type:unquoted, et default_value doit être une chaîne sans espaces, par exemple The_Money_Zone. Si le paramètre est type:string, les guillemets s'affichent.
Libellés de champ dynamiques
Il est possible que plusieurs groupes d'utilisateurs interprètent différemment le nom d'un champ. Par exemple, certains utilisateurs peuvent appeler la marge brute une marge opérationnelle, tandis que d'autres peuvent l'appeler une marge standard, selon leur cas d'utilisation.
Le nom d'un champ peut être différent pour chaque utilisateur en fonction de la façon dont vous combinez les attributs utilisateur et les variables Liquid.
Exemple: Étiquettes différentes pour différents attributs utilisateur
Pour extrapoler l'exemple précédent, vous pouvez tenir compte des différences de logique métier en affichant le champ Marge brute sous la forme Marge standard pour certains utilisateurs et Marge opérationnelle pour d'autres. Le code LookML suivant exploite les attributs utilisateur et les variables Liquid.
dimension: gross_margin {
label: "{% if _user_attributes['customer'] == 'A' %} Standard Margin
{% elsif _user_attributes['customer'] == 'B' %} Operating Margin
{% else %} Gross Margin
{% endif %}"
type: number
value_format_name: usd
sql: ${sale_price} - ${inventory_items.cost} ;;
}
D'après le code LookML, le champ Marge brute s'affiche sous la forme Marge opérationnelle dans un sélecteur de champs d'exploration pour l'utilisateur A.
D'après le code LookML, le champ Marge brute apparaît sous le nom Marge standard dans un sélecteur de champ d'exploration pour l'utilisateur B.
Ce modèle peut également être utilisé pour créer une localisation de bas niveau par utilisateur, comme illustré dans l'exemple suivant.
Exemple: Noms de champs personnalisés pour plusieurs explorations
Cet exemple combine les techniques des exemples précédents pour créer une exploration avec des libellés de champ qui varient en fonction de la région de l'utilisateur.
Dans cet exemple, deux équipes régionales (Finance East et Finance West) utilisent une exploration intitulée Ventes de l'entreprise. Les deux équipes doivent utiliser les métriques Bénéfice total et Revenus totaux dans leurs requêtes:
measure: total_profit {
label: "{{ _explore._name}}: Profit"
type: sum
sql: ${profit} ;;
}
measure: total_revenue {
label: "{{ _explore._name}}: Revenue"
type: sum
sql: ${sale_price} ;;
value_format_name: usd
}
Cependant, chaque équipe souhaite que le nom du champ reflète la région de son équipe.
Les développeurs peuvent afficher les noms des champs différemment pour les utilisateurs de Finance East et de Finance West. Pour ce faire, il peut utiliser DRY LookML avec les paramètres Liquid suivants:
from spécifie la vue sous-jacente des explorations.
explore_label permet d'afficher le même nom pour les deux explorations avec alias ("Ventes de l'entreprise") afin de créer une expérience d'exploration identique pour les deux équipes.
{{ _explore._name}}, qui capture et affiche le nom de l'exploration.
Les explorations:
explore: Finance_East{
from: order_items
label: "Company Sales"
view_label: "The Money Zone"
}
explore: Finance_West{
from: order_items
label: "Company Sales"
view_label: "The Money Zone"
}
Lors de l'exploration, l'équipe Finance East verra le champ Bénéfice total sous la forme Finance_East: Profit et le champ Revenus totaux sous la forme Finance_East: Revenue.
Lors de l'exploration, l'équipe Finance West verra le champ Bénéfice total sous la forme Finance_West: Profit et le champ Revenus totaux sous la forme Finance_West: Revenue.
Pour découvrir d'autres façons de personnaliser l'affichage des champs pour les utilisateurs, consultez la page de documentation Modifier le menu Exploration et le sélecteur de champs.