Resumen: explicaciones detalladas para el uso del control web ASP+ Verificación.
Tabla de contenido
Breve introducción
empezando
¿Cuándo sucede?
Secuencia de verificación en el lado del servidor
Verificación del cliente
Reglas efectivas e información de error útil
Funciones de propiedades habilitadas, visibles y de visualización
Control de Validador Custom
¿Qué controles se pueden verificar?
Fin
-------------------------------------------------- -------------------------------------------------- ----------------------------
Breve introducción
Este artículo explica el método de trabajo del control de verificación ASP+ en detalle. Si desea generar una página compleja que contenga el control de verificación, o expandir el marco de verificación, se recomienda que lea este artículo. Si desea aprender a usar el control de verificación o decidir si utilizar el control de verificación, consulte "ASP+ Usuario Ingrese la verificación (inglés)".
empezando
Sabemos que es importante comprender la verificación durante todo el proceso de desarrollo ASP+. Mire la mayoría de los sitios web comerciales de hoy, encontrará que hay muchas formas en estos sitios, que obviamente se ejecutan ejecutando una gran cantidad de código escrito a mano. Escribir código de verificación no es un trabajo interesante. Si escribe un código para mostrar la tabla de datos o genera gráficos dinámicamente, puede ser muy atractivo, pero nadie puede confirmar con sus colegas que este método "genial" puede prohibir el valor vacío en el campo Nombre.
Por otras razones, la verificación de aplicaciones web también es muy problemática. HTML 3.2 tiene muchas restricciones en el contenido que puede controlar o comentarios que puede obtener del usuario, por lo que no se puede aplicar a las técnicas que pueden usarse en un cliente más satisfactorio, como prohibir a los usuarios ingresar ciertos caracteres o haciendo un sonido. El uso de script de navegador puede producir una verificación más poderosa. Sin embargo, este método es difícil de confirmar, porque el navegador del cliente no es necesariamente un script, y los usuarios maliciosos pueden evitarlo. Por lo tanto, para garantizar la seguridad del sitio, es necesario realizar la misma inspección del servidor.
Al desarrollar ASP+, nuestra intención original es usar solo un control para la verificación de procesos. Pero cuando fue diseñado, descubrí que este deseo no podía lograrse. Hemos investigado una gran cantidad de formularios de entrada de datos para encontrar una solución que pueda aplicarse a tantos formularios como sea posible. Encontramos que la tabla de entrada de datos tiene muchas características interesantes:
Aunque la información de error o los iconos a menudo son adyacentes a los elementos de entrada, casi siempre se encuentran en diferentes celdas de la tabla.
A menudo hay un área en la página para resumir todos los errores.
Muchos sitios incluyen scripts de clientes para proporcionar comentarios más rápidos al tiempo que evitan viajar entre el servidor en vano.
Muchos sitios que contienen scripts de clientes muestran cuadros de información cuando hay un error.
No solo se verificará la entrada del texto, sino que también se verificará la lista de caída y el botón de selección única.
Si un campo está vacío, el sitio generalmente muestra información o iconos diferentes cuando la entrada no es válida.
Muchos exámenes efectivos pueden ser bien reemplazados por expresiones de uso común.
La verificación generalmente se basa en los resultados de comparación entre dos entradas.
El 90% o más del 90% de las tareas de verificación son algunas operaciones comunes, como verificar el nombre o el código postal. La mayoría de los sitios todavía parecen estar repitiendo estas tareas.
Debido a que la diferencia entre los sitios generalmente es demasiado grande, no se puede obtener una solución perfecta para manejar todas las tareas de verificación de cada sitio.
Teniendo en cuenta todas las situaciones anteriores, las soluciones finales incluyen cinco controles de dispositivos de verificación, validaciones de controles y integración con objetos de página. Al mismo tiempo, es obvio que la solución debe ampliarse y se necesita una API para cooperar en el cliente y el servidor.
Descubrimos que parecíamos necesitar una caja de herramientas más grande durante las diversas verificaciones de investigación. En la mayoría de los entornos de componentes, como Microsoft & Reg; Afortunadamente, hay una herencia mágica en Microsoft & Reg;
La mayoría de estos controles se implementan en suvalidator Base Public -Alevel -Alevel. También puede completar varias tareas de BaseValidator u otros controles. De hecho, incluso si BaseValidator es demasiado vago para lograr sus propios atributos de texto, se hereda de los atributos de la etiqueta.
¿Cuándo sucede?
Es muy efectivo comprender la secuencia del evento al procesar la página que contiene la página del control web. Si una condición de verificación es opcional, debe comprender con precisión cuándo se verifica el cliente y el servidor. Si desea escribir una rutina de verificación usted mismo, puede ser un tiempo que consume o efectos secundarios. Al mismo tiempo, también es importante comprender el momento de la rutina de verificación de llamadas.
Primero, echemos un vistazo al servidor.
Secuencia de verificación en el lado del servidor
Es importante comprender el período de validez de la página. Si está acostumbrado a procesar el formulario en Visual Basic o herramientas de cliente funcional similares, debe pasar un cierto tiempo para comprender. Todos los objetos en la página y la página no son efectivos cuando interactúan con los usuarios, aunque a veces esto es lo mismo.
La siguiente es una secuencia de eventos simplificada al visitar una página por primera vez:
Cree una página y su control basado en el archivo ASPX.
Activar el evento Page_Load.
La página y los atributos de control se almacenan en un campo oculto.
Las páginas y los controles se convierten en HTML.
Deseche todo.
Ahora, cuando el usuario haga clic en un botón o un control similar, volverá al servidor y luego ejecutará una secuencia de eventos similar. Esta secuencia se llama secuencia de retorno:
Cree una página y su control basado en el archivo ASPX.
Restaurar la página y controlar los atributos desde el campo oculto.
Ingrese el control de la página de actualización de acuerdo con el usuario.
Activar el evento Page_Load.
Los eventos de notificación de cambios de activación.
La página y los atributos de control se almacenan en un campo oculto.
Las páginas y los controles se convierten en HTML.
Deseche todo de nuevo.
¿Por qué no mantenemos todos los objetos en la memoria? Porque los sitios web establecidos con ASP+ no pueden manejar una gran cantidad de usuarios. Por lo tanto, la memoria del servidor solo conserva el contenido que se procesará de inmediato.
¿Cuándo es la verificación del lado del servidor? Al obtener información de la página por primera vez, la verificación del lado del servidor no se realizará en absoluto. La mayoría de los usuarios finales son muy serios.
En la secuencia del evento de retorno, la verificación se realizará entre el paso 3 y el paso 4. En otras palabras, la verificación es después de los atributos de control de carga de datos del usuario, pero antes de la mayor parte del número de ejecución del código. Esto significa que al escribir eventos de usuario, generalmente se puede usar para la verificación. En circunstancias normales, querrás hacer esto.
La desventaja de la verificación en ese momento es: si desea modificar algunos atributos que afecten la verificación por programación, será demasiado tarde. Por ejemplo, encontrará que si usa el código para habilitar o deshabilitar los atributos del control de verificación o modificar el control de verificación, no verá ningún efecto antes de procesar la página. Este problema se puede evitar a través de los siguientes dos métodos:
Modifique el atributo antes de la verificación.
Verifique el control después del cambio de atributo.
Ambos métodos deben usar atributos y métodos de verificación efectivos en el objeto de página.
API de la página
Los objetos de página incluyen algunos atributos y métodos importantes relacionados con la verificación del lado del servidor. La Tabla 1 resume estos atributos y métodos:
Tabla 1. Atributos y métodos del objeto de página
Atributo o descripción del método
El atributo ISVALID es el atributo más útil. Este atributo puede verificar si todo el formulario es efectivo. Esta verificación generalmente se realiza antes de actualizar la base de datos. Solo todos los objetos de los validadores son válidos, el atributo es verdadero y el valor no se almacena en el caché.
Validadores atribuye la colección de todos los objetos de verificación de esta página. Esta es una colección de objetos que implementan la interfaz ivalidator.
El método de valor llama a un método cuando la verificación. El método de ejecución predeterminado en el objeto de página es pasar a cada dispositivo de verificación y requerir que el dispositivo de verificación se evalúe.
La colección de validadores es muy útil para muchas tareas. Este conjunto es una colección de objetos que implementan la interfaz ivalidator. La razón por la que uso el objeto no es el control del control porque el objeto de página solo presta atención a la interfaz Ivalidator. Dado que todas las verificaciones generalmente se usan para lograr algunos controles visuales del ivalidator, cualquiera debe poder usar cualquier objeto de verificación y agregar el objeto de verificación a la página.
La interfaz de Ivalidator contiene los siguientes atributos y métodos:
Tabla 2. Los atributos y métodos de la interfaz ivalidator
Atributo o descripción del método
El atributo ISVALID señaló si la prueba de validez realizada por un objeto de verificación separado ha pasado. Puede cambiar manualmente el valor después de la verificación.
El atributo ErrorMessage introduce el error para verificar que se verifique el objeto y los errores que se pueden mostrar al usuario.
El método Validate se verifica para la validez del objeto de verificación para actualizar su valor ISVALID.
Puede usar esta interfaz para realizar algunas tareas interesantes. Por ejemplo, para restablecer la página a un estado efectivo, use el siguiente código (como el ejemplo que se muestra en C#):
Valor ivalidator;
Foreach (val en validadores) {
valueValid = true;
}
Para volver a ejecutar toda la secuencia de verificación, use el siguiente código:
Valor ivalidator;
Foreach (val en validadores) {
Val.Validate ();
}
Si tiene versiones de edición Beta 1 o superiores, también puede llamar al método de valor solo para el objeto de página, para que se pueda completar la misma tarea. Para realizar algunos cambios antes de la verificación, el método de valor se puede cubrir. Este ejemplo muestra una página que contiene el dispositivo de verificación, que se abre o desactiva de acuerdo con el valor de la casilla de verificación:
Public Class Conditional: Página {
Public htmlinputcheckbox chksameas;
Investigación pública de Validator RfvalshipAddress;
Anulación protegida void validate () {) {)
// simplemente verifique la dirección de entrega (si es diferente de la dirección de pago)
Bool habilitando =!
rfvalshipAddress.enabled = EnlAntShip;
// ahora ejecutando verificación
base.validate ();
}
}
Verificación del cliente
Si su página está habilitada por verificación del cliente, se producirá una secuencia de eventos completamente diferente durante el viaje de ida y vuelta. La verificación del cliente utiliza el cliente JScript & Reg; La verificación no requiere componentes binarios.
Aunque la estandarización del lenguaje JScript está bien realizado, el modelo de objeto de documento (DOM) utilizado en la documentación HTML en el navegador (DOM) no ha utilizado ampliamente los estándares. Por lo tanto, la verificación del cliente solo se realiza en Internet Explorer 4.0 y versiones superiores, porque el objeto verificado es Internet Explorer DOM.
Desde la perspectiva del servidor, la verificación del cliente solo significa que el control de verificación envía contenido diferente a HTML. Además, la secuencia de incidentes es exactamente la misma. La verificación del lado del servidor todavía se realiza. Aunque parece redundante, es muy importante porque:
Algunos controles de verificación pueden no admitir el script del cliente. Hay un buen ejemplo: si desea usar las funciones de verificación CustomValidator y del servidor al mismo tiempo, pero no hay función de verificación del cliente.
Precauciones de seguridad. Algunas personas pueden obtener fácilmente una página que contiene un script y luego deshabilitar o cambiar la página. No debe usar su script para evitar que los datos malos ingresen a su sistema, sino solo para que los usuarios obtengan comentarios más rápidos. Por lo tanto, si desea utilizar CustomValidator, no debe proporcionar una función de verificación del cliente sin las funciones de verificación del servidor correspondientes.
Cada control de verificación puede garantizar que se envíe un bloque de script de cliente estándar a la página. De hecho, esto es solo una pequeña parte del código, que contiene una referencia al código en la biblioteca de scripts webuivalidation.js. Este archivo de biblioteca de script contiene toda la lógica verificada por el cliente.
Acerca de la biblioteca de guiones
Debido a que la verificación del script de control web está en la biblioteca de script, el código verificado por todos los clientes no es necesario para enviarlo directamente a la página, aunque parece hacerse en la superficie. Las referencias del archivo de script principal son similares a las siguientes:
<Script Language = JavaScript
src =/_ ASPX/1.0.9999/script/webuivalidation.js> </script>
De manera predeterminada, el archivo de script se instalará en el directorio raíz predeterminado en el directorio _aspx, y utiliza una instrucción de inclusión de script que se llamará, que comienza con una línea diagonal positiva. La referencia muestra que cada objeto individual no necesita incluir la biblioteca de script, y todas las páginas en la misma computadora pueden hacer referencia al mismo archivo. Notará que también hay un número de versión de lenguaje público en esta ruta, para que diferentes versiones de tiempo de ejecución puedan ejecutarse en la misma computadora.
Si observa su directorio raíz virtual predeterminado, encontrará el archivo y verá el contenido. La posición de estos archivos se especifica en el archivo config.web. El archivo config.web es un archivo XML para la mayoría de la configuración ASP+. La siguiente es la definición de la posición en este archivo:
<WebControls
ClientScriptSlocation =/_ ASPX/{0}/script/
/>
Anímate a leer el guión para que puedas entender los eventos que ocurren en profundidad. Sin embargo, se recomienda que no modifique estos scripts, porque sus funciones están estrechamente vinculadas a versiones específicas de tiempo de ejecución. Cuando se actualiza la versión, estos scripts también deben actualizarse en consecuencia. Si se deben cambiar proyectos específicos, la primera copia de seguridad de estos scripts y luego apunte su proyecto al archivo de copia de seguridad, el método es usar un archivo de configuración privada para reemplazar la posición de estos archivos. Si la cadena contiene la instrucción de formato {0}, el número de versión reemplazará la instrucción cuando se reemplazará el número de versión de tiempo de ejecución. Es mejor cambiar esta posición a una referencia relativa o referencia absoluta.
Desactivar la verificación del cliente
A veces es posible que no desee verificar a los clientes. Si el número de campos de entrada es pequeño, la verificación del cliente puede no ser muy útil. Después de todo, debe tener una lógica que requiera un servidor de trips redondo cada vez. Encontrará que la información dinámica del cliente tendrá un impacto negativo en su diseño.
Para deshabilitar la verificación del cliente, use la instrucción de la página ClientTarget = Downlevel. Esta instrucción es similar al comienzo del archivo ASPX:
< %@page idioma = c# clientTarget = downlevel %>
El valor predeterminado de esta instrucción es automático, lo que indica que solo verifica el cliente de las versiones de Microsoft Internet Explorer 4.0 o superiores.
Nota: Desafortunadamente, en Beta 1, esta instrucción no solo está deshabilitada para la verificación, y al mismo tiempo, todos los controles web usan etiquetas HTML 3.2 para procesar, que pueden tener resultados inesperados. La versión final proporciona una mejor manera de controlar este problema.
Secuencia de eventos del cliente
Esta secuencia es una secuencia de eventos que ocurre cuando la página que contiene la verificación del cliente:
Al cargar el navegador en la página, debe inicializar cada control de verificación. Estos controles se envían como la marca <span>, y sus características HTML están más cerca de las características del servidor. Lo más importante es que todos los elementos de entrada a los que se hace referencia por el dispositivo de verificación se "colgarán" en este momento. El elemento de entrada referenciado modificará su evento de cliente para llamar a la rutina de verificación al ingresar el cambio.
El código en la biblioteca de script se ejecutará cuando el usuario use la tecla Tab para cambiar entre cada campo. Cuando se cambia un cierto campo independiente, las condiciones de verificación se volverán a evaluar y el dispositivo de verificación será visible o invisible según sea necesario.
Cuando el usuario intenta enviar el formulario, se evaluarán todas las verificaciones. Si todas estas verificaciones son efectivas, el formulario se enviará al servidor. Si hay un error en uno o más lugares, ocurrirá la siguiente situación:
La presentación fue cancelada. El formulario no se envía al servidor.
Todas las verificaciones no válidas son visibles.
Si un resumen de verificación contiene showummary = true, todos los errores del control de verificación se recopilarán y el contenido se actualiza con estos errores.
Si un resumen de verificación contiene showMessageBox = true, recopilará errores y mostrará estos errores en el cuadro de información del cliente.
Debido a que el control de verificación del cliente se realiza cuando el control de verificación del cliente se realiza en cada cambio de entrada o cuando se envía, estos controles de verificación generalmente se evalúan dos o más de dos veces en el cliente. Tenga en cuenta que después del envío, estos controles de verificación aún se volverán a evaluar en el servidor.
API del cliente
Hay una pequeña API que se puede usar en el cliente para lograr varios efectos en su propio código del cliente. Debido a que alguna rutina no se puede ocultar, en teoría, puede usar el cliente para verificar todas las variables, características y funciones definidas por el cliente. Sin embargo, muchos de ellos se pueden cambiar. Lo siguiente resume el objeto cliente que le recomendamos que use.
Tabla 3. Objeto cliente
Nombre Tipo de descripción
PAGE_ISVALID La variable booleana señaló si la página es actualmente válida. Verificar los scripts siempre mantenga la variable más reciente.
Page_Validator Element Array Esta es una matriz que contiene todas las verificaciones en la página.
Page_ValidationActive Boolean las variables indican si debe verificarse. Establezca esta variable en FALSE se puede probar mediante programación.
Atributos de boolen ISVALID Cada dispositivo de verificación del cliente tiene la propiedad, señalando si el dispositivo de verificación es actualmente válido. Tenga en cuenta que en la versión PDC, este atributo se mezcla con ISVALID.
Evitar la verificación del cliente
Una tarea que a menudo necesita ejecutar es agregar el botón "Cancelar" o el botón de navegación en la página. En este caso, incluso si hay errores en la página, también puede usar el botón para enviar la página. Debido a que el evento OnClick del botón cliente ocurre antes del evento OnSubmit del formulario, puede evitar enviar la inspección y el omitido de la verificación. Lo siguiente muestra cómo usar el control de imagen HTML como el botón "Cancelar" para completar la tarea:
<input type = image runat = servidor
Valor = cancelar
OnClick = page_validationActive = false;
onServerClight = cmdcancel_click>
Use el botón o el control de Button para ejecutar cierta confusión, porque el evento OnClick supone que es un evento de servidor con el mismo nombre. Debe establecer este evento en el script del cliente:
<ASP: ImageButton Runat = Server ID = CMDIMGCANCEL
alternatetext = cancelar
OnClick = cmdcancel_click/>
<Script Language = JavaScript>
document.all [cmdimgCancel] .onclick =
nueva función (page_validationActive = false;);
</script>
Otro método para resolver este problema es establecer una determinada configuración del botón "Cancelar" para que no active el evento de envío en el script del cliente al regresar. Los controles HtmlinputButton y LinkButton son los ejemplos.
Efecto especial
Otro requisito común es que, además de la información de error mostrada por el dispositivo de verificación en sí, se necesitan algunos otros efectos. En este caso, cualquier modificación que haga debe llevarse a cabo al mismo tiempo en el servidor o el cliente. Supongamos que necesita agregar una etiqueta para cambiar el color de acuerdo con si la entrada es válida. La siguiente es cómo implementar esta tarea en el servidor:
Public Class ChangeColorPage: Page {
etiqueta pública lblzip;
Valor público de RegulaxPressionValidator;
Anulación protegida void overoad (EventArgs e) {{
lblzip.forecolor = valzip.isvalid?
}
}
Todos los métodos anteriores son perfectos, pero siempre que modifique la verificación anterior, encontrará que a menos que realice la misma operación en el cliente, se verá muy inconsistente. El marco de verificación le permitirá evitar muchos de estos efectos duales, pero no puede evitar otros efectos que debe lograr al mismo tiempo en el cliente y el servidor. El siguiente es un fragmento que realiza la misma tarea en el cliente:
<ASP: etiqueta id = lblzip runat = servidor
Text = Zip Code:/>
<ASP: TextBox id = txtzip runat = servidor
onchange = txtziponchange ();
<ASP: regularxpressionValidator id = valzip runat = servidor
ControlTovalidate = txtzip
ErrorMessage = código postal no válido
ValidationXpression = [0-9] {5} /> <br>
<Script Language = JavaScript>
Función txtziponchange () {{) {
// Si la verificación del cliente no está en la actividad, no realizará ninguna operación
ifof (page_validators) == Undefined) return;
// Cambiar el color de la etiqueta
lblzip.style.color = valzip.isvalid?
}
</script>
Beta 1 API del cliente
Para la edición Beta 1, algunas funciones que se pueden llamar desde el script del cliente causarán otras situaciones.
Tabla 4. Funcionar desde la llamada de script del cliente
Descripción del nombre
ValidatorValidate (Val) utiliza un dispositivo de verificación del cliente como entrada. Haga que el dispositivo de verificación verifique su entrada y actualice su pantalla.
Validatorenable (Val, Enable) obtenga un dispositivo de verificación del cliente y un valor booleano. Habilitar o deshabilitar el dispositivo de verificación del cliente. Si está deshabilitado, el dispositivo de verificación del cliente no será evaluado y el validador del cliente siempre será válido.
ValidatorHookupControl (Control, Val) obtuvo un elemento HTML de entrada y un dispositivo de verificación del cliente. Modifique o cree el evento de cambio del elemento para que el dispositivo de verificación se pueda actualizar durante el cambio. Esta función es adecuada para verificaciones personalizadas basadas en múltiples valores de entrada.
Su propósito especial es habilitar o deshabilitar el dispositivo de verificación. Si desea verificar que solo entra en vigencia en circunstancias específicas, es posible que deba cambiar el estado de activación al mismo tiempo en el servidor y los clientes, de lo contrario encontrará que el usuario no puede enviar la página.
El siguiente es el ejemplo anterior más un campo.
Public Class Conditional: Página {
Public htmlinputcheckbox chksameas;
Investigación pública de Validator RfvalshipAddress;
Anulación protegida void validate () {) {)
Bool habilitando =!
rfvalshipAddress.enabled = EnlAntShip;
base.validate ();
}
}
El siguiente es el código del cliente equivalente:
<input type = checkbox runat = servidor id = chksameas
OnClick = OnChangeSeMeas ();> lo mismo que la dirección de pago <br>
<Script Language = JavaScript>
Function onChangeSeMeas () {
vartleship =!
Validatorenable (rfValshipAddress, Enlanship);
}
</script>
Reglas efectivas e información de error útil
Cada dispositivo de verificación muestra información de error específica sobre condiciones específicas en controles específicos. Hay algunas reglas que confirman si es válido.
Todas las verificaciones vacías (a excepción de RequiredFieldValidator) se consideran válidas. Si un valor vacío no es válido, generalmente necesita un Validator requerido y otro verificador. Debe hacer esto, porque en general, siempre desea mostrar información de error diferente sobre el dispositivo de verificación vacía y la efectividad. También puede usar información poco clara, como "debe ingresar un valor, y este valor debe ser entre 1 y 10".
Otras reglas especiales utilizadas cuando el campo de entrada no se puede convertir en un tipo de datos especificados está relacionada con comparación y rangalidador. El proceso de evaluación de validez del compartimento de ControlTocompare especifica el proceso de evaluación de validez es el descrito a continuación:
Si el campo de entrada referenciado por ControlTovalidate está vacío, es efectivo.
Si el campo de entrada referenciado por ControlTovalidate no se puede convertir al tipo de datos requerido, no es válido.
Si el campo de entrada referenciado por ControlTocompare no se puede convertir al tipo de datos requerido, es válido.
El campo de entrada se convierte al tipo de datos requerido y se compara.
El tercer paso parece un poco inconsistente. La razón de esto es porque si el dispositivo de verificación verifica la efectividad de múltiples campos al mismo tiempo, es difícil escribir información de error significativa para el dispositivo de verificación. Se debe utilizar un dispositivo de verificación independiente para informar la situación de error en el campo de entrada ControlTocompare. Rangalidator tiene métodos de trabajo similares, con propiedades máximas y mínimas.
Funciones de propiedades habilitadas, visibles y de visualización
La diferencia entre las propiedades habilitadas, visibles y de visualización del dispositivo de verificación puede no ser muy obvia.
Display = Ninguno se puede usar para especificar que el dispositivo de verificación no muestra directamente ningún contenido, pero aún evalúa, aún afecta la efectividad general y aún puede poner errores en el resumen del cliente y el servidor. Para la verificación del cliente, estos valores están determinados para utilizar las características de estilo visible o usar las características de estilo de visualización para abrir o cerrar el dispositivo de verificación. Para la verificación de servidor, Display = Dynamic significa que la entrada no muestra ningún contenido cuando la entrada es válida, y Display = static representa un espacio que no cambia. La última configuración debe doblarse en ningún contenido cuando la celda que contiene solo el dispositivo de verificación en la tabla es válido.
¿Por qué no solo usar Visible = False para hacer que el dispositivo de verificación sea visible? En ASP+, el atributo visible del control tiene muchos significados: el control de visible = false no se procesará ni se mostrará en absoluto. Se debe precisamente a este significado que el visible = falso del dispositivo de verificación significa que no solo no muestra ningún contenido, sino que tampoco se puede usar. Este dispositivo de verificación no se evaluará, no afectará la validez de la página, ni se pondrá en abstracto.
Habilitado es neutral. En la mayoría de los casos, el efecto de habilitado = falso y visible = falso es exactamente el mismo. En la edición Beta 1 o la versión superior, hay una diferencia importante: en la verificación del cliente, el dispositivo de verificación deshabilitado aún se enviará al navegador, pero está en un estado discapacitado. Puede usar la función Validatorenable en el script del cliente para activar el dispositivo de verificación.
Cuando use Visible o habilitado para controlar si verificar, preste atención al pedido de pedido en el servidor anterior. O cambiar antes de la verificación, o volver a verificar después del cambio. De lo contrario, sus valores ISVALID no reflejarán los cambios en los atributos.
Control de Validador Custom
La forma más fácil de extender el marco de verificación es utilizar el control CustomValidator. Este control se puede utilizar para realizar verificaciones de que no se pueden realizar otros controles de verificación, pero también pueden ejecutar verificaciones que necesitan acceder a información en el servidor (como bases de datos o servicios web).
Si se agrega CustomValidator con una sola función de verificación del servidor, notará que el dispositivo de verificación no participa en la verificación del cliente. Cuando el usuario cambia entre cada campo con la tecla TAB, el CustomValidator no se actualizará, y el servidor redondo de Trip debe realizar su verificación a la vez. Si desea utilizar CustomValidator para realizar una verificación que no requiere ninguna información en el servidor, también puede usar la propiedad ClientValidationFunction para que el dispositivo de verificación participe por completo en la verificación del cliente. Supongamos que proporciona una función ClientValidation. Pero de hecho, es solo una parte de la verificación. La verificación de la función de verificación del cliente no excede la verificación de la ejecución en el servidor porque los piratas informáticos pueden evitar fácilmente la función de verificación.
El siguiente es un ejemplo simple del uso de CustomValidator en el cliente y el servidor, solo verifique si la entrada es uniforme. Presentemos la función del servidor (en C#):
{servicio parcial) {posición
intentar {
int i = int.FromString (valor);
Return ((i % 2) == 0);
} Atrapar {
Devolver falso;
}
}
El siguiente es el método de declaración de la función en el cliente y una función de verificación del cliente que realiza la misma verificación. Este suele ser un formulario JScript, pero si su objetivo es Microsoft & Reg;
<ASP: CustomValidator ID = CustomVal2 Runat = Server
ErrorMessage = los números no se pueden eliminar!
ControlTovalidate = txtCustomData
onservalidationFunction = serverValidation
ClientValidationFunction = checkeven /> <br>
Campo de datos: <ASP: TextBox id = txtCustosData runat = Server />
<Script Language = JavaScript>
<!-
Función checkeven (fuente, valor) {{
valor var = parseint (valor, 10);
if (isnan (val))
Devolver falso;
Retorno ((val % 2) == 0);
}
//->
</script>
Las siguientes son algunas precauciones para usar CustomValidator:
Similar a todos los demás controles de verificación (excepto para RequiredFieldValidator), si el campo de entrada está vacío, se considera que CustomValidator es efectivo.
Si se usa el navegador más antiguo o la verificación del cliente está cerrada, no se puede llamar a la función de verificación del cliente. Antes de definir la función, no tiene que verificar la función del navegador utilizado en el navegador, pero debe asegurarse de que el navegador no cause errores de script debido a la definición. Asegúrese de hacer el código de su cliente como una anotación de HTML, como se muestra en el siguiente ejemplo.
Se pasan dos parámetros a la función de su cliente y corresponden a los parámetros pasados a la función del servidor. El primero es el elemento del dispositivo de verificación del cliente, y el segundo es el valor de control especificado por el control de control. Sin embargo, en el cliente, puede elegir no definir los parámetros para la función, que funcionará normalmente.
Si usa versiones Beta1 o superiores, puede mantener el control de control como vacío. En este modo, la función del servidor siempre activará un viaje redondo redondo, y la función del cliente siempre se activará cada vez que intente enviarlo. Puede usar esta función para verificar los controles que otros métodos no pueden verificar, como CheckBoxList o Botones de radio separados. Si la condición se basa en múltiples controles, y no desea que el usuario evalúe la condición al cambiar entre cada campo en la página, puede usar este método.
Otra opción en la versión Beta 1 o superior es el evento de cambio de múltiples controles. El método es agregar algunos scripts integrados que llaman a la función del cliente ValidatorHookUpControl, como se describió anteriormente.
¿Qué controles se pueden verificar?
Para permitir que el control sea verificado por la referencia de control, el control debe tener atributos verificados. Todos los controles verificados tienen propiedades ValidationPropertyAttribute, que indican el atributo que debe leerse durante la verificación. Si escribe su propio control, puede especificar los atributos que se utilizarán proporcionando uno de ellos, para que el control esté involucrado en la verificación.
Para habilitar la verificación que se llevará a cabo normalmente en el cliente, el atributo debe corresponder a las características de valor del elemento HTML que muestra el cliente. Muchos controles complicados (como DataGrid y Calendar) no valen el cliente y solo pueden verificarse en el servidor. Por lo tanto, solo los controles más cercanos a los elementos HTML pueden participar en la verificación. Además, el control debe tener un único valor lógico en el cliente. Por lo tanto, RadioButtonList se puede verificar, pero la lista de cheques no puede.
Fin
La explicación mencionada anteriormente de la verificación ASP+ puede haber excedido el contenido que desea comprender. ¡Disfrútala!
-------------------------------------------------- -------------------------------------------------- ----------------------------
Utilice Ie4.0 Vistas anteriores a la versión 800 * 600 en este sitio
& Copiar; Mantenga la propiedad. Usar regulaciones.
¡Recopile el código de efecto especial más práctico de la página web!