Verificação do cliente
Se a sua página tiver autenticação de cliente ativada, ocorre uma sequência de eventos completamente diferente durante a viagem de ida e volta. A autenticação do cliente é implementada usando o cliente JScript®. Não são necessários componentes binários para implementar essa verificação.
Embora a linguagem JScript seja bem padronizada, não há padrão amplamente adotado para o modelo de objeto de documento (DOM) usado para interagir com documentos HTML no navegador. Portanto, a autenticação do cliente é realizada apenas no Internet Explorer 4.0 e posterior porque o objeto de autenticação é o Internet Explorer DOM.
Do ponto de vista do servidor, a verificação do cliente significa apenas que o controle de verificação envia conteúdo diferente para HTML. Fora isso, sua sequência de eventos é exatamente a mesma. A verificação do lado do servidor ainda é executada. Embora possa parecer redundante, é muito importante porque:
Alguns controles de verificação podem não suportar scripts do cliente. Há um bom exemplo: se você deseja usar as funções de verificação do CustomValidator e do servidor, mas não há função de verificação do cliente.
Precauções de segurança. Algumas pessoas podem facilmente obter uma página com scripts e desativar ou alterar essa página. Você não deve usar scripts para impedir que dados ruins digitem seu sistema, mas apenas para obter feedback mais rápido dos usuários. Portanto, se você deseja usar o CustomValidator, não deve fornecer uma função de verificação do cliente sem a função de verificação do servidor correspondente.
Cada controle de verificação garante que um bloco de script do cliente padrão seja enviado para a página. Na verdade, esta é apenas uma pequena parte do código que contém referências ao código na biblioteca de scripts webuivalidation.js. Este arquivo da biblioteca de scripts contém toda a lógica para a verificação do cliente.
Sobre a biblioteca de scripts
Como o script de controle da Web de verificação está na biblioteca de scripts, não é necessário enviar todo o código verificado diretamente para a página, embora pareça estar fazendo isso na superfície. As principais referências de arquivo de script são assim:
<Script Language = "JavaScript"
src = "/_ ASPX/1.0.9999/script/webuivalidation.js"> </script>
Por padrão, o arquivo de script está instalado no diretório raiz padrão no diretório "_aspx" e é chamado com o script de raízes inclui a diretiva, que começa com uma barra para a frente. Esta referência indica que cada objeto individual não precisa conter uma biblioteca de scripts e todas as páginas no mesmo computador podem fazer referência ao mesmo arquivo. Você notará que também existe um número de versão de tempo de execução do idioma comum neste caminho para que diferentes versões de tempo de execução possam ser executadas no mesmo computador.
Se você olhar para o seu diretório raiz virtual padrão, encontrará o arquivo e verá o conteúdo dele. A localização desses arquivos é especificada no arquivo config.web. O arquivo config.web é um arquivo XML para a maioria das configurações ASP+. A seguir, é apresentada a definição do local no arquivo:
<WebControls
CLEERSCRIPTSLOCATION = "/_ ASPX/{0}/script/"
/>
Você é incentivado a ler o roteiro para obter informações sobre o que aconteceu. No entanto, é recomendável que você não modifique esses scripts, pois a funcionalidade deles está intimamente ligada a versões específicas de tempo de execução. Quando a versão de tempo de execução é atualizada, esses scripts também podem exigir atualizações correspondentes e você abandonará as alterações ou enfrentará o problema de que o script não funciona. Se um projeto específico deve alterar esses scripts, faça backup dos scripts primeiro e depois aponte seu projeto para o arquivo de backup, substituindo o local desses arquivos por um arquivo privado Config.Web. Se a sequência contiver a instrução de formato "{0}", o número da versão do tempo de execução substituirá a instrução. É melhor alterar esse local para uma referência relativa ou absoluta.
Desative a autenticação do cliente
Às vezes você pode não querer autenticação do cliente. Se o número de campos de entrada for pequeno, a verificação do cliente pode ser de pouco uso. Afinal, você precisa ter uma lógica que precise viajar de e para o servidor uma vez sempre. Você descobrirá que as informações que aparecem dinamicamente no cliente terão um impacto negativo no seu layout.
Para desativar a autenticação do cliente, use a diretiva da página "ClientTarget = Downlevel". Esta diretiva é semelhante ao início do seguinte arquivo ASPX:
< %@ Page Language = "C#" ClientTarget = Downlevel %>
O valor padrão desta diretiva é "Auto", o que significa que você executa apenas a autenticação do cliente para o Microsoft Internet Explorer 4.0 ou posterior.
NOTA: Infelizmente, na versão beta 1, esta diretiva não desativa simplesmente a verificação, mas também faz com que todos os controles da Web sejam processados usando tags HTML 3.2, o que pode produzir resultados inesperados. A versão final fornece uma maneira melhor de controlar esse problema.
Sequência de eventos do cliente
Esta sequência é uma sequência de eventos que ocorrem ao executar uma página contendo validação do cliente:
Quando a página é carregada no navegador, cada controle de verificação precisa ser inicializado em algum momento. Esses controles são enviados como tags <span> e seus atributos HTML são mais próximos dos do servidor. Mais importante ainda, todos os elementos de entrada referenciados pelo validador são "montados" neste momento. O elemento de entrada referenciado modificará seus eventos do cliente para que a rotina de verificação seja chamada sempre que a entrada muda.
O código na biblioteca de script será executado quando o usuário alternar entre os campos usando a tecla TAB. Quando um campo separado muda, a condição de verificação é reavaliada, tornando o validador visível ou invisível conforme necessário.
Quando o usuário tenta enviar um formulário, todos os validadores são reavaliados. Se todos esses validadores forem válidos, o formulário será enviado ao servidor. Se houver um ou mais erros, ocorrerão as seguintes situações:
A submissão foi cancelada. O formulário não é enviado ao servidor.
Todos os validadores inválidos são visíveis.
Se um resumo de verificação contiver showsummary = true, todos os erros do controle de verificação serão coletados e seu conteúdo será atualizado com esses erros.
Se um resumo de verificação contiver showMessageBox = true, os erros serão coletados e exibidos na caixa de informações do cliente.
Como os controles de verificação do cliente são executados sempre que uma alteração é inserida ou enviada, esses controles de verificação geralmente são avaliados no cliente duas ou mais vezes. Observe que, após o envio, esses controles de verificação ainda serão reavaliados no servidor.
API do cliente
Há uma pequena API que pode ser usada na máquina cliente para obter vários efeitos em seu próprio código de cliente. Como algumas rotinas não podem ser ocultas, em teoria, você pode aproveitar o cliente para verificar todas as variáveis, recursos e funções definidas pelo script. No entanto, muitos deles são detalhes de implementação que podem ser alterados. A seguir, resume os objetos do cliente que o incentivamos a usar.
Tabela 3. Objetos do cliente
Nome Tipo Descrição
A variável booleana Page_isValid indica se a página é atualmente válida. O script de verificação sempre mantém a variável atualizada.
Page_Validators Matriz de elementos Esta é uma matriz que contém todos os validadores na página.
A variável booleana Page_ValidationActive indica se a verificação deve ser executada. Definir essa variável como false pode ser desligada pela programação.
Propriedade booleana ISVALID Cada validador do cliente possui essa propriedade indicando se o validador é atualmente válido. Observe que, na versão PDC, esta propriedade é misturada com maiúsculas e minúsculas ("IsValid").
Ignorando a autenticação do cliente
Uma tarefa que você geralmente precisa executar é adicionar um botão de cancelamento ou botão de navegação na página. Nesse caso, convém enviar a página usando o botão, mesmo que haja um erro na página. Como o botão do cliente "OnClick" ocorre antes do evento "Onsubmit" do formulário, ele pode evitar enviar cheques e ignorar a verificação. A seguir, descreve como concluir a tarefa usando o controle de imagem HTML como o botão Cancelar:
<Tipo de entrada = imagem runat = servidor
value = "Cancelar"
ONSERVERCLICK = CMDCANCEL_CLICK>
A execução dessa tarefa usando o botão ou o controle do button causará alguma confusão porque o evento "OnClick" é considerado um evento do lado do servidor com o mesmo nome. Você deve definir o evento no script do cliente:
<ASP: ImageButton Runat = ID do servidor = CMDIMGCANCEL
AlternateText = "Cancelar"
OnClick = cmdcancel_click/>
<Script Language = "JavaScript">
document.all ["cmdimgcancel"]. OnClick =
nova função ("Page_ValidationActive = false;");
</script>
Outra maneira de resolver esse problema é definir o botão Cancelar para não acionar o evento commit no script do cliente quando ele retornar. Os controles htmlinputbutton e linkbutton são exemplos disso.
Efeitos especiais
Outro requisito comum é que, no caso de um erro, além da mensagem de erro exibida pelo próprio validador, são necessários outros efeitos. Nesse caso, quaisquer modificações que você fizer devem ser feitas simultaneamente no servidor ou cliente. Suponha que você precise adicionar um rótulo para alterar a cor, dependendo se a entrada é válida ou não. Aqui está como implementar esta tarefa no servidor:
classe pública ChanGecolorpage: Página {
Public Label Lblzip;
Valzip Public RegularExpressionValidator;
Substituição protegida Void OnLoad (EventArgs e) {
lblzip.forecolor = valzip.isvalid?
}
}
Todos os métodos acima são perfeitos, mas, desde que você modifique a verificação mencionada acima, você descobrirá que, a menos que faça o mesmo no cliente, ele parecerá muito inconsistente. A estrutura de verificação o impedirá de muitos desses efeitos duplos, mas não pode evitar outros efeitos que você deve alcançar simultaneamente no cliente e no servidor. Aqui está um trecho de executar a mesma tarefa no cliente:
<ASP: Rótulo ID = lblzip runat = servidor
Text = "Código ZIP:"/>
<asp: textbox ID = txtzip runat = servidor
/> </asp: textbox> <br>
<asp: regularexpressionValidator id = valzip runat = servidor
ControlTovalidate = txtzip
ErrorMessage = "Código postal inválido"
ValidationExpression = "[0-9] {5}" /> <br>
<idioma do script = javascript>
função txtziPonchange () {
// Se a autenticação do cliente não estiver ativa, nenhuma ação será executada
if (typeof (page_validators) == "indefinido") retornar;
// altere a cor do rótulo
lblzip.style.color = valzip.isvalid?
}
</script>
API do cliente beta 1
Para a versão beta 1, algumas funções que podem ser chamadas dos scripts do cliente podem causar outras situações.
Tabela 4. Funções chamadas de scripts do cliente
Descrição do nome
ValidatorValidate (VAL) toma um validador do cliente como entrada. Faça o validador verificar sua entrada e atualizar sua tela.
O Validatorenable (Val, Enable) recebe um validador de cliente e um valor booleano. Ativar ou desativar o validador do cliente. Se desativado, o validador do cliente não será avaliado e o validador do cliente sempre aparecerá como válido.
ValidatorHookUpControl (Control, Val) Obtém um elemento HTML de entrada e um validador de cliente. Modifique ou crie o evento de alteração para esse elemento para que o validador seja atualizado quando mudar. Esta função é adequada para validadores personalizados com base em vários valores de entrada.
Seu objetivo especial é ativar ou desativar o validador. Se você deseja que a verificação seja efetiva apenas em uma situação específica, pode ser necessário alterar o status de ativação no servidor e no cliente; caso contrário, você descobrirá que o usuário não pode enviar a página.
A seguir, é apresentado o exemplo acima, mais um campo que é validado apenas quando uma caixa de seleção não é controlada.
classe pública condicional: página {
public htmlinputcheckbox chksameas;
public requeryfieldValidator rfvalshipAddress;
substituição protegida void valid () {
BOOL Enableship =! Chksameas.Checked;
rfvalshipAddress.enabled = ativação;
base.Validate ();
}
}
Aqui está o código equivalente ao cliente:
<Tipo de entrada = Caixa de seleção Runat = ID do servidor = Chksameas
> O mesmo que endereço de pagamento <br>
<idioma do script = javascript>
função onchangesameas () {
var ativador =! event.srcelement.status;
Validatorenable (rfvalshipAddress, ativação);
}
</script>