Na aprovação da explicação ASP+ Verificação
Anthony Moore
Microsoft Corporation
Outubro de 2000
Resumo: Explicações detalhadas para o uso do controle da Web ASP+ Verificação.
Índice
Breve introdução
começando
Quando isso acontece?
Sequência de verificação no lado do servidor
Verificação do cliente
Regras eficazes e informações úteis de erro
Funções de propriedades habilitadas, visíveis e de exibição
Controle CustomValidator
Quais controles podem ser verificados?
Fim
--------------------------------------------------- ------------------------------------------------------ --------------------------
Breve introdução
Este artigo explica o método de trabalho de controle de verificação ASP+ em detalhes. Se você deseja gerar uma página complexa que contém o controle de verificação ou para expandir a estrutura de verificação, é recomendável que você leia este artigo. Se você quiser aprender a usar o controle de verificação ou decidir se deseja usar o controle de verificação, consulte "ASP+ Usuário, insira a verificação (inglês)".
começando
Sabemos que é importante entender a verificação durante todo o processo de desenvolvimento ASP+. Veja a maioria dos sites comerciais de hoje, você descobrirá que existem muitas formas nesses sites, que são obviamente executados executando um grande número de código manuscrito. Escrever o código de verificação não é um trabalho interessante. Se você escrever um código para exibir a tabela de dados ou gerar dinamicamente gráficos, ele pode ser muito atraente, mas ninguém pode confirmar com seus colegas que esse método "legal" pode proibir o valor vazio no campo Nome.
Por outros motivos, a verificação de aplicativos da Web também é muito problemática. O HTML 3.2 tem muitas restrições ao conteúdo que você pode controlar ou feedback que você pode obter do usuário, para que não possa ser aplicado às técnicas que possam ser usadas em um cliente mais gratificante, como proibir os usuários de inserir determinados caracteres ou fazendo um som. O uso do script do navegador pode produzir uma verificação mais poderosa. No entanto, esse método é difícil de confirmar, porque o navegador do cliente não é necessariamente script, e usuários maliciosos podem ignorá -lo. Portanto, para garantir a segurança do site, é necessário executar a mesma inspeção do servidor.
Ao desenvolver asp+, nossa intenção original é usar apenas um controle para processar a verificação. Mas quando foi projetado, descobri que esse desejo não poderia ser alcançado. Pesquisamos um grande número de formulários de entrada de dados para encontrar uma solução que possa ser aplicada ao maior número possível de formas. Descobrimos que a tabela de entrada de dados tem muitos recursos interessantes:
Embora as informações ou ícones de erro sejam frequentemente adjacentes aos elementos de entrada, eles estão quase sempre localizados em diferentes células da tabela.
Muitas vezes, há uma área na página para resumir todos os erros.
Muitos sites incluem scripts clientes para fornecer feedback mais rápido, impedindo a viagem entre o servidor em vão.
Muitos sites que contêm scripts do cliente exibem caixas de informação quando há um erro.
Não apenas a entrada de texto será verificada, mas também a lista de queda e o botão de seleção única será verificada.
Se um campo estiver vazio, o site geralmente mostra informações ou ícones diferentes quando a entrada é inválida.
Muitos exames eficazes podem ser bem substituídos por expressões comumente usadas.
A verificação geralmente é baseada nos resultados da comparação entre duas entradas.
90% ou mais de 90% das tarefas de verificação são algumas operações comuns, como o nome da verificação ou o código postal. A maioria dos sites ainda parece estar repetindo essas tarefas.
Como a diferença entre os sites é geralmente muito grande, uma solução perfeita não pode ser obtida para lidar com todas as tarefas de verificação de cada site.
Considerando todas as situações acima, as soluções finais incluem cinco controles de dispositivo de verificação, controles de validação e integração com objetos de página. Ao mesmo tempo, é óbvio que a solução precisa ser expandida e uma API é necessária para cooperar no cliente e no servidor.
Descobrimos que parecíamos precisar de uma caixa de ferramentas maior durante as várias verificações da pesquisa. Na maioria dos ambientes de componentes, como o Microsoft® ActiveX®, podemos ter tentado integrar as funções de todos os controles de verificação em um controle para processar diferentes atributos em diferentes modos. Felizmente, há herança mágica na estrutura do Microsoft® .NET.
A maioria desses controles é implementada em seus pais públicos de nível BaseValidator. Você também pode concluir várias tarefas do BaseValidator ou outros controles. De fato, mesmo que o BaseValidator seja com preguiça de obter seus próprios atributos de texto, ele é herdado dos atributos do rótulo.
Quando isso acontece?
É muito eficaz entender a sequência do evento ao processar a página que contém a página do controle da Web. Se uma condição de verificação for opcional, você precisará entender com precisão quando o cliente e o servidor são verificados. Se você deseja escrever uma rotina de verificação, pode ser muito tempo -consumindo efeitos colaterais. Ao mesmo tempo, também é importante entender o momento da rotina de verificação de chamadas.
Primeiro, vamos dar uma olhada no servidor.
Sequência de verificação no lado do servidor
É importante entender o período de validade da página. Se você estiver acostumado a processar o formulário no Visual Basic ou ferramentas funcionais similares, precisará gastar um certo tempo para entender. Todos os objetos na página e na página não são eficazes ao interagir com os usuários, embora às vezes isso seja o mesmo.
A seguir, é apresentada uma sequência de eventos simplificada ao visitar uma página pela primeira vez:
Crie uma página e seu controle com base no arquivo ASPX.
Acionando o evento Page_load.
Os atributos de página e controle são armazenados em um campo oculto.
Páginas e controles são convertidos em HTML.
Descarte tudo.
Agora, quando o usuário clicar em um botão ou um controle semelhante, ele retornará ao servidor e executará uma sequência de eventos semelhante. Esta sequência é chamada de sequência de retorno:
Crie uma página e seu controle com base no arquivo ASPX.
Restaure os atributos da página e controle do campo oculto.
Digite o controle da página de atualização de acordo com o usuário.
Acionando o evento Page_load.
Trigger Alterações de Eventos de Notificação.
Os atributos de página e controle são armazenados em um campo oculto.
Páginas e controles são convertidos em HTML.
Descarte tudo de novo.
Por que não mantemos todos os objetos na memória? Porque os sites estabelecidos com o ASP+ não podem lidar com um número muito grande de usuários. Portanto, a memória do servidor mantém apenas o conteúdo a ser processado imediatamente.
Quando é a verificação do servidor? Ao obter informações da página pela primeira vez, a verificação do servidor -lado não será executada. A maioria dos usuários finais é muito grave.
Na sequência de eventos de retorno, a verificação será realizada entre a Etapa 3 e a Etapa 4. Em outras palavras, a verificação é após os atributos de controle de carregamento de dados do usuário, mas antes da maior parte do número de execução de código. Isso significa que, ao escrever eventos do usuário, geralmente pode ser usado para verificação. Em circunstâncias normais, você deseja fazer isso.
A desvantagem da verificação naquele momento é: se você deseja modificar alguns atributos que afetam a verificação por programação, será tarde demais. Por exemplo, você descobrirá que, se usar o código para ativar ou desativar os atributos do controle de verificação ou modificar o controle de verificação, não verá nenhum efeito antes de processar a página. Este problema pode ser evitado pelos dois métodos a seguir:
Modifique o atributo antes da verificação.
Re -verifique o controle após a alteração do atributo.
Ambos os métodos precisam usar atributos e métodos de verificação eficazes no objeto da página.
API da página
Os objetos da página incluem alguns atributos e métodos importantes relacionados à verificação do servidor. A Tabela 1 resume esses atributos e métodos:
Tabela 1. Atributos e métodos do objeto da página
Descrição do atributo ou método
O atributo isValid é o atributo mais útil. Este atributo pode verificar se todo o formulário é eficaz. Esta verificação geralmente é realizada antes de atualizar o banco de dados. Somente todos os objetos dos validadores são válidos, o atributo é verdadeiro e o valor não é armazenado no cache.
Os validadores atribuem a coleção de todos os objetos de verificação desta página. Esta é uma coleção de objetos que implementam a interface do IVALIDADOR.
O método do valor chama um método quando a verificação. O método de execução padrão no objeto da página é recorrer a cada dispositivo de verificação e exigir que o dispositivo de verificação se avalie.
A coleção de validadores é muito útil para muitas tarefas. Este conjunto é uma coleção de objetos que implementam a interface do Iivalidator. A razão pela qual eu uso o objeto não é o controle do controle, porque o objeto da página presta atenção apenas à interface do IVALIDADOR. Como todas as verificações são geralmente usadas para obter alguns controles visuais do IVALIDADOR, qualquer um deve poder usar qualquer objeto de verificação e adicionar o objeto de verificação à página.
A interface IValidator contém os seguintes atributos e métodos:
Tabela 2. Os atributos e métodos da interface do IVALIDADOR
Descrição do atributo ou método
O atributo ISValid apontou se o teste de validade realizado por um objeto de verificação separado passou. Você pode alterar manualmente o valor após a verificação.
O atributo errorMessage apresenta o erro para verificar o objeto a ser verificado e os erros que podem ser exibidos ao usuário.
O método Validate é verificado quanto à validade do objeto de verificação para atualizar seu valor ISValid.
Você pode usar essa interface para executar algumas tarefas interessantes. Por exemplo, para redefinir a página para um estado eficaz, use o código a seguir (como o exemplo mostrado em C#):
Valor do IValidator;
Foreach (Val em validadores) {
valueValid = true;
}
Para re -executar toda a sequência de verificação, use o seguinte código:
Valor do IValidator;
Foreach (Val em validadores) {
Val.validate ();
}
Se você tiver uma edição beta 1 ou versões superiores, também poderá chamar o método do valor apenas para o objeto da página, para que a mesma tarefa possa ser concluída. Para fazer algumas alterações antes da verificação, o método do valor pode ser coberto. Este exemplo mostra uma página que contém o dispositivo de verificação, que é aberto ou desligado de acordo com o valor da caixa de seleção:
Classe pública condicional: página {
public htmlinputcheckbox chksameas;
Public ResearchFieldValidator RfvalshipAddress;
Substituição protegida void validate () {) {)
// Basta verificar o endereço de entrega (se diferente do endereço de pagamento)
BOOL Enableship =!
rfvalshipAddress.enabled = ativação;
// agora executando a verificação
base.Validate ();
}
}
Verificação do cliente
Se a sua página for ativada pela verificação do cliente, uma sequência de eventos completamente diferente ocorrerá durante a viagem de ida e volta. A verificação do cliente usa o cliente JScript®. A verificação não requer componentes binários.
Embora a padronização da linguagem JScript seja bem feita, o Modelo de Objeto de Document (DOM) usado na documentação HTML no navegador (DOM) não tem padrões amplamente utilizados. Portanto, a verificação do cliente é realizada apenas no Internet Explorer 4.0 e nas versões superiores, porque o objeto verificado é o Internet Explorer DOM.
Da perspectiva do servidor, a verificação do cliente significa apenas que o controle de verificação envia conteúdo diferente para HTML. Além disso, a sequência de incidentes é exatamente a mesma. A verificação do servidor ainda é executada. Embora pareça redundante, é muito importante porque:
Alguns controles de verificação podem não suportar o script do cliente. Há um bom exemplo: se você deseja usar as funções de verificação do CustomValidator e do servidor ao mesmo tempo, mas não há função de verificação do cliente.
Precauções de segurança. Algumas pessoas podem facilmente obter uma página contendo um script e desativar ou alterar a página. Você não deve usar seu script para impedir que dados ruins digitem seu sistema, mas apenas para os usuários obter feedback mais rápido. Portanto, se você deseja usar o CustomValidator, não deve fornecer uma função de verificação do cliente sem as funções de verificação do servidor correspondentes.
Cada controle de verificação pode garantir que um bloco de script do cliente padrão seja enviado para a página. De fato, esta é apenas uma pequena parte do código, que contém uma referência ao código na biblioteca de scripts webuivalidation.js. Este arquivo da biblioteca de scripts contém toda a lógica verificada pelo cliente.
Sobre a biblioteca de scripts
Como a verificação do script de controle da web está na biblioteca de scripts, o código verificado por todos os clientes não é necessário para enviá -lo diretamente para a página, embora pareça ser feito na superfície. As principais referências do arquivo de script são semelhantes às seguintes:
<idioma de script = javascript
src =/_ ASPX/1.0.9999/script/webuivalidation.js> </script>
Por padrão, o arquivo de script será instalado no diretório raiz padrão no diretório _aspx e usa um script incluir instruções a serem chamadas, que começa com uma linha diagonal positiva. A referência mostra que cada objeto individual não precisa incluir a 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 do idioma público nesse 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 visualizará o conteúdo. A posiçã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 da posição neste arquivo:
<WebControls
CLEERSCRIPTSLOCATION =/_ ASPX/{0}/SCRIPT/
/>
Incentive você a ler o script para que você possa entender os eventos que ocorrem em profundidade. No entanto, é recomendável que você não modifique esses scripts, porque suas funções estão intimamente ligadas a versões específicas de tempo de execução. Quando a versão é atualizada, esses scripts também podem ser atualizados de acordo. Se projetos específicos forem alterados, primeiro faça backup desses scripts e aponte seu projeto para o arquivo de backup, o método é usar um arquivo privado Config.Web para substituir a posição desses arquivos. Se a sequência contiver a instrução de formato {0}, o número da versão substituirá a instrução quando o número da versão do tempo de execução será substituído. É melhor alterar essa posição para uma referência relativa ou referência absoluta.
Desative a verificação do cliente
Às vezes, você pode não querer verificar os clientes. Se o número de campos de entrada for pequeno, a verificação do cliente pode não ser muito útil. Afinal, você precisa ter uma lógica que requer um servidor -trip redondo todas as vezes. Você descobrirá que as informações dinâmicas sobre o cliente terão um impacto negativo no seu layout.
Para desativar a verificação do cliente, use a página Instrução ClientTarget = Downlevel. Esta instrução é semelhante ao início do arquivo ASPX:
< %@Page Language = C# ClientTarget = Downlevel %>
O valor padrão desta instrução é automático, indicando que você verifica apenas o cliente das versões do Microsoft Internet Explorer 4.0 ou superior.
NOTA: Infelizmente, na versão beta 1, esta instrução não está apenas desativada para verificação e, ao mesmo tempo, todos os controles da Web usam tags HTML 3.2 para processar, o que pode ter 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 ocorre quando a página que contém a verificação do cliente:
Ao carregar o navegador na página, você precisa inicializar cada controle de verificação. Esses controles são enviados como a marca <span> e seus recursos HTML são mais próximos dos recursos do servidor. Mais importante ainda, todos os elementos de entrada referenciados pelo dispositivo de verificação serão "enforcados" neste momento. O elemento de entrada referenciado modificará o evento do cliente para chamar a rotina de verificação ao inserir a alteração.
O código na biblioteca de script será executado quando o usuário usar a tecla TAB para alternar entre cada campo. Quando um determinado campo independente é alterado, as condições de verificação serão avaliadas e o dispositivo de verificação será visível ou invisível conforme necessário.
Quando o usuário tentar enviar o formulário, todas as verificações serão avaliadas. Se todas essas verificações forem eficazes, o formulário será enviado ao servidor. Se houver um erro em um ou mais lugares, ocorrerá a seguinte situação:
A submissão foi cancelada. O formulário não é enviado ao servidor.
Todas as verificações inválidas são visíveis.
Se um resumo de verificação contiver o showsummary = true, todos os erros do controle de verificação serão coletados e o conteúdo será atualizado com esses erros.
Se um resumo de verificação contiver showMessageBox = true, ele coletará erros e exibirá esses erros na caixa de informações do cliente.
Como o controle de verificação do cliente é realizado quando o controle de verificação do cliente é realizado em cada alteração de entrada ou ao enviar, esses controles de verificação geralmente são avaliados duas ou mais que duas vezes no cliente. Observe que, após o envio, esses controles de verificação ainda serão avaliados no servidor.