2009-03-17 14 views
22

Tengo una pregunta sobre qué podría impedir que RequiredFieldValidator evite una devolución de datos.ASP.net ObligatorioFieldValidator no previene la devolución de datos

Empecé a trabajar en un formulario aspx más antiguo pero simple y mi predecesor usó la validación manual del formulario del lado del servidor (comprobando si algunos campos tienen un valor y si no muestran un mensaje de error en una etiqueta). Pensé que limpiaría algún código innecesario y reemplazaría la comprobación manual con los controles RequiredFieldValidator, pero aunque parecen estar validando, no impiden una devolución de datos. Es decir, me aparecen mis mensajes de error pero la devolución de datos todavía ocurre.

El formulario es bastante simple y no hay atributos CausesValidation = "false" establecidos. Mis controles se parecen:

<asp:TextBox ID="txtPhone" Runat="server" Columns="20" MaxLength="20" /> 
<asp:RequiredFieldValidator ID="rfvPhone" runat="server" Display="Dynamic" 
     ErrorMessage="* Required" ControlToValidate="txtPhone" /> 

he creado un nuevo formulario web en el mismo proyecto con un solo cuadro de texto, validador y botón de enviar y actúa de la misma manera. Aparece un mensaje de error, pero aún se produce una devolución de datos.

¿Existe una configuración global o para todo el proyecto que pueda causar este comportamiento? Algo en el web.config o global.asax?

+0

Me encontré con este problema cuando me conecté al evento onClientClick de mi asp: botón. Si hay una forma de ordenar los eventos y mantener el agregado por asp.net asumiendo primero que cancelaría los siguientes eventos, entonces estaría bien. –

Respuesta

31

Whew. De acuerdo, encontré el problema, básicamente creando un nuevo proyecto y comparando su web.config línea por línea con mi proyecto anterior. Resulta que el culpable es la siguiente:

<xhtmlConformance mode="Legacy"/> 

Si quito la línea, mi validación funciona de la manera que esperaba que. Google que descubrió un montón de publicaciones de blog sobre cómo VisualStudio agrega esa línea a web.config al actualizar aplicaciones web de .net 1.1 a .net 3.5.

Las publicaciones del blog se quejaban principalmente de cómo ese campo interfiere con el material AJAX de .net, pero supongo que se mezcla con el JavaScript emitido para RequiredFieldValidator de una manera similar.

+1

Wow. Simplemente guau. ¿Cómo nunca me he encontrado con esto antes? Este es un gran problema porque la validación del lado del servidor no detiene la activación de ningún evento, solo establece la propiedad IsValid. Básicamente, he estado codificando ASP.NET incorrectamente. : | – Bryan

+0

Esto me llevó mucho más tiempo de lo que me gustaría admitir para encontrar como la causa de los problemas de validación en nuestra aplicación. –

+0

He pasado mucho tiempo tratando de arreglar esto ... FYI para otros usuarios, esta línea funciona bien en IE, pero eliminando estas correcciones para Chrome, FF y opera. – Botonomous

0

¿Podría probar un parámetro explícito EnableClientScript="True" para RequiredFieldValidator?

9

La validación puede ocurrir en el cliente, si está disponible, o en el servidor. El trabajo del validador no es evitar una devolución de datos, es validar la entrada.

Asegúrate de tener javascript habilitado e intenta establecer explícitamente "EnableClientScript" en verdadero.

En el código subyacente, nunca debe confiar en que los validadores estén validando en el cliente, y siempre use "if Page.IsValid".

+0

Hmm ... Puedo y lo cambiaré para verificar si el formulario es válido, pero tengo curiosidad por saber por qué este proyecto se comporta de manera diferente a los proyectos web que he creado. – Dana

+0

Cualquier posibilidad de que su validador se configure programáticamente en Visible = "false", o los clics de su botón están llamando a envíos de formularios manualmente desde javascript (evitando así la llamada del lado del cliente DoPostBackWithOptions())? – womp

+0

No, creo una forma completamente nueva en el mismo proyecto para probar eso y la nueva forma muestra el mismo comportamiento. – Dana

0

Si presiona "Enter" dentro de un cuadro de texto para enviar el formulario, no creo que los validadores impidan la devolución de datos.

4

Tuve el mismo problema, pero la respuesta resultó ser bastante diferente. También estaba actualizando a la validación de .NET desde la validación de código duro del lado del servidor.

El problema en mi caso resultó estar relacionado con el motor de reescritura de ASP.NET utilizado en el artículo URL Rewriting in ASP.NET de MSDN. Usar la implementación predeterminada del "Formulario sin acción" fue el culpable, aparentemente este fue escrito basado en una versión anterior de .NET y el JavaScript en el formulario que impedía que la devolución de datos no se enviara a la salida porque faltaba el código .

De todos modos, por si alguien más está usando este motor de reescritura, la solución era cambiar la aplicación por defecto de ActionlessForm a lo siguiente:

Public Class Form 
    Inherits System.Web.UI.HtmlControls.HtmlForm 

    Protected Overrides Sub Render(ByVal writer As System.Web.UI.HtmlTextWriter) 
     MyBase.Render(New ActionlessFormHtmlTextWriter(writer)) 
    End Sub 

End Class 

Public Class ActionlessFormHtmlTextWriter 
    Inherits HtmlTextWriter 

    Sub New(ByVal writer As HtmlTextWriter) 
     MyBase.New(writer) 
     Me.InnerWriter = writer.InnerWriter 
    End Sub 

    Sub New(ByVal writer As System.IO.TextWriter) 
     MyBase.New(writer) 
     MyBase.InnerWriter = writer 
    End Sub 

    Public Overrides Sub WriteAttribute(ByVal name As String, ByVal value As String, ByVal fEncode As Boolean) 

     Dim Context As HttpContext = HttpContext.Current 

     'Skip the action attribute of the form control. 
     If Not (name = "action") OrElse Not Context.Items("ActionAlreadyWritten") Is Nothing Then 

      MyBase.WriteAttribute(name, value, fEncode) 

     Else 
      Context.Items("ActionAlreadyWritten") = True 
     End If 
    End Sub 

End Class 

Lo que esto hace es simplemente suprimir el atributo de acción, pero permitir que cualquier otra lógica en el marco para ejecutar. Esto debería prueba futura esto en caso de que Microsoft decida cambiar el formulario nuevamente.

+0

¡Tenía exactamente el mismo problema! Gracias por publicar, me hubiera llevado una eternidad encontrar el problema. – Onisemus

Cuestiones relacionadas