Design e processamento de scripts no lado do cliente

Scripts de cliente bem projetados podem reduzir a quantidade de tempo que os usuários levam para preencher um formulário.

O processamento adequado no lado do cliente depende do carregamento do formulário primeiro. Fazer atualizações de registro antes do carregamento do formulário pode produzir resultados inesperados que ignoram o processamento do lado do cliente.

Se você criar scripts de cliente para controlar valores de campo em um formulário, deverá usar outro método para controlar esses valores de campo em uma lista. Você pode:

• Desabilite a edição de lista para a tabela.
• Crie regras de negócios ou controles de acesso apropriados para edição de lista.
• Crie políticas de dados.
• Crie um script de cliente onCellEdit separado.

Restringir edição de lista

Se você criar políticas de IU ou scripts de cliente para campos em um formulário, precisará usar outro método para garantir que os dados nesses campos sejam controlados da mesma forma em uma lista.

Com exceção dos scripts de cliente onCellEdit, as políticas de IU e os scripts de cliente se aplicam somente aos formulários. Use os seguintes métodos para restringir a edição de lista ao usar scripts de cliente:

• Desabilite a edição de lista para a tabela.
• Crie regras de negócios ou controles de acesso apropriados para edição de lista.
• Crie políticas de dados.
• Crie um script de cliente onCellEdit separado.

Minimize as pesquisas de servidor

Use os dados do cliente o máximo possível para eliminar a necessidade de pesquisas demoradas de servidor.

O client scripting usa dados disponíveis no cliente ou dados recuperados do servidor. As principais maneiras de obter informações do servidor são g_scratchpad e pesquisa assíncrona GlideAjax.

A principal diferença entre esses métodos é que g_scratchpad é enviado uma vez quando um formulário é carregado (as informações são enviadas do servidor para o cliente), enquanto GlideAjax é acionado dinamicamente quando o cliente solicita informações do servidor.

Nota:

GlideRecord e g_form.getReference() também estão disponíveis para recuperar informações do servidor. No entanto, esses métodos não são mais recomendados devido ao impacto no desempenho. Ambos os métodos recuperam todos os campos no GlideRecord solicitado quando a maioria dos casos requer apenas um campo.

Recupere dados do servidor usando g_scratchpad

O objeto g_scratchpad passa informações do servidor para o cliente, como quando o cliente requer informações não disponíveis no formulário.

Por exemplo, se você tiver um script de cliente que precise acessar o campo u_recover e o campo não estiver no formulário, os dados não estarão disponíveis para o script de cliente. Uma solução típica para essa situação é colocar o campo no formulário e sempre ocultá-lo com um script de cliente ou política de IU. Embora esta solução possa ser mais rápida de configurar, ela é mais lenta de executar.

Se você souber quais informações o cliente precisa do servidor antes que o formulário seja carregado, uma regra de negócios de exibição poderá criar propriedades g_scratchpad para armazenar essas informações. Theg_scratchpad é enviado para o cliente quando o formulário é solicitado, tornando-o disponível para todos os métodos de script do lado do cliente. Este é um meio muito eficiente de enviar informações do servidor para o cliente. No entanto, você só pode carregar dados dessa maneira quando o formulário é carregado. A regra de negócio não pode ser acionada dinamicamente. Nesses casos, use uma chamada assíncrona do GlideAjax.

Por exemplo, suponha que você abra um incidente e precise passar essas informações para o cliente:

• O valor da propriedade do sistema css.base.color
• Se o registro atual tem anexos ou não
• O nome do gerente do chamador

Uma regra de negócios de exibição envia essas informações ao cliente usando o seguinte script:

g_scratchpad.css = gs.getProperty('css.base.color');
g_scratchpad.hasAttachments = current.hasAttachments();
g_scratchpad.managerName = current.caller_id.manager.getDisplayValue();

Para acessar dados do bloco de anotações usando um client script:

// Check if the form has attachments
if (g_scratchpad.hasAttachments)
    // do something interesting here
else
    alert('You need to attach a form signed by ' + g_scratchpad.managerName);

Recupere dados do servidor usando GlideAjax assíncrono

GlideAjax assíncrono permite que você solicite dinamicamente informações do servidor.

Este script compara o grupo de suporte do IC e o grupo de atribuição do incidente por nome:

//Alert if the assignment groups name matches the support group
function onChange(control, oldValue, newValue, isLoading) {
 
    if (isLoading)
        return;
 
    var ga = new GlideAjax('ciCheck');
 
    ga.addParam('sysparm_name', 'getCiSupportGroup');
    ga.addParam('sysparm_ci', g_form.getValue('cmdb_ci'));
    ga.addParam('sysparm_ag', g_form.getValue('assignment_group'));
    ga.getXML(doAlert); // Always try to use asynchronous (getXML) calls rather than synchronous (getXMLWait)
}
 
// Callback function to process the response returned from the server
function doAlert(response) {
 
    var answer = response.responseXML.documentElement.getAttribute("answer");
 
    alert(answer);
}

Este script depende do script que acompanha:

var ciCheck = Class.create();
 
ciCheck.prototype = Object.extendsObject(AbstractAjaxProcessor, {
 
    getCiSupportGroup: function() {
 
        var retVal = ''; // Return value
        var ciID   = this.getParameter('sysparm_ci');
        var agID   = this.getParameter('sysparm_ag');		
        var ciRec  = new GlideRecord('cmdb_ci');
 
        // If we can read the record, check if the sys_ids match
        if (ciRec.get(ciID)) {
            if (ciRec.getValue('support_group') == agID)
                retVal = 'CI support group and assignment group match';
            else
                retVal = 'CI support group and assignment group do not match';
 
            // Can't read the CI, then they don't match
        } else {
            retVal = 'CI support group and assignment group do not match';
        }
 
        return retVal;
    }
 
});

Use o parâmetro setValue() displayValue para campos de referência

Ao usar setValue() em um campo de referência, inclua o parâmetro displayValue para evitar chamadas adicionais do servidor.

Ao usar Valor() em um campo de referência, certifique-se de incluir o valor de exibição do campo de referência como o 3º parâmetro. Se você definir o valor sem displayValue, a instância fará uma chamada síncrona para recuperar o valor de exibição do registro especificado. Essa ida e volta extra para o servidor pode afetar o desempenho.

Este exemplo demonstra a maneira incorreta de chamar setValue:

var id = '5137153cc611227c000bbd1bd8cd2005';
 
g_form.setValue('assigned_to', id); // Client needs to go back to the server to
                                    // fetch the name that goes with this ID

Em vez disso, inclua o valor de exibição como um parâmetro opcional em Valor() :

var id = '5137153cc611227c000bbd1bd8cd2005';
var name = 'Fred Luddy';
 
g_form.setValue('assigned_to', id, name); // No server call required

Use política de IU em vez de um script de cliente

Quando possível, considere o uso de uma política de IU em vez de um script de cliente.

As políticas de IU fornecem estes benefícios em relação aos scripts de cliente:

• As políticas de IU têm um Pedido campo para permitir controle total sobre a ordem em que as operações do lado do cliente ocorrem.
• As políticas de IU não exigem script para tornar um campo obrigatório, somente leitura ou visível.

Nota:

As políticas de IU se aplicam após scripts de cliente.

Validando a entrada usando um script de cliente

Um excelente uso para um script de cliente é validar a entrada do usuário.

Essa validação melhora a experiência do usuário porque o usuário descobre se há problemas de dados antes de enviar as informações.

Um exemplo de validação é verificar se o. Impacto o valor do campo é válido com Prioridade valor do campo. Neste exemplo, Impacto baixo não é permitido com prioridade alta.

if (g_form.getValue('impact') == '3' && g_form.getValue('priority') == '1')
   g_form.showFieldMsg('impact', getMessage('Low impact now allowed with High priority'), 'error');

Defina a ordem do script do cliente

Controle a ordem de execução dos scripts do cliente usando o campo Ordem. Para evitar que dois ou mais scripts de cliente sejam executados simultaneamente e, em seguida, entrem em conflito, você pode adicionar uma ordem para que os scripts sejam executados em.

Antes de Iniciar

Função necessária: administrador

Por Que e Quando Desempenhar Esta Tarefa

A adição de um pedido ao script do cliente cria uma sequência de processamento, ordenada do número mais baixo para o mais alto. Se dois scripts entrarem em conflito, o script do cliente com o número inferior será executado primeiro.

Procedimento

1. Navegar até Tudo > Definição do Sistema > Client script e abra um client script existente ou clique em Novo .
2. Configurando o layout do formulário para incluir o. Pedido campo.
3. Adicione um número ao campo Ordem com base na ordem em que você deseja que ele seja executado em relação a outros scripts de cliente.
   Escolha um número menor para o script que você deseja executar primeiro.

Evite manipulação de DOM

Se possível, evite a manipulação do modelo de objeto de documento (DOM). Isso pode causar um problema de manutenção quando os navegadores são atualizados.

Em vez disso, use a API GlideForm ou considere uma abordagem diferente para a solução. Em geral, ao usar métodos de manipulação DOM, você precisa referenciar um elemento no DOM por ID ou usando um seletor CSS. Ao fazer referência a elementos DOM prontos, existe o risco de que o ID do elemento ou o posicionamento no DOM mude, fazendo com que o código pare de funcionar e/ou gere erros. Use previsão, cautela e tenha uma compreensão completa do risco que você está incorrendo. Revise esses objetos e reduza o uso de métodos de manipulação DOM o máximo possível.

Evite scripts de cliente globais

Um script de cliente global é qualquer script de cliente em que a tabela selecionada é Global. Os scripts de cliente globais não têm restrições de tabela, portanto, eles serão carregados em todas as páginas do sistema, introduzindo atraso de carregamento do navegador no processo.

Não há benefício em carregar este tipo de scripts em todas as páginas.

Como alternativa, e para uma abordagem mais modular e escalável, considere mover scripts de cliente para uma tabela de base (como Tarefa[tarefa] ou Item de configuração[cmdb_ci]) que pode ser derivada para todas as tabelas secundárias/estendidas. Isso elimina o carregamento do sistema dos scripts em todos os formulários na IU, como páginas iniciais ou Catálogo de serviços, onde raramente (se alguma vez) são necessários.

Inclua o código em funções

Coloque o código em um script de cliente dentro de uma função.

Os scripts de cliente sem uma função causam problemas com o escopo variável. Quando o código não está incluído em uma função, variáveis e outros objetos ficam disponíveis e compartilhados com todos os outros scripts do lado do cliente. Se você estiver usando os mesmos nomes de variáveis, é possível que eles possam colidir. Isso pode levar a consequências inesperadas que são difíceis de solucionar.

Considere este exemplo:

var state = "6";
 
function onSubmit() {
 
   if(g_form.getValue('incident_state') == state) {
   		alert("This incident is Resolved");
   }
}

Porque estado a variável não está incluída em uma função, todos os scripts do lado do cliente têm acesso a ela. Outros scripts também podem usar o nome de variável comum estado . Os nomes duplicados podem entrar em conflito e levar a resultados inesperados. Esses problemas são difíceis de isolar e resolver. Para evitar esse problema, certifique-se de que todo o código esteja encapsulado em uma função:

function onSubmit() {
 
   var state = "6";
 
   if(g_form.getValue('incident_state') == state) {
   		alert("This incident is Resolved");
   }
}

Esta solução é muito mais segura devido ao escopo da variável estado Está limitado à função onSubmit(). Portanto, o. estado a variável não entra em conflito com estado variáveis em outros scripts do lado do cliente.

Execute somente os scripts necessários

Para evitar a execução desnecessária de scripts demorados, certifique-se de que os scripts de cliente executem somente as tarefas necessárias.

Os exemplos a seguir demonstram melhorias na amostra de código inicial. Cada exemplo demonstra um aprimoramento específico do script para melhorar o desempenho e evitar chamadas desnecessárias.

Lembre-se de que os scripts de cliente não têm Condição campo. Isso significa que os scripts onLoad() e onChange() são executados integralmente sempre que o formulário apropriado é carregado. Este exemplo é um script de cliente ineficiente onChange() definido para execução quando o. Item de configuração mudanças de campo.

//Set Assignment Group to CI's support group if assignment group is empty
function onChange(control, oldValue, newValue, isLoading) {
 
    var ciSupportGroup = g_form.getReference('cmdb_ci').support_group;
 
    if (ciSupportGroup != '' && g_form.getValue('assignment_group) != '')
        g_form.setValue('assignment_group', ciRec.support_group.sys_id);
}

Este exemplo melhora o primeiro substituindo a pesquisa getReference() ou GlideRecord por uma chamada assíncrona GlideAjax.

//Set Assignment Group to support group if assignment group is empty
function onChange(control, oldValue, newValue, isLoading) {
 
    var ga = new GlideAjax('ciCheck');
 
    ga.addParam('sysparm_name', 'getSupportGroup');
    ga.addParam('sysparm_ci', g_form.getValue('cmdb_ci'));
    ga.getXML(setAssignmentGroup);
}
 
function setAssignmentGroup(response) {
 
    var answer = response.responseXML.documentElement.getAttribute("answer");
 
    g_form.setValue('assignment_group', answer);
}

. isLoadingO sinalizador é a maneira mais simples de evitar que código desnecessário ocupe o tempo do navegador em scripts onChange. . isLoadingo sinalizador deve ser usado no início de qualquer script que não seja necessário executar quando o formulário estiver sendo carregado. Não há necessidade de executar este script em um carregamento de formulário porque a lógica já teria sido executada quando o campo foi alterado pela última vez. Adicionando o. isLoadinga verificação do script impede que ele faça uma pesquisa cmdb_ci em cada carregamento de formulário.

. isTemplateo sinalizador indica que um modelo está sendo carregado.

//Set Assignment Group to CI's support group if assignment group is empty
function onChange(control, oldValue, newValue, isLoading, isTemplate) {
 
    if (isLoading)
        return;
 
    var ga = new GlideAjax('ciCheck');
 
    ga.addParam('sysparm_name', 'getSupportGroup');
    ga.addParam('sysparm_ci', g_form.getValue('cmdb_ci'));
    ga.getXML(setAssignmentGroup);
}
 
function setAssignmentGroup(response) {
 
    var answer = response.responseXML.documentElement.getAttribute("answer");
 
    g_form.setValue('assignment_group', answer);
}

Se o script onChange precisar ser executado durante o carregamento, use a seguinte convenção:

function onChange(control, oldValue, newValue, isLoading, isTemplate) {
 
    if (isLoading) {}; // run during loading
 
    // rest of script here
 
}

A verificação newValue informa este script para continuar somente se houver um valor válido no campo relevante. Isso impede que o script seja executado quando o valor do campo é removido ou deixado em branco. Isso também garante que sempre haverá um valor válido disponível quando o restante do script for executado.

//Set Assignment Group to CI's support group if assignment group is empty
function onChange(control, oldValue, newValue, isLoading, isTemplate) {
 
    if (isLoading)
        return;
 
    if (newValue) {
        var ga = new GlideAjax('ciCheck');
 
        ga.addParam('sysparm_name', 'getSupportGroup');
        ga.addParam('sysparm_ci', g_form.getValue('cmdb_ci'));
        ga.getXML(setAssignmentGroup);
    }
}
 
function setAssignmentGroup(response) {
 
   var answer = response.responseXML.documentElement.getAttribute("answer");
 
   g_form.setValue('assignment_group', answer);
}

Para que o script reaja a um valor que muda após o carregamento do formulário, use a verificação newValue.

Nota:

Este exemplo não detecta usuários alterando um valor e, em seguida, alterando-o de volta para seu valor original.

//Set Assignment Group to CI's support group if assignment group is empty
function onChange(control, oldValue, newValue, isLoading, isTemplate) {
 
    if (isLoading)
        return;
 
    if (newValue) {
        if (newValue != oldValue) {
            var ga = new GlideAjax('ciCheck');
 
            ga.addParam('sysparm_name', 'getSupportGroup');
            ga.addParam('sysparm_ci', g_form.getValue('cmdb_ci'));
            ga.getXML(setAssignmentGroup);
        }
    }
}
 
function setAssignmentGroup(response) {
 
   var answer = response.responseXML.documentElement.getAttribute("answer");
 
   g_form.setValue('assignment_group', answer);
}

Neste exemplo, a chamada GlideAjax é enterrada um nível mais profundo, reorganizando o script para verificar o máximo possível de coisas disponíveis para o cliente antes de executar as chamadas do servidor. O script verifica a atribuição antes de executar a chamada GlideAjax. Isso impede a pesquisa do servidor quando o. assignment_group o campo já está definido.

//Set Assignment Group to CI's support group if assignment group is empty
function onChange(control, oldValue, newValue, isLoading, isTemplate) {
 
    if (isLoading)
       return;
 
    if (newValue) {
        if (newValue != oldValue) {
            if (g_form.getValue('assignment_group') == '') {
                var ga = new GlideAjax('ciCheck');
 
                ga.addParam('sysparm_name', 'getSupportGroup');
                ga.addParam('sysparm_ci', g_form.getValue('cmdb_ci'));
                ga.getXML(setAssignmentGroup);
            }
        }
    }
}
 
function setAssignmentGroup(response) {
 
   var answer = response.responseXML.documentElement.getAttribute("answer");
 
   g_form.setValue('assignment_group', answer);
}