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 a Microsoft & Reg; ActiveX & Reg;, 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, existe uma herança mágica na Microsoft & Reg;
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 & Reg; 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 o comando format {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.
Porque o controle de verificação do cliente é executado ao entrar ou quando. Observe que, após o envio, esses controles de verificação ainda serão avaliados no servidor.
API do cliente
Há uma pequena API que pode ser usada no cliente para obter vários efeitos no seu próprio código de cliente. Como alguma rotina não pode ser oculta, em teoria, você pode usar o cliente para verificar todas as variáveis, características e funções definidas pelo cliente. No entanto, muitos deles podem ser alterados. A seguir, resume o objeto do cliente que o incentivamos a usar.
Tabela 3. Objeto do cliente
Nome Tipo Descrição
Page_isValid Boolean Variable apontou se a página é atualmente válida. Verificar os scripts sempre mantenha a variável mais recente.
Page_Validator Element Array Esta é uma matriz que contém todas as verificações na página.
Page_ValidationActive Variáveis booleanas indicam se devem ser verificadas. Defina essa variável como false pode ser comprovada pela programação.
IsValid Boolen Atributos Cada dispositivo de verificação do cliente possui a propriedade, apontando se o dispositivo de verificação é atualmente válido. Observe que, na versão PDC, esse atributo é misturado com IsValid.
Ignorando a verificação do cliente
Uma tarefa que você geralmente precisa executar é adicionar o botão "Cancelar" ou o botão de navegação na página. Nesse caso, mesmo que haja erros na página, você também pode usar o botão para enviar a página. Como o botão do cliente OnClick Ocorre antes do evento Onsubmit do formulário, ele pode evitar o envio de inspeção e a verificação. A seguir, mostra como usar o controle de imagem HTML como o botão "Cancelar" para concluir a tarefa:
<Tipo de entrada = imagem Runat = servidor
Valor = cancelar
OnClick = Page_ValidationActive = false;
OnServerclight = cmdcancel_click>
Use o botão ou o Controle do Button para executar alguma confusão, porque o evento OnClick assume que é um evento de servidor com o mesmo nome. Você deve definir este evento no script do cliente:
<ASP: ImageButton Runat = ID do servidor = CMDIMGCANCEL
alternateText = Cancelar
OnClick = cmdcancel_click/>
<idioma de script = javascript>
document.all [cmdimgcancel] .onclick =
nova função (page_validationActive = false;);
</script>
Outro método para resolver esse problema é definir algumas configurações do botão "Cancelar" para que não acione o evento de envio no script do cliente ao retornar. Os controles htmlinputbutton e linkbutton são os exemplos.
Efeito especial
Outro requisito comum é que, além das informações de erro exibidas pelo próprio dispositivo de verificação, alguns outros efeitos sejam necessários. Nesse caso, qualquer modificação que você faça precisa ser realizada ao mesmo tempo no servidor ou cliente. Suponha que você precise adicionar um rótulo para alterar a cor de acordo com a entrada de entrada. A seguir, é como implementar esta tarefa no servidor:
Classe pública ChanGecolorpage: Página {
Public Label Lblzip;
Valor público de regulamento regulaxpressivo;
Substituição protegida void sobreoad (EventArgs e) {{
lblzip.forecolor = valzip.isvalid?
}
}
Todos os métodos acima são perfeitos, mas, desde que você modifique a verificação acima, você descobrirá que, a menos que execute a mesma operação no cliente, ela parecerá muito inconsistente. A estrutura de verificação permitirá que você evite muitos efeitos duplos, mas não pode evitar outros efeitos que você deve alcançar ao mesmo tempo no cliente e no servidor. A seguir, é apresentado um fragmento que executa a mesma tarefa no cliente:
<asp: rótulo id = lblzip runat = servidor
texto = código postal:/>
<Asp: textbox id = txtzip runat = servidor
OnChange = TXTZIPONCHANGE ();
<Asp: regularxpressionValididator id = valzip runat = servidor
ControlTovalidate = txtzip
errorMessage = código postal inválido
Validationxpression = [0-9] {5} /> <br>
<idioma de script = javascript>
Função txtziponchange () {{) {
// Se a verificação do cliente não estiver na atividade, ela não executará nenhuma operação
ifOF (page_validators) == indefinido) retornar;
// altere a cor do rótulo
lblzip.style.color = valzip.isvalid?
}
</script>
API do cliente beta 1
Para a edição beta 1, algumas funções que podem ser chamadas do script do cliente causarão outras situações.
Tabela 4. Função da chamada do script do cliente
Descrição do nome
ValidatorValidate (VAL) usa um dispositivo de verificação do cliente como entrada. Faça o dispositivo de verificação verificar sua entrada e atualizar sua tela.
ValidatorEnable (Val, Ativar) Obtenha um dispositivo de verificação do cliente e um valor booleano. Ativar ou desativar o dispositivo de verificação do cliente. Se estiver desativado, o dispositivo de verificação do cliente não será avaliado e o validador do cliente sempre será válido.
O ValidatorHookupControl (Control, Val) obteve um elemento HTML de entrada e um dispositivo de verificação do cliente. Modifique ou crie o evento de mudança do elemento para que o dispositivo de verificação possa ser atualizado durante a alteração. Esta função é adequada para verificações personalizadas com base em vários valores de entrada.
Seu objetivo especial é ativar ou desativar o dispositivo de verificação. Se você deseja verificar se você só entra em vigor em circunstâncias específicas, pode ser necessário alterar o status de ativação ao mesmo tempo no servidor e nos clientes; caso contrário, você descobrirá que o usuário não pode enviar a página.
A seguir, o exemplo acima, mais um campo.
Classe pública condicional: página {
public htmlinputcheckbox chksameas;
Public ResearchFieldValidator RfvalshipAddress;
Substituição protegida void validate () {) {)
BOOL Enableship =!
rfvalshipAddress.enabled = ativação;
base.Validate ();
}
}
A seguir, o código do cliente equivalente:
<Tipo de entrada = Caixa de seleção Runat = ID do servidor = Chksameas
OnClick = Onchangesameas ();> o mesmo que o endereço de pagamento <br>
<idioma de script = javascript>
Função onchangesameas () {
var entleship =! Event.srcement.status;
ValidatorEnable (rfvalshipAddress, ativação);
}
</script>
Regras eficazes e informações úteis de erro
Cada dispositivo de verificação mostra informações de erro específicas sobre condições específicas em controles específicos. Existem algumas regras que confirmam se é válido.
Todas as verificações vazias (exceto o requerirFieldValidator) são consideradas válidas. Se um valor vazio for inválido, você geralmente precisará de um Valorizador Necessário e um outro verificador. Você precisa fazer isso, porque, em geral, sempre deseja mostrar informações de erro diferentes no dispositivo de verificação vazio e na eficácia. Você também pode usar informações pouco claras, como "você deve inserir um valor, e esse valor deve estar entre 1 e 10".
Outras regras especiais usadas quando o campo de entrada não pode ser convertido em um tipo de dados especificado está relacionado ao CompareValidator e RangeValidator. O processo de avaliação de validade do CompareValidator do ControlTocompare especifica o processo de avaliação de validade é o descrito abaixo:
Se o campo de entrada referenciado pelo ControlTovalidate estiver vazio, será eficaz.
Se o campo de entrada referenciado pelo ControlTovalidate não puder ser convertido no tipo de dados necessário, ele será inválido.
Se o campo de entrada referenciado pelo ControlTocompare não puder ser convertido no tipo de dados necessário, ele será válido.
O campo de entrada é convertido para o tipo de dados necessário e se compara.
O terceiro passo parece um pouco inconsistente. A razão para isso é porque, se o dispositivo de verificação verificar a eficácia de vários campos ao mesmo tempo, é difícil escrever informações de erro significativas para o dispositivo de verificação. Um dispositivo de verificação independente deve ser usado para relatar a situação de erro no campo de entrada do ControlTocompare. RangeValidator possui métodos de trabalho semelhantes, com propriedades máximas e mínimas.
Funções de propriedades habilitadas, visíveis e de exibição
A diferença entre as propriedades ativadas, visíveis e de exibição do dispositivo de verificação pode não ser muito óbvia.
Display = nenhum pode ser usado para especificar que o dispositivo de verificação não exibe diretamente nenhum conteúdo, mas ainda avalia, ainda afeta a eficácia geral e ainda pode colocar erros no resumo do cliente e do servidor. Para a verificação do cliente, esses valores estão determinados a usar as características do estilo visível ou usar as características do estilo de exibição para abrir ou fechar o dispositivo de verificação. Para verificação do servidor -lado, exibir = dinâmico significa que a entrada não exibe nenhum conteúdo quando a entrada é válida e o display = estático representa um espaço que não muda. A última configuração deve ser dobrada em nenhum conteúdo quando a célula que contém apenas o dispositivo de verificação na tabela é válida.
Por que não apenas usar visível = false para tornar o dispositivo de verificação visível? No ASP+, o atributo visível do controle tem muitos significados: o controle de visível = false não será processado ou exibido. É precisamente por esse significado que o visível = false do dispositivo de verificação significa que não apenas não exibe nenhum conteúdo, mas também não pode ser usado. Este dispositivo de verificação não será avaliado, não afetará a validade da página, nem será colocado em resumo.
Ativado é neutro. Na maioria dos casos, o efeito de ativado = false e visível = false é exatamente o mesmo. Na edição beta 1 ou na versão superior, há uma diferença importante: na verificação do cliente, o dispositivo de verificação desativado ainda será enviado ao navegador, mas está em um estado deficiente. Você pode usar a função ValidatorEnable no script do cliente para ativar o dispositivo de verificação.
Ao usar visível ou ativado para controlar se deve verificar, preste atenção ao pedido no servidor acima. Ou altere antes da verificação, ou re -verifique após a alteração. Caso contrário, seus valores isvalid não refletirão alterações nos atributos.
Controle CustomValidator
A maneira mais fácil de estender a estrutura de verificação é usar o controle CustomValidator. Esse controle pode ser usado para executar verificações que outros controles de verificação não podem ser executados, mas também podem executar verificações que precisam acessar informações no servidor (como bancos de dados ou serviços da Web).
Se o CustomValidator com apenas uma função de verificação do servidor for adicionada, você notará que o dispositivo de verificação não participará da verificação do cliente. Quando o usuário alterna entre cada campo com a tecla TAB, o CustomValidator não será atualizado e o servidor redondo -trip precisa executar sua verificação ao mesmo tempo. Se você deseja usar o CustomValidator para executar uma verificação que não requer nenhuma informação no servidor, você também pode usar a propriedade ClientValidationFunction para fazer com que o dispositivo de verificação participe completamente da verificação do cliente. Suponha que você forneça uma Função de Validação do Client. Mas, de fato, é apenas uma parte da verificação. A verificação da função de verificação do cliente não excede a verificação da execução no servidor porque os hackers podem ignorar facilmente a função de verificação.
A seguir, é apresentado um exemplo simples de usar o CustomValidator no cliente e no servidor, verifique apenas se a entrada é uniforme. Vamos apresentar a função do servidor (em C#):
{serviço parcial) {posição
tentar {
int i = int.FromString (valor);
Return ((i % 2) == 0);
} Pegar {
Retornar falso;
}
}
A seguir, é apresentado o método da declaração da função no cliente e uma função de verificação do cliente que executa a mesma verificação. Geralmente, é um formulário JScript, mas se o seu objetivo é a Microsoft & Reg;
<ASP: ID do CustomValidator = CustomVal2 Runat = servidor
ErrorMessage = números não podem ser removidos!
ControlTovalidate = txtCustomData
OnservalidationFunction = ServerValidation
ClientValidationFunction = checkeven /> <br>
Campo de dados: <asp: textbox id = txtcustosdata runat = server />
<idioma de script = javascript>
<!-
Função checkeven (fonte, valor) {{
var valor = parseint (valor, 10);
if (isnan (val))
Retornar falso;
Return ((Val % 2) == 0);
}
//->
</script>
Aqui estão algumas precauções usando o CustomValidator:
Semelhante a todos os outros controles de verificação (exceto o NeceedFieldValidator), se o campo de entrada estiver vazio, considera -se que o CustomValidator é eficaz.
Se o navegador mais antigo for usado ou a verificação do cliente estiver fechada, a função de verificação do cliente não poderá ser chamada. Antes de definir a função, você não precisa verificar a função do navegador usado no navegador, mas precisa garantir que o navegador não cause erros de script devido à definição. Certifique -se de tornar o código do seu cliente como uma anotação do HTML, como mostrado no exemplo a seguir.
Dois parâmetros são passados para a função do seu cliente e correspondem aos parâmetros passados para a função do servidor. O primeiro é o elemento do dispositivo de verificação do cliente e o segundo é o valor de controle especificado pelo ControlTovalidate. No entanto, no cliente, você pode optar por não definir parâmetros para a função, que funcionarão normalmente.
Se você usa versões beta1 ou superior, poderá manter o ControlTovalidate como vazio. Nesse modo, a função do servidor sempre desencadeará uma ida e volta de ida e volta, e a função do cliente sempre será acionada toda vez que você tentar enviá -la. Você pode usar esse recurso para verificar os controles que outros métodos não podem verificar, como botões de caixa de seleção ou botões de rádio separados. Se a condição for baseada em vários controles e você não desejar que o usuário avalie a condição ao alternar entre cada campo na página, você poderá usar esse método.
Outra opção na versão beta 1 ou superior é o evento de mudança de vários controles. O método é adicionar alguns scripts incorporados que chamam o cliente ValidatorHookupControl, conforme descrito acima.
Quais controles podem ser verificados?
Para permitir que o controle seja verificado pela referência de controle, o controle deve ter atributos verificados. Todos os controles verificados possuem propriedades ValidationPropertyAttribute, que indicam o atributo que deve ser lido durante a verificação. Se você escrever seu próprio controle, poderá especificar os atributos a serem usados fornecendo um deles, para que o controle esteja envolvido na verificação.
Para permitir que a verificação seja realizada normalmente no cliente, o atributo deve corresponder às características do valor do elemento HTML exibido pelo cliente. Muitos controles complicados (como Datagrid e Calendário) não valem o cliente e só podem ser verificados no servidor. Portanto, apenas os controles mais próximos dos elementos HTML podem participar da verificação. Além disso, o controle deve ter um único valor lógico no cliente. Portanto, o RadiobuttonList pode ser verificado, mas a lista de seleção não pode.
Fim
A explicação mencionada acima da verificação ASP+ pode ter excedido o conteúdo que você deseja entender. Apreciá-lo!
--------------------------------------------------- -------------------------------------------------------- --------------------------
Use IE4.0 acima da versão 800 * 600 visualizações neste site
& Copy; Mantenha a propriedade. Use regulamentos.
Colete o código de efeito especial da página da web mais prático!