Telescope (core)

Padronização dos nomes das regras de negócio

ADS.FAQ-23290
O uso de uma padrão nos nomes das regras de negócio auxilia no desenvolvimento facilitando a identificação dos objetivos de cada regra e facilitando o entendimento dos desenvolvedores. O nome da regra irá gerar um método no código. Os nomes das regras de negócio devem:

Segue abaixo o padrão sugerido:

AJUSTAR_AUTOCOMPLETE_X

Regra utilizada para ajustar a forma com que o sistema irá autocompletar o campo "X". Esta regra é utilizada quando se deseja, por exemplo, filtrar o autocomplete com os dados que estão em outro campo.
Eventos:

Maiores detalhes podem ser optidos em Como customizar um autocomplete dinamicamente por regra de negócio?.

AJUSTAR_X - Ajustar as características de X

Método que ajusta características de um campo, tais como, visibilidade, editabilidade, sufixos, prefixos, labels, cores, etc.
Este tipo de regra é normalmente chamado pelos eventos:
E caso o ajuste seja dependente de algum campo, também são disparado nos eventos


AJUSTAR_CAMPOS_CFE_X - Ajustar campos conforme X

Métodos que ajustam a visibilidade, editabilidade, obrigatoriedade, labels, sufixo, prefixo, etc de vários campos conforme uma condição.
Este tipo de método normalmente é chamado pelos eventos:

Exemplos:
AJUSTAR_CAMPOS_CFE_TIPO_PEDIDO - Ajustar campos conforme o tipo de pedido

Muitas vezes, a implementação deste regra será simplesmente a chamada de várias regras tipo AJUSTAR_X, cada uma ajustando um campo específico conforme a condição.


ALERTAR_X

Regra que por objetivo gerar um alerta para o usuário.
Ex:


ATUALIZAR_X

Regra que atualiza alguma informação em outra entidade.

Exemplos:


APRESENTAR_X

Regra utilizada quando uma condição especial exige a apresentação de uma mensagem especial para o usuário. Não se deve utilizar regras com esta nomenclatura para campos normais (mesmo que calculados) do contexto. Nestes casos, prefira regras CALCULAR...
A mensagem pode ser apresentada de inúmeras formas:

A regra deve ser chamada através dos eventos:

Exemplos:


BLOQUEAR_X

Regra que bloqueia o usuário de fazer determinadas coisas baseado em algum critério.

Exemplos:



CALCULAR_X - Calcular o valor para X

Método que calcula o valor de um campo. Apesar do nome sugerir um número, pode ser de qualquer tipo: número, data, texto, etc.
Este tipo de regra é normalmente chamado pelos eventos:
E caso o valor seja dependente de algum campo, também são disparadas nos eventos
Em determinados casos, esta regra também pode ajustar características do campo, tais como visibilidade, editabilidade e opções.
Quando conveniente, este tipo de regra também pode calcular mais do que um campo. Isso deve ser realizado apenas quando os campos estão relacionados entre si e podem ser calculados juntos e nos mesmos eventos. Isso pode ser importante em casos de ganho de performance e inteligibilidade de código.

FILTRAR_X - Filtrar X

Regra que adiciona algum tipo de filtro à query que não é gerado automaticamente através de itens da entidade base.
Este tipo de regra é normalmente utilizado para situações como filtros de elementos indiretos definidos por entidades (1-N) informados através de itens UNBOUND_CUSTOM.

Evento:

LER_X

Método utilizado para preencher um campo unbound "X" com informações persistidas em outras entidades e que devam passar a ideia de como se fosse um campo comum da mesma. Quando o campo "X" é editável, este método vem acompanhado de um método SALVAR_X.

Exemplos:

LIMPAR_FILTROS

Método que limpa os filtros de uma pesquisa quando é informado algum elemento que elimine a razão de existir os demais filtros. Normalmente isso ocorre quando se informa uma chave única como filtro. Neste caso, é comum um código nos seguintes moldes: 
clearQueryFilters(qPedido, qNumeroDocumento);

PESQUISAR_X

Este tipo de regra é utilizado quando uma determinada informação deve ser pesquisada e algum tipo de ação deve ser tomado em função desta pesquisa. Normalmente as ações são ajustar de determinados campos de acordo com o resultado. Esta regra é quase igual ao AJUSTAR_CAMPOS_CFE_X. A diferença é que este regra pode envolver uma pesquisa mais complexa sobre a informação.
Este tipo de método normalmente é chamado pelos eventos:
Exemplos:

POPULAR_X - Popular opções para X

Método que popula as opções disponíveis para um determinado campo (tipo OPCAO, SELECTION_CHECK, etc).
Este tipo de método é normalmente chamado pelos eventos:
E caso as opções sejam dependentes de algum campo, também são disparadas nos eventos
Em determinadas situações, este tipo de regra pode também sugerir um valor para o campo (em especial quando o valor atual não faz parte da nova lista de opções).

É muito importante documentar, na descrição do campo, como ele é populado de forma que o usuário final possa entender qual o critério utilizado na formação das opções disponíveis.


SALVAR_X

Regra utilizada para persistir alguma informação fora da entidade base. É comum quando existe um campo UNBOUD que apresenta informações que deverão ser persistidas em outras entidades. Muito comum quando temos entidades associativas representadas em campos tipo SELECTION_CHECK, SELECTION_BOX, etc.
Neste caso "X" é o nome de um ou mais campos.
Normalmente, a existência de um método SALVAR_X vem acompanhado de um método LER_X.


Exemplos:


SUGERIR_X - Sugerir X

Regra que sugere um valor para um ou mais campos da interface. Esta regra é normalmente disparada nos eventos:
E caso as opções sejam dependentes de algum campo, também são disparadas nos eventos
Note que este tipo de regra não impõe o valor. Ela apenas sugere um valor que pode ser alterado pelo usuário.


VALIDAR_X - Validar X

Regra que verifica se um valor ou uma combinação de valores é permitida. Este tipo de regra deve ser chamada em eventos como:
Estas regras também podem ser utilizadas de forma interativa enquanto o usuário informa os campos na interface. Nestes casos, a implementação da regra deve registrar ou limpar) mensagens de erro nos campos que possuem valores inválidos.

Exemplos:


VERIFICAR_X

Este tipo de regra verifica uma determinada situação e dependendo do resultado, toma uma ação.
Note que as regras tipo VALIDAR, geram mensagens de erro, evitando situações que não são permitidas.

Exemplos:


REMOVER_X

Regra utilizada para excluir alguma ação específica de acordo com alguma condição. Em geral, a mesma regra será executada em
Eventos:

Exemplos:


Ver também