Design e processamento de scripts do lado do cliente

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

O processamento adequado do 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 client scripts 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ócio apropriadas ou controles de acesso para edição de lista.
• Criar políticas de dados.
• Crie um client script onCellEdit separado.

Restringir edição de lista

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

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

• Desabilite a edição de lista para a tabela.
• Crie regras de negócio apropriadas ou controles de acesso para edição de lista.
• Criar políticas de dados.
• Crie um client script onCellEdit separado.

Minimizar pesquisas de servidor

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

O script de cliente 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 de 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 por push do servidor para o cliente), enquanto o 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.

Recuperar 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 client script que precisa acessar o campo u_retrieve e o campo não estiver no formulário, os dados não estarão disponíveis para o client script. Uma solução típica para essa situação é colocar o campo no formulário e sempre ocultá-lo com um client script ou uma política de IU. Embora esta solução possa ser mais rápida de configurar, ela é mais lenta de executar.

Se você souber de quais informações o cliente precisa do servidor antes que o formulário seja carregado, uma regra de negócio de exibição poderá criar propriedades g_scratchpad para manter essas informações. Og_scratchpad é enviado ao cliente quando o formulário é solicitado, disponibilizando-o 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 forma quando o formulário estiver carregado. A regra de negócio não pode ser acionada dinamicamente. Nesses casos, use uma chamada GlideAjax assíncrona.

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 ou não anexos
• O nome do gerente do solicitante

Uma regra de negócio de exibição envia essas informações para o 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);

Recuperar dados do servidor usando GlideAjax assíncrono

O GlideAjax assíncrono permite que você solicite informações dinamicamente 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 da inclusão de script que o 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 displayValue setValue() para campos de referência

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

Ao usar setValue() em um campo de referência, certifique-se de incluir o valor de exibição do campo de referência como o terceiro parâmetro. Se você definir o valor sem o 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 setValue():

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

Use a política de IU em vez de um client script

Quando possível, considere usar uma política de IU em vez de um client script.

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

• As políticas de IU têm um campo Ordem para permitir controle total sobre a ordem na qual 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 os client scripts.

Validando a entrada usando um client script

Um excelente uso para um client script é 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 valor do campo Impacto é válido com o valor do campo Prioridade. Neste exemplo, Baixo impacto não é permitido com Alta prioridade.

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

Definir ordem de client script

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

Antes de Iniciar

Função necessária: administrador

Por Que e Quando Desempenhar Esta Tarefa

Adicionar 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 client script com o número menor 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. Configurar o layout do formulário para incluir o campo Pedido.
3. Adicione um número ao campo de pedido com base na ordem em que você deseja que ele seja executado em relação a outros client scripts.
   Escolha um número menor para o script que você deseja executar primeiro.

Evite manipulação de DOM

Evite a manipulação do DOM (Document Object Model), se possível. 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 de DOM, você precisa fazer referência a um elemento no DOM por ID ou usando um seletor de CSS. Ao fazer referência a elementos DOM prontos para uso, há um risco de que o ID do elemento ou o posicionamento no DOM possa mudar, fazendo com que o código pare de funcionar e/ou gere erros. Use a premeditação, o cuidado e tenha uma compreensão total do risco em que está incorrendo. Revise esses objetos e reduza o uso de métodos de manipulação de DOM o máximo possível.

Evite client scripts globais

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

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

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

Incluir código em funções

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

Scripts de cliente sem uma função causam problemas com o escopo da variável. Quando o código não está entre uma função, as variáveis e outros objetos ficam disponíveis e são 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");
   }
}

Como a variável de estado 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 estadode nome de variável comum. 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");
   }
}

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

Executar somente os scripts necessários

Para evitar a execução desnecessária de scripts demorados, certifique-se de que os client scripts 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 client scripts não têm um campo Condição. 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 onChange() ineficiente definido para ser executado quando o campo Item de configuração for alterado.

//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 aprimora o primeiro substituindo a pesquisa getReference() ou GlideRecord por uma chamada GlideAjax assíncrona.

//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);
}

O sinalizador isLoading é a maneira mais simples de impedir que códigos desnecessários ocupem o tempo do navegador em scripts onChange. O sinalizador isLoading deve ser usado no início de qualquer script que não precise ser executado 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. Adicionar a verificação isLoading ao script evita que ele faça uma pesquisa cmdb_ci em cada carregamento de formulário.

O sinalizador isTemplate 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 deve 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 a este script para continuar somente se houver um valor válido no campo relevante. Isso evita que o script seja executado quando o valor do campo é removido ou está 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 != oldValue.

Nota:

Este exemplo não detecta usuários alterando um valor e, em seguida, alterando-o de volta para o 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 está um nível mais profunda, reorganizando o script para verificar o máximo possível de itens 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 de servidor quando o campo assign_group 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);
}