Adição de modelos personalizados a uma sala limpa¶

1. Desenvolvimento do modelo¶

Primeiro, desenvolva o modelo e os possíveis scripts que ele chama usando apenas a API de salas limpas nas contas tanto do provedor quanto do consumidor. O teste do modelo na API é muito mais rápido e menos propenso a erros do que na UI.

Teste o seu modelo cuidadosamente na API, no lado tanto do provedor quanto do consumidor, para garantir que o ele faça exatamente o que você quer. O teste na API é muito rápido, e as alterações são propagadas imediatamente para a conta do consumidor.

Depois de testar e comprovar que seu modelo é executado exatamente como você quer, prossiga para criar o formulário de entrada.

2. Desenvolvimento do formulário de entrada¶

Quando o modelo e todos os scripts carregados estiverem funcionando como pretendido, comece a trabalhar no formulário de entrada. Neste estágio, você não usa a API na conta de provedor, mas a UI na conta de consumidor.

Quando você faz alterações usando a API, alguns valores na UI são atualizados imediatamente, alguns são atualizados quando o usuário clica em Refresh e outros são atualizados apenas a cada 10 minutos. Portanto, quando você trabalhar no formulário de entrada, crie-o e atualize-o no lado do provedor usando a API, mas instale e configure a sala limpa na conta de consumidor usando a UI de salas limpas, não a API. Isso garante que você use os dados atualizados na UI de salas limpas.

Além disso, cada vez que você fizer alterações no formulário de entrada na API, crie uma nova sala limpa para garantir que use os dados mais recentes. Use um número incremental no nome, por exemplo, «Minha sala limpa 1», «Minha sala limpa 2» e assim por diante. Em seguida, instale a sala limpa no cliente usando a UI. Por fim, exclua as salas limpas antigas porque há um limite para o número de salas limpas armazenadas na conta.

Um formulário de entrada deve ser anexado a um modelo, caso contrário, a sala limpa e o formulário não poderão ser executados na UI de salas limpas. Ao desenvolver o formulário, considere usar um modelo que apenas espelhe todos os valores selecionados no formulário para que você possa verificar quais valores são enviados para o modelo.

Por exemplo, suponha que seu modelo de produção seja parecido com este:

SELECT {{ col1 | sqlsafe | column_policy }}, {{ col2 | sqlsafe | column_policy }}
  FROM IDENTIFIER({{ source_table[0] }}) AS p
  JOIN IDENTIFIER({{ my_table[0] }}) AS c

Você pode criar o seguinte modelo para espelhar todos os valores desse modelo de produção:

SELECT
  {{ col1 | default('Undefined')}},
  {{ col2 | default('Undefined') }},
  {{ source_table[0] | default('Undefined') }},
  {{ my_table[0] | default('Undefined') }},
  {{ provider_join_col | default('Undefined') }},
  {{ consumer_join_col | default('Undefined') }}
;

Em seguida, crie um formulário que defina esses seis valores de variáveis e anexe-o ao modelo de espelho em vez do modelo de produção.

Dicas gerais para desenvolver o formulário de entrada

A seguinte lista apresenta dicas detalhadas para ajudar você a desenvolver um formulário de entrada eficaz:

• Se você receber uma mensagem genérica de «falha na instalação» ou «algo deu errado» ao instalar, configurar ou executar uma sala limpa na UI, talvez haja um erro no formulário da UI ou no modelo associado que não tenha sido capturado quando você adicionou o formulário ou o modelo.

• Quando um campo depende de outro, por exemplo, um menu suspenso de coluna que se baseia no valor escolhido em um menu suspenso de tabela, coloque o campo pai primeiro, possivelmente logo acima do campo filho, para que os usuários preencham o campo pai antes de preencherem o campo filho. Com campos dependentes, o menu suspenso filho fica vazio até um valor ser escolhido no campo pai.

• Se você não especificar um valor order ou group, os itens serão renderizados na ordem em que foram definidos.

• Inclua uma infoMessage informativa e um texto de description, além de mostrar valores de exemplo que um usuário pode inserir.

• Escolha o tipo de elemento preciso para o tipo de dados da variável. Por exemplo, para um número inteiro, escolha integer em vez de uma caixa de texto de forma livre. O modelo pode converter valores usando filtros Jinja, por exemplo: SELECT {{ max_age | int }};.

• Se você não definir um formulário de configuração mínima para um modelo personalizado, o modelo não poderá ser executado na UI de salas limpas.

• Se você não definir um elemento de formulário para uma variável no modelo, uma caixa de texto simples será renderizada para essa variável no formulário de usuário. Isso provavelmente não é o que você quer, porque a caixa de texto é identificada com o nome da variável do modelo e não tem descrição nem sugestões.

• Os elementos de formulário especificados em add_ui_form_customizations não serão renderizados, a menos que haja uma variável de modelo correspondente com o mesmo nome do elemento.

• As alterações do modelo feitas na API se propagam de forma rápida e confiável para a UI, portanto, você não precisa criar uma nova sala limpa para alterações do modelo. No entanto, você deve desenvolver e testar o modelo na API :emph: antes de chegar ao estágio da UI.

• Não é possível preencher automaticamente um menu suspenso com valores de coluna de uma determinada tabela. Você pode codificar os valores em um menu suspenso, mas não mostrar os valores de uma tabela em tempo de execução.

3. Conexão do formulário de entrada com o modelo de produção¶

Depois que o formulário estiver exatamente como você quer e tornar todas as variáveis de modelo acessíveis ao usuário, designe seu modelo de trabalho ao formulário de entrada na chamada para provider.add_ui_form_customizations.