jueves, 24 de diciembre de 2009

La segunda parte del tutorial de la revista Atix

La revista Atix en su número 14 publicó la segunda parte del tutorial sobre XML utilizando MonoDevelop.

Los archivos del proyecto y el código fuente correspondientes al proyecto de ejemplo del tutorial pueden ser descargados en un archivo comprimido desde este enlace.

Descarga el código fuente

lunes, 5 de octubre de 2009

Archivos del proyecto de la Revista Atix

La Revista Atix publicó la primera parte de un tutorial sobre XML utilizando MonoDevelop.

Desde este enlace se puede descargar un archivo comprimido, que contiene el código fuente del ejercicio y los archivos del proyecto.

Descarga el código fuente

viernes, 29 de mayo de 2009

Notas de Unified Modeling Language (UML)


Hace ya casi un mes que terminé un curso de UML y hace un par de semanas que me llego el número de serie para activar Enterprise Architect, la cual es una herramienta muy útil para realizar los diagramas UML que sean requeridos por el proyecto, aunque siempre es bueno capacitarse, lo mejor es practicar.

Las notas que elaboré del curso son las siguientes:

Hay que tener en cuenta que para todo proyecto, sobre todo de sistemas existen un ¿qué hacer? (análisis o modelo conceptual) y un ¿cómo hacer? (diseño o modelo de clases), donde hay actores o agentes externos al sistema.
De todas las metodologías hay metodologías que cubren la parte de administración y la parte de ingeniería dentro de la misma metodología, dos ejemplos de metodologías que cubren estos dos aspectos de los proyectos son: Microsoft Solution Framework (MSF) y Rational Unified Process (RUP), las características principales de este último son:


  1. Esta dirigido por casos de uso.
  2. Centrado en la arquitectura (tecnología, hardware, aplicación) y un ciclo de vida
  3. Es iterativo (cada dos o dos meses y medio entregar algo al cliente funcionando).

Este proceso toma una parte de la lógica del ciclo de vida en cascada, que tiene dos principios:

  1. No se puede programar algo que no está diseñado.
  2. No se puede probar algo que no está programado.


Buenas prácticas



  1. solicitar una recomendación para nomenclatura de proceso.
  2. solicitar procedimiento y reglamento.
  3. objetivo del proceso.
  4. usar verbos pasivos más el complemento para el nombre de las actividades.


Notas sobre los diagramas.


En los diagramas de actividades solo puede haber un estado inicial y un estado final.
Los diagramas de secuencia son uno a uno con los diagramas de casos de uso, es decir por cada diagrama de caso de uso debe de existir un diagrama de secuencia.
Cada diagrama no debe de tener más de nueve elementos en promedio de cinco a siete elementos.
Los actores primarios en el diagrama del caso de uso van del lado derecho y los actores secundarios van del lado izquierdo.
El término realización se refiere a que cada caso de uso realiza un requerimiento.
Nunca al redactarse un caso de uso se debe poner la palabra etc.
Siempre es bueno acompañar los diagramas con un glosario de términos.
Una forma de estimación de los casos de uso es la clasificación de actores, un ejemplo:
+-------------------------+
| Simple | 1 | Sistema |
+-------------------------+
| Mediana | 2 | Máquina |
+-------------------------+
| Dificíl | 3 | Humano |
+-------------------------+

En el modelo conceptual se muestran tanto las reglas físicas como las reglas de negocio.
El orden del ciclo hasta el diseño deberá ser:

Modelado del negocio: diagrama de Stakeholder y diagrama de proceso de negocio.


Requerimientos: matriz de requerimientos, matriz de trazabilidad y diagrama de casos de uso.


Análisis: descripción de alto nivel y especificación detallada de casos de uso.


Diseño: modelo conceptual, diseño detallado y prototipo.


Para aseguramiento de la calidad usar las revisiones de software y "poner puntos de control" es decir revisar los artefactos creados y regresar con el usuario.

El diagrama de comunicación solo muestra cuales son los mensajes.
El diagrama de secuencia muestra el orden en que deben de invocarse los mensajes.
Un escenario va de un estado inicial al estado final.
Siempre debemos de fijarnos entre la correspondencia entre el diagrama de secuencia y el diagrama de clases en cuanto a la multiplicidad, recordando que una multiplicidad se refiere a una colección.
En la nomenclatura de un diagrama de clases si se tiene dos puntos (:) se refiere a una instancia y si se tiene cuatro puntos (::) se refiere al namespace más la instancia.
Para hacer un diagrama de secuencia se debe de pensar en operaciones, en tiempo y en la responsabilidad.
Por buenas prácticas en el constructor solo se debe de poner los métodos que se inicialicen y se debe de separar de la invocación de los métodos.
Por estandarización no se ponen los retornos en el diagrama de secuencia, pero solamente si es necesario, la respuesta siempre regresa al actor que invoco el método.
Un caso de uso abstracto es un caso de uso que se utiliza para representar soluciones genéricas y se coloca dentro del paquete de casos de uso, este caso de uso se utiliza para ocurrencias que es una nota dentro del diagrama de secuencia que va hacia un diagrama de secuencia que está dentro del caso de uso abstracto.
La diferencia entre un diagrama de clases y un diagrama conceptual son los métodos, en el diagrama conceptual únicamente se muestran los atributos y la relación de los objetos además en el modelo conceptual se puede omitir el tipo de dato en cambio en el diagrama de clases es obligatorio poner el tipo de dato.
Una funcionalidad como los hilos (threads) solamente puede diagramarse en el diagrama de secuencia.
De un diagrama de secuencia puede sacarse el diagrama de colaboración o viceversa.
En un diagrama de actividades el estado inicial no es obligatorio.
En el diagrama de componentes existe el manifest: que indica una relación lógica entre el componente y un archivo físico.
En el diagrama de máquinas de estados, se ponen los objetos que más relaciones tienen además los diagramas de máquinas de estados son útiles en la etapa de análisis, aunque también pueden usarse en la etapa de diseño.



Esta herramienta también puede auxiliarnos en la etapa de desarrollo creando código desde el diagrama clases, aquí dependerá del lenguaje o los lenguajes que decidimos para el proyecto y por supuesto no olvidar que la notación de UML ayuda con un factor importante en los proyectos: la comunicación.

martes, 26 de mayo de 2009

Ingeniería de software

Hace un par de semanas me solicitaron la elaboración de dos propuestas, una para la migración y otra para un nuevo desarrollo por lo me solicitaron hacer un resumen general sobre Metodologías RUP, MSF y XP, el mismo para ambas propuestas, el resultado fue el siguiente:


Microsoft Solution Framework (MSF) proporciona un conjunto de modelos, principios, y guías para diseñar y desarrollar soluciones empresariales de una manera que asegura que todos los elementos del proyecto tal como gente, procesos y herramientas, puedan ser exitosamente conducidos. No solamente es aplicable a los proyectos de desarrollo sino igualmente a los de infraestructura o redes. MSF actualmente tiene dos instancias: MSF for Agile Software Development y MSF for CMMI (Capability Maturity Model Integration) Process Improvement.MSF contiene un meta-modelo que estaba basado en la filosofía de que un proceso esta creado para ayudar y no para estorba, este modelo es compartido para procesos agiles y maduros que ocupen MSF.MSF consta de cinco fases: Previsión, Planificación, Desarrollo, Estabilización e Implementación y es continuamente refinado por clientes, consultores, grupos de producto y partners de Microsoft.



Rational United Process (RUP) Es un refinamiento del proceso unificado, sus características principales son combinar las prácticas comúnmente aceptadas de los procesos incremental e iterativo. Su objetivo principal es entregar artefactos verificables por el cliente. El énfasis en el desarrollo iterativo e incremental previene muchos de los riesgos comunes en los proyectos al animar al equipo a desarrollar en principio lo más riesgoso del proyecto, además de que los artefactos y los roles de los participantes están bien definidos y que el proceso esta soportado por muchas herramientas de desarrollo, el proceso toma en cuenta que cada proyecto es diferente, con necesidades diferentes y habilita para que cada fase del proyecto sea personalizada para lo requerido por el proyecto. Este proceso comienza con la toma de requerimientos, el análisis y el diseño para todo el proyecto incluyendo el modelado de datos y de objetos antes de la construcción. En este sentido toma un enfoque de proceso en cascada para el análisis y el diseño y un enfoque iterativo para la construcción y la liberación.



Extreme Programming (XP) Los procesos ágiles mueven el enfoque de desarrollo de software hacia lo que se considera la importancia del desarrollo de software: ejecutar software. Esto es posible si se acepta que el desarrollo de software es un trabajo creativo hecho por seres humanos individuales, por eso este proceso anima a la comunicación, interacción y diversión. XP se distingue de otras metodologías en: es inmediato, concreto y se retroalimenta en ciclos muy cortos, tiene flexibilidad para programar las funcionalidades en acuerdo con los cambios en los requerimientos, se confía de pruebas automatizadas escritas por los programadores y clientes para monitorear el progreso del desarrollo que permite una detección de pruebas tempranas, se confía de la comunicación oral y el código fuente para mostrar la estructura del programa, tiene confianza en la cercana colaboración de los programadores con habilidades ordinarias. XP es diseñado para trabajar con proyectos que pueden ser construidos por equipos de dos a diez programadores.



En la revisión de las propuestas por parte del cliente, se selecciono la metodología MSF para el nuevo desarrollo y RUP para la migración, lo interesante de esta elección es que la tecnología empleada por el cliente en ambos proyectos es .NET, por lo que la elección natural hubiera sido MSF sin miramientos.

Pero bueno el cliente es el cliente y sus razones tendrá, aunque esta decisión no es tan dispar como pudiera parecerse, ya que MSF y RUP comparten una gran cantidad de artefactos, por lo que solo deberé que usar lo común a las dos metodologías.

domingo, 12 de abril de 2009

Prueba de conocimientos

Hace un par de meses con motivo de una consultoría una empresa transnacional me hizo un examen sobre conocimientos en C#, este examen me ha llamado la atención por el tipo de preguntas, que me da la impresión que era de un examen de Java y solo ajustaron las preguntas para C#, incluso en algunas preguntas decian "In Java we can .....bla,bla in C# how to .....bla,bla", como si asumieran que el entrevistado además de C# conoce Java, casos que no siempre es asi, algunas preguntas son en verdad muy buenas para conocer el nivel de programación.

Entre las preguntas se encontraban algunas que bien se podria responder dependiendo de la situación:

If you need to modify a value parameter to a function, which of the following can you do to achieve this?

1-. use a ref keyword
2-. use an out keyword
3-. use the return keyword
4-. All of Above

True or false Like in C++, using exception does carry some performance penalty.
1-. true
2-. false

if we want to hide a non virtual method, public void Print(), was the way to declare the method in the derived class?

1-.public void Print();
2-.public virtual void Print();
3-.public override void Print();
4-.public new void Print();


To catch all exceptions, which of the following would you declare?
1-.catch(...)
2-.catch(exception e)
3-.catch(throwable t)
4-.catch

En lo particular me gusta este tipo de exámenes ya que todas las respuestas son soluciones y solo es correcta la mejor, es decir la que es considerada como una buena práctica (best practice).

jueves, 5 de marzo de 2009

Code Access Security CAS, la seguridad en el código

CAS (Code Access Security), es la forma en que los ensamblados solicitan permisos para acceder a ciertos recursos para su ejecución en el CLR, esto proporciona seguridad a nivel código,como una forma complementaria y adicional a la seguridad del sistema operativo.

Esta seguridad debe estar presente sobre todo si de desarrollan componentes, plugins, add-ons o juegos que serán ejecutados en diferentes ambientes que no conocemos ni controlamos.
Señalo que esta seguridad es complementaria y en ningún momento deberá reemplazar la seguridad del sistema operativo.
Para explicar voy a usar un ejemplo, un banco nos solicito realizar un aplicación donde el usuario genera unos archivos de estados de cuenta esta aplicación en un diseño inicial esta compuesta por un formulario y un ensamblado que se encarga de generar el estado de cuenta en un archivo XML.
Obviamente una aplicación de esta naturaleza, necesitaría una disciplina de análisis y diseño, pero para fines ilustrativos, logramos llegar a la etapa de construcción sin la utilización del CAS.

La aplicación se mostraría más o menos así,





La operación de la aplicación consiste que cuando el usuario presione el botón de generar, se generaría un archivo XML en una carpeta restringida para ciertos usuarios, el código del método del ensamblado es el siguiente:




El método de la aplicación para invocar el método del ensamblado es el siguiente:


La aplicación es utilizada sin ningún problema hasta que varios archivos de estados de cuenta no coinciden al utilizarlos en la contabilidad, se encuentran localizados en una ubicación que no es la ruta predeterminada y el sistema operativo no indica ninguna excepción en las bitácoras de seguridad.
Supongamos que un usuario autenticado construye un programa malintencionado que ejecuta el método de nuestro ensamblado para escribir los estados de cuenta afuera de la carpeta predeterminada un código como el siguiente:




Para compilar este código usamos:
csc /r:Ensamblado1.dll SinPermiso.cs

Con la opción /r le indicamos al compilador, que haga referencia al metadata del ensamblado indicado, en este caso al Ensamblado1 donde se encuentra el método para generar estados de cuenta.
Al revisar los códigos observamos que el método esta implementado para generar los archivos debajo de una carpeta llamada [Banks] en la partición [C:\\] y que la protección de los valores del ensamblado dependerá de las validaciones que implementemos en el formulario de la aplicación, mas no del ensamblado mismo, por eso al invocar el método y pasar le la cadena con una secuencia ..\\ indicamos al ensamblado que escriba el archivo un nivel arriba.

Más que buscar un culpable a nivel usuario, la pregunta se plantea a nivel código:
¿como podemos evitar que el código realice operaciones para las que no fue diseñado?
La respuesta sin duda alguna es uno de los objetivos del CAS.
Usando CAS podemos evitar que un usuario o un proceso autenticado utilice los métodos del ensamblado para realizar acciones que no están consideradas en la lógica del programa.
Para lograr ese objetivo CAS utiliza permisos encapsulados como objetos que pueden ser usados a nivel de métodos o ensamblados, estos permisos pueden ser de manera declarativa usados como o como atributos dentro del código, en este ejemplo usaremos un permiso de forma declarativa para nuestro método.



Los permisos representan acciones que son revisadas cada vez que el CLR carga el ensamblado para ejecutarse, estos permisos son controlados por el CAS.

UIPermission Controla la manipulación a la interfaz de usuario y el portapapeles.
ResourcePermissionBase Controla el acceso a los recursos de Windows
RegistryPermission Controla el acceso al Registro de Windows
ReflectionPermission Controla el acceso a la funcionalidad de la reflexión proporcionada por el CLR
IsolatedStoragePermission Controla el acceso a isolated storage
FileIOPermission Controla el acceso de escritura o lectura al disco duro
FileDialogPermission Controla el acceso a archivos o carpetas.
EnviromentPermission Controla el acceso a leer, modificar y crear variables de ambiente.

Si ejecutamos nuevamente el código para escribir los estados de cuenta fuera de la carpeta predeterminada con el ensamblado modificado, se mostrará el siguiente error.



Ahora nuestro ensamblado esta protegido por la seguridad del CAS y no depende de la validación que implementen las clases que invoquen sus métodos.

Para habilitar o des habilitar la seguridad del CAS se utiliza la herramienta caspol con el siguiente argumento:
caspol -s on
Siempre es recomendable habilitar la seguridad del CAS.

Para compilar la aplicación:
csc /r:Ensamblado1.dll EstadosCuenta.cs EstadosCuenta.Designer.cs


 Descarga el código fuente

lunes, 23 de febrero de 2009

70-340 Implementando seguridad de aplicaciones C#

El día sábado presente el examen de certificación "70-340 Implementing Security applications with C#" que trata sobre seguridad de las aplicaciones .NET independientemente si son de tipo escritorio,Web o de consola, los temas igualmente aplican para las aplicaciones desarrolladas con Mono.

Este examen esta basado en el FrameWork .NET 1.1 (Visual Studio 2003, Mono 1.1) por lo que los temas y su ejemplos los ejecuté en mi vieja portátil que conserva este ambiente.

Entre los temas que trata están:

- CAS (Code Access Security)
- Autenticación
- Autorización
- SQL Injection
- Buenas prácticas de codificación (validar todas las entradas del usuario, uso de bloques try/catch/finally, uso de una cuenta con el menor privilegio)

Al final pase el examen con un mínimo necesario: 721 de 700.

Este examen se mantendrá hasta el mes de Marzo y sera retirado de las carreras de certificación.

Bibliografía recomendada:

Writing Secure Code, Second Edition: Michael Howard and David Leblanc


Professional C# 3rd Edition: Simon Robinson, Christian Nagel, Karli Watson, Jay Glynn, Morgan Skinner, Bill Evjen

domingo, 11 de enero de 2009

Usando los controles de validación ASP .NET III (RegularExpressionValidator)

Este control es verdaderamente útil, si necesitamos comparar el valor de un campo con una expresión regular , este control aplica esencialmente si queremos comparar el formato de una dirección de correo electrónico,una fecha o un código postal entre o bien para buscar un patrón dentro del texto.


Veamos el siguiente formulario como ejemplo:
<%@Page Language="C#" AutoEventWireup="false" 
CodeBehind="RegularExpression.aspx.cs"
Inherits="blog.listings.RegularExpression"
%>
<html>
<head>
<title>Expresiones Regulares</title>
</head>
<body>
<form id="form1" runat="server">
<table>
<tr>
<td>Fecha (dd/mm/yyyy)</td>
<td><asp:TextBox ID="txtDate" runat="server"></asp:TextBox></td>
<td>
<asp:RequiredFieldValidator ID="reqvtxtDate" runat="server"
ErrorMessage="* Obligatorio" ControlToValidate="txtDate">

</asp:RequiredFieldValidator>
<asp:RegularExpressionValidator ID="rexpvtxtDate" runat="server"
ErrorMessage="* Invalida"
ValidationExpression="(0[1-9]|[12][0-9]|3[01])[- /.]
(0[1-9]|1[012])[- /.](19|20)\d\d" ControlToValidate="txtDate">

</asp:RegularExpressionValidator>
</td>
</tr>
<tr>
<td>Teclea un URL</td>
<td><asp:TextBox ID="txtUrl" runat="server"></asp:TextBox></td>
<td>
<asp:RequiredFieldValidator ID="reqvtxtUrl" runat="server"
ErrorMessage="* Obligatorio" ControlToValidate="txtUrl">

</asp:RequiredFieldValidator>
<asp:RegularExpressionValidator ID="rexpvtxtUrl" runat="server"
ErrorMessage="* Invalida"
ValidationExpression="http://([\w-]+\.)+[\w-]+(/[\w- ./?%&amp;=]*)?"
ControlToValidate="txtUrl">

</asp:RegularExpressionValidator>
</td>
</tr>
<tr>
<td>Teclea un código postal</td>
<td><asp:TextBox ID="txtCp" runat="server"></asp:TextBox></td>
<td>
<asp:RequiredFieldValidator ID="reqvtxtCp" runat="server"
ErrorMessage="*Obligatorio" ControlToValidate="txtCp">

</asp:RequiredFieldValidator>
<asp:RegularExpressionValidator ID="rexptxtCp" runat="server"
ErrorMessage="* Invalido"
ValidationExpression="\d{5}(-\d{4})?"
ControlToValidate="txtCp">

</asp:RegularExpressionValidator>
</td>
</tr>
<tr>
<td>Correo Electrónico</td>
<td><asp:TextBox ID="txtEmail" runat="server"></asp:TextBox></td>
<td>
<asp:RequiredFieldValidator ID="reqvtxtEmail" runat="server"
ControlToValidate="txtEmail" ErrorMessage="* Obligatorio">

</asp:RequiredFieldValidator>
<asp:RegularExpressionValidator ID="rexptxtEmail" runat="server"
ErrorMessage="* Invalido" ControlToValidate="txtEmail" ValidationExpression="\w+([-+.]\w+)*@\w+([-.]\w+)*\.\w+([-.]\w+)*">

</asp:RegularExpressionValidator>
</td>
</tr>
</table>
<p><asp:Button ID="btnSubmit" runat="server" Text="Enviar"></asp:Button></p>
<asp:Label ID="lbMsg" runat="server"></asp:Label>
</form>
</body>
</html>

y su correspondiente código de clase:

Lo compilamos:

  • (.NET)csc /t:library -r:System.Web RegularExpression.aspx.cs
  • (mono) mcs /t:library -r:System.Web RegularExpression.aspx.cs

Lo instalamos: copiamos el ensamblado a la carpeta bin, ejecutamos xsp y abrimos el navegador con la dirección http://localhost:8080/RegularExpression.aspx. Al ejecutar el programa se mostrará como en la siguiente imagen.


Propiedades del control RegularExpressionValidator

  1. display Esta propiedad puede tener 3 valores: Static es la propiedad predeterminada, reserva un espacio suficiente en la página para mostrar el mensaje de error.Dynamic el espacio para mostrar el mensaje no se reserva, cuando el mensaje se despliega se desplaza el contenido existente en la página. None el mensaje no será desplegado en el lugar del control sino en el control ValidationSummary si se localiza en la misma página.

  2. ValidatorExpression El valor de la expresión regular con la que se compara el valor del control a validar.

  3. controlToValidate El identificador del control donde obtenemos el valor para validar.

  4. ErrorMessage El texto del mensaje de error a desplegar

 Descarga el código fuente

martes, 6 de enero de 2009

Usando los controles de validación ASP .NET II (RangeValidator)

Si necesitamos asegurarnos que el valor de un campo se encuentre dentro de unos limites es decir dentro de un rango especifico, el control RangeValidator se asegura que el valor de un campo sea del tipo que necesitemos y se encuentre dentro de los valores iniciales y finales que necesitemos, el código del formulario es el siguiente:


<%@Page language="C#" AutoEventWireUp="false" 
CodeBehind="ValidarRango"
Inherits="blog.listings.ValidarRango"
%>
<html>
<head><title>Validar Rango</title></head>
<body>
<p>Fecha de nacimiento</p>
<form id="frmRange" runat="server">
<table>
<tr>
<td>Dia</td>
<td>
<asp:TextBox id="txtDay" Runat="server" Maxlength="2"
Columns="3"></asp:TextBox>

<asp:RangeValidator id="rngvtxtDay" Runat="server"
Display="Dynamic" ErrorMessage="* Fuera de rango"
ControlToValidate="txtDay" Type="Integer" MinimumValue="1"
MaximumValue="31"></asp:RangeValidator>

<asp:RequiredFieldValidator id="reqvtxtDay" Runat="server"
ControlToValidate="txtDay" ErrorMessage="* Obligatorio">

</asp:RequiredFieldValidator>
</td>
</tr>
<tr>
<td>Mes</td>
<td>
<asp:TextBox id="txtMonth" Runat="server" Maxlength="2"
Columns="3"></asp:TextBox>

<asp:RangeValidator id="rngvtxtMonth" Runat="server"
Display="Dynamic" ErrorMessage="* Fuera de rango"
ControlToValidate="txtMonth" Type="Integer" MinimumValue="1"
MaximumValue="12"></asp:RangeValidator>

<asp:RequiredFieldValidator id="reqvtxtMonth" Runat="server"
ControlToValidate="txtMonth" ErrorMessage="* Obligatorio">

</asp:RequiredFieldValidator>
</td>
</tr>
<tr>
<td>Año (entre 1950 y 1989)</td>
<td>
<asp:TextBox id="txtYear" Runat="server" MaxLength="4"
Columns="6"></asp:TextBox>

<asp:RangeValidator id="rngvtxtYear" Runat="server" Display="Dynamic"
ErrorMessage="* Fuera de rango" ControlToValidate="txtYear" Type="Integer"
MinimumValue="1950" MaximumValue="1989"></asp:RangeValidator>

<asp:RequiredFieldValidator id="reqvtxtYear" Runat="server"
ControlToValidate="txtYear" ErrorMessage="* Obligatorio">

</asp:RequiredFieldValidator>
</td>
</tr>
</table>
<br>
<asp:Button id="btnSubmit" Runat="server" Text="Validar"></asp:Button>
<br>
<asp:Label id="lbMsg" Runat="server"></asp:Label>
</form>
</body></html>

y el código de la clase es:


Lo compilamos:

  • (.NET)csc /t:library -r:System.Web ValidarRango.aspx.cs
  • (mono) mcs /t:library -r:System.Web ValidarRango.aspx.cs

Lo instalamos: copiamos el ensamblado a la carpeta bin ejecutamos xsp y abrimos el navegador con la dirección http://localhost:8080/ValidarRango.aspx.
Si todo es correcto se mostrará la ejecucción como en la siguiente imagen:




Propiedades del control RangeValidator

  1. display Esta propiedad puede tener 3 valores: Static es la propiedad predeterminada, reserva un espacio suficiente en la página para mostrar el mensaje de error.Dynamic el espacio para mostrar el mensaje no se reserva, cuando el mensaje se despliega se desplaza el contenido existente en la página. None el mensaje no será desplegado en el lugar del control sino en el control ValidationSummary si se localiza en la misma página.

  2. type El tipo de datos de los valores a comparar, los tipos de datos disponibles para este control son: Currency (moneda), Date (fecha), Double (valor de punto flotante), Integer (Entero sin punto decimal), String (Cadena).

  3. controlToValidate El identificador del control donde obtenemos el valor para validar.

  4. minimumValue El valor mínimo del rango.

  5. maximumValue El valor máximo del rango.

 Descarga el código fuente

domingo, 4 de enero de 2009

Usando los controles de validación ASP .NET (RequiredFieldValidator)

Verificando la información de los formularios con los controles de validación


Algo indispensable en el desarrollo de formularios que trabajan con bases de datos, es la validación de los datos que solicitamos, acciones que son repetitivas e importantes ya que están relacionadas con la integridad y la seguridad de nuestra aplicación, una mala validación de los formularios puede convertirse en un problema que va desde un formato inadecuado o ataques con sentencias SQL (SQL Injection).
NET provee de controles web (Web Controls) de validación que nos ayudan a realizar este tipo de tareas, tareas como: verificar que los datos que necesitemos estén completos en el formulario, comparar que el tipo de datos que solicitemos coincida con el tipo de datos donde se va a almacenar en la base de datos, que los datos se encuentren en el formato que necesitamos, etc, estos controles no solo nos ahorran tiempo de codificación sino que también están diseñados para detectar la versión del navegador (browser) y así presentar el mejor HTML para ese navegador.


Validando los campos obligatorios con RequiredFieldValidator


Una de las primeras tareas que se necesitan cuando se desarrolla una aplicación es verificar que antes de que la información sea devuelta con los cambios hacie el servidor la información cumpla con los
criterios obligatorios para continuar, incluso antes de la tarea de validar el formato de los campos, debemos asegurarnos que eses campos tienen información y los campos necesarios no estan sin información, el control RequiredFieldValidator nos ayuda a esa tarea, el código del formulario es el siguiente:


y el código de la clase es:


Lo compilamos:

(.NET) csc /t:library CampoRequerido.aspx.cs
(mono) mcs /t:library CampoRequerido.aspx.cs

Lo instalamos: copiamos el ensamblado a la carpeta bin
ejecutamos xsp y abrimos el navegador con la dirección http://localhost:8080/CampoRequerido.aspx


Al presionar el botón para enviar los datos al servidor se verifica que el atributo de la página Page.IsValid regrese un valor verdadero, si es falso desplegará el mensaje de error de lo contrario desplegará el texto en el control etiqueta Label. En la siguiente imagen se muestra la ejecucción del programa.



Propiedades del control RequiredFieldValidator

  1. controlToValidate El control de donde obtendremos el valor para evaluar

  2. errorMessage El texto del mensaje que se desplegara si no se cumplen las condiciones

  3. display Esta propiedad puede tener 3 valores: Static es la propiedad predeterminada, reserva un espacio suficiente en la página para mostrar el mensaje de error.Dynamic el espacio para mostrar el mensaje no se reserva, cuando el mensaje se despliega se desplaza el contenido existente en la página. None el mensaje no será desplegado en el lugar del control sino en el control ValidationSummary si se localiza en la misma página.


 Descarga el código fuente