Verificación del cliente
Si su página tiene habilitada la autenticación del cliente, se produce una secuencia de eventos completamente diferente durante el viaje de ida y vuelta. La autenticación del cliente se implementa utilizando el Cliente JScript®. No se requieren componentes binarios para implementar esta verificación.
Aunque el lenguaje JScript está bien estandarizado, no existe un estándar ampliamente adoptado para el modelo de objeto de documento (DOM) utilizado para interactuar con los documentos HTML en el navegador. Por lo tanto, la autenticación del cliente solo se realiza en Internet Explorer 4.0 y más tarde porque el objeto de autenticación es Internet Explorer DOM.
Desde una perspectiva del servidor, la verificación del cliente solo significa que el control de verificación envía contenido diferente a HTML. Aparte de eso, su secuencia de eventos es exactamente la misma. La verificación del lado del servidor todavía se ejecuta. Aunque puede parecer redundante, es muy importante porque:
Algunos controles de verificación pueden no admitir scripts de clientes. Hay un buen ejemplo: si desea utilizar las funciones de verificación CustomValidator y Server, pero no hay función de verificación del cliente.
Precauciones de seguridad. Algunas personas pueden obtener fácilmente una página con scripts y luego deshabilitar o cambiar esa página. No debe usar scripts para evitar que los datos malos ingresen a su sistema, sino solo para obtener comentarios más rápidos de los usuarios. Por lo tanto, si desea utilizar CustomValidator, no debe proporcionar una función de verificación del cliente sin la función de verificación del servidor correspondiente.
Cada control de verificación garantiza que se envíe un bloque de script de cliente estándar a la página. En realidad, esta es solo una pequeña parte del código que contiene referencias al código en la biblioteca de script Webuivalidation.js. Este archivo de biblioteca de script contiene toda la lógica para la verificación del cliente.
Acerca de la biblioteca de guiones
Debido a que el script de control web de verificación se encuentra en la biblioteca de script, no es necesario enviar todo el código verificado del cliente directamente a la página, aunque parece estar haciéndolo en la superficie. Las principales referencias de archivo de script se ven así:
<script language = "javaScript"
src = "/_ ASPX/1.0.9999/script/webuivalidation.js"> </script>
De manera predeterminada, el archivo de script se instala en el directorio raíz predeterminado en el directorio "_aspx" y se llama con la directiva de incluido de la raíz, que comienza con una barra de reenvío. Esta referencia indica que cada objeto individual no tiene que contener una 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 tiempo de ejecución de idioma común 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 de él. La ubicació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 ubicación en el archivo:
<WebControls
ClientScriptSlocation = "/_ ASPX/{0}/script/"
/>
Se le recomienda leer el guión para obtener información sobre lo que sucedió. Sin embargo, se recomienda que no modifique estos scripts, ya que su funcionalidad está estrechamente vinculada a versiones específicas de tiempo de ejecución. Cuando se actualiza la versión de tiempo de ejecución, estos scripts también pueden requerir actualizaciones correspondientes, y abandonará los cambios o enfrentará el problema de que el script no funciona. Si un proyecto específico debe cambiar estos scripts, haga una copia de seguridad de los scripts primero y luego apunte su proyecto al archivo de copia de seguridad reemplazando la ubicación de estos archivos con un archivo Config.web privado. Si la cadena contiene la instrucción de formato "{0}", el número de versión de tiempo de ejecución reemplazará la instrucción. Es mejor cambiar esa ubicación a una referencia relativa o absoluta.
Deshabilitar la autenticación del cliente
A veces es posible que no desee la autenticación del cliente. Si el número de campos de entrada es pequeño, la verificación del cliente puede ser de poca utilidad. Después de todo, debe tener una lógica que debe viajar hacia y desde el servidor una vez cada vez. Encontrará que la información que aparece dinámicamente en el cliente tendrá un impacto negativo en su diseño.
Para deshabilitar la autenticación del cliente, use la directiva de página "ClientTarget = Downlevel". Esta directiva es similar al comienzo del siguiente archivo ASPX:
< %@ Page idioma = "c#" clientTarget = downlevel %>
El valor predeterminado de esta directiva es "Auto", lo que significa que solo realiza la autenticación del cliente para Microsoft Internet Explorer 4.0 o posterior.
Nota: Desafortunadamente, en Beta 1, esta directiva no simplemente deshabilita la verificación, sino que también hace que todos los controles web se procesen utilizando etiquetas HTML 3.2, que pueden producir 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 ocurren al ejecutar una página que contiene validación del cliente:
Cuando la página se carga en el navegador, cada control de verificación debe inicializarse en algún momento. Estos controles se envían como etiquetas <span>, y sus atributos HTML son más cercanos a los del servidor. Lo más importante, todos los elementos de entrada a los que se hace referencia por el validador están "montados" en este momento. El elemento de entrada referenciado modificará los eventos de su cliente para que la rutina de verificación se llame cada vez que cambia la entrada.
El código en la biblioteca de script se ejecutará cuando el usuario cambie entre campos utilizando la tecla Tab. Cuando cambia un campo separado, se reevalúa la condición de verificación, lo que hace que el validador sea visible o invisible según sea necesario.
Cuando el usuario intenta enviar un formulario, todos los validadores son reevaluados. Si todos estos validadores son válidos, el formulario se enviará al servidor. Si hay uno o más errores, ocurrirán las siguientes situaciones:
La presentación fue cancelada. El formulario no se envía al servidor.
Todos los validadores no válidos son visibles.
Si un resumen de verificación contiene showummary = true, todos los errores del control de verificación se recopilan y su contenido se actualiza con esos errores.
Si un resumen de verificación contiene showMessageBox = true, los errores se recopilan y se muestran en el cuadro de información del cliente.
Debido a que los controles de verificación del cliente se ejecutan cada vez que se ingresa o envía un cambio, estos controles de verificación generalmente se evalúan en el cliente dos veces o más veces. Tenga en cuenta que después del envío, estos controles de verificación aún se reevaluarán en el servidor.
API del cliente
Hay una pequeña API que se puede usar en la máquina del cliente para lograr varios efectos en su propio código de cliente. Debido a que algunas rutinas no pueden estar ocultas, en teoría, puede aprovechar al cliente para que verifique todas las variables, características y funciones definidas por el script. Sin embargo, muchos de estos son detalles de implementación que se pueden cambiar. Lo siguiente resume los objetos del cliente que le recomendamos que use.
Tabla 3. Objetos del cliente
Nombre Tipo de descripción
La variable booleana PAGE_ISVALID indica si la página es actualmente válida. El script de verificación siempre mantiene la variable actualizada.
Page_Validators Element Array Esta es una matriz que contiene todos los validadores en la página.
La variable booleana Page_ValidationActive indica si se debe realizar la verificación. Establecer esta variable en falso se puede desactivar mediante la programación.
Propiedad booleana ISVALID Cada validador del cliente tiene esta propiedad que indica si el validador es actualmente válido. Tenga en cuenta que en la versión PDC, esta propiedad se mezcla con la caja superior y minúscula ("isValid").
Omitiendo la autenticación del cliente
Una tarea que a menudo debe realizar es agregar un botón de cancelación o un botón de navegación en la página. En este caso, es posible que desee enviar la página usando el botón, incluso si hay un error en la página. Debido a que el evento del botón del cliente "OnClick" ocurre antes del evento "OnSubmit" del formulario, puede evitar enviar cheques y pasar por alto la verificación. A continuación se describe cómo completar la tarea utilizando el control de imagen HTML como el botón Cancelar:
<input type = image runat = servidor
valor = "cancelar"
OnserverClick = cmdcancel_click>
Ejecutar esta tarea utilizando el botón o el control de Button causará cierta confusión porque se supone que el evento "OnClick" es un evento del lado del servidor con el mismo nombre. Debe establecer el 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>
Otra forma de resolver este problema es establecer el botón Cancelar para que no active el evento de confirmación en el script del cliente cuando regresa. Los controles HtmlinputButton y LinkButton son ejemplos de esto.
Efectos especiales
Otro requisito común es que en el caso de un error, además del mensaje de error que muestra el validador mismo, se requieren otros efectos requeridos. En este caso, cualquier modificación que realice debe realizarse simultáneamente en el servidor o el cliente. Supongamos que necesita agregar una etiqueta para cambiar el color dependiendo de si la entrada es válida o no. Aquí está cómo implementar esta tarea en el servidor:
Public Class ChangeColorPage: Page {
etiqueta pública lblzip;
Regularexpresión pública Validator Valzip;
anulación protegida void onload (EventArgs e) {
lblzip.forecolor = valzip.isvalid?
}
}
Todos los métodos anteriores son perfectos, pero siempre que modifique la verificación como se mencionó anteriormente, encontrará que a menos que haga lo mismo en el cliente, se verá muy inconsistente. El marco de verificación le impedirá muchos de estos efectos duales, pero no puede evitar otros efectos que debe lograr simultáneamente tanto en el cliente como en el servidor. Aquí hay un fragmento de realizar la misma tarea en el cliente:
<ASP: etiqueta id = lblzip runat = servidor
Text = "código zip:"/>
<ASP: TextBox id = txtzip runat = servidor
/> </asp: textbox> <br>
<ASP: RegulareXpressionValidator ID = Valzip Runat = Server
ControlTovalidate = txtzip
ErrorMessage = "código postal inválido"
ValidationExpression = "[0-9] {5}" /> <br>
<Script Language = JavaScript>
función txtziponchange () {
// Si la autenticación del cliente no está activa, no se realiza ninguna acción
if (typeof (page_validators) == "Undefinado") return;
// Cambiar el color de la etiqueta
lblzip.style.color = valzip.isvalid?
}
</script>
Beta 1 API del cliente
Para Beta Versión 1, algunas funciones que se pueden llamar desde los scripts del cliente pueden causar otras situaciones.
Tabla 4. Funciones llamadas desde los scripts del cliente
Descripción del nombre
ValidatorValidate (Val) toma un validador del cliente como entrada. Haga que el validador verifique su entrada y actualice su pantalla.
Validatorenable (Val, Enable) obtiene un validador de cliente y un valor booleano. Habilitar o deshabilitar el validador del cliente. Si está deshabilitado, el validador del cliente no será evaluado y el validador del cliente siempre aparecerá como válido.
ValidatorHookupControl (Control, Val) obtiene un elemento HTML de entrada y un validador del cliente. Modifique o cree el evento de cambio para ese elemento para que el validador se actualice cuando cambie. Esta función es adecuada para validadores personalizados basados en múltiples valores de entrada.
Su propósito especial es habilitar o deshabilitar el validador. Si desea que la verificación sea efectiva solo en una situación específica, es posible que deba cambiar el estado de activación tanto en el servidor como en el cliente, de lo contrario encontrará que el usuario no puede enviar la página.
El siguiente es el ejemplo anterior más un campo que se valida solo cuando una casilla de verificación no está marcada.
Public Class Conditional: Página {
Public htmlinputcheckbox chksameas;
Public RequiredFieldValidator rfvalshipaddress;
anulación protegida void validate () {
bool habilship =! chksameas.ecked;
rfvalshipAddress.enabled = EnlAntShip;
base.validate ();
}
}
Aquí está el código equivalente del cliente:
<input type = checkbox runat = servidor id = chksameas
> Igual que la dirección de pago <br>
<Script Language = JavaScript>
function onChangeSeMeas () {
var enableship =! Event.srcelement.status;
Validatorenable (rfValshipAddress, Enlanship);
}
</script>