viernes, 24 de agosto de 2007

ONO y sus "trampas"

El otro día estaba viendo el partido de BA-LON-CES-TO por laSexta (grande España, grande!!, o mejor dicho, estaba disfrutando de la paliza que España le dio a Lituania. El caso es que, en uno de los tiempos muertos, en lugar de dejar que los telespectadores contemplemos el trabajo de esas sacrificadas cheerleaders (nunca entenderé lo poco que se les valora, máxime cuando algunas son INGENIERAS AEROESPACIALES!!!! Ahí es nada...), la Sexta nos puso una publicidad de ONO.
Pues bien, el susodicho anuncio decía que ONO ofrecía a sus nuevos clientes 20partidos de fútbol por 30€... SÓLO PARA NUEVOS CLIENTES!!
Como soy cliente, me apresuré en entrar en la web de la operadora para comprobar si esta oferta también valía para los que ya somos clientes... Pues no! En las condiciones ponía bien claro que la oferta sólo era válida para nuevos clientes y con un contrato de permanencia de esos que casi son de por vida.
Ya había olvidado el tema, casi, cuando ayer me puse a ojear la revista esa que envían a los clientes. Sí, esa que nadie lee dónde ponen la programación y cosas de esas. Entonces recordé lo de la oferta y busqué por la revista a ver si ponía algo de los precios de los partidos de fútbol.
Y vaya si lo ponía... 11 eurazos y pico por partido!!!
Menos mal que vi que había bonos!! Bueno, menos mal no. Casi que la expresión sería "más mal!".... Os digo los precios de los bonos a ver que os parecen:
10 partidos: 105€
20 partidos: 195€ (ojo! no nos olvidemos del precio de oferta: 30€)
Abono de temporada: 43€ AL MES!!!
En fin... ya lo estaba dando por perdido cuando en casa hemos pensado: "cómo puede ser que para los clientes que ya somos de ONO cueste tanto y para los nuevos tan poco". No es que pensemos que esté mal que las operadoras intenten atraer a nuevos clientes con ofertas, sino que pensamos que también deben cuidar a los clientes que ya son de ONO y ofrecerles esas mismas ofertas...
El caso es que hemos llamado a ONO. Ha contestado una persona que, obviamente, no era de España. Y al preguntarle sobre la oferta nos ha contestado que "la oferta también es válida para los clientes que ya son de ONO".
GENIAL!! Ya tenemos el bono de 20 partidos de fútbol!!!

Pero todo esto te hace plantearte muchas cosas, no creéis?? ¿Por qué en los sitios dónde los clientes pueden ver los precios no pone el precio de oferta? ¿Por qué en los sitios dónde pone la oferta pone que sólo es válida para nuevos clientes?
Las respuestas, creo yo, se basan en una estrategia comercial muy sencilla: "Si el cliente lo quiere comprar y no dice nada de la oferta, pues le cobro más. Y si dice algo de la oferta, pues le cobro lo que tengo que cobrarle."
Se tendrían que plantear que a lo mejor mucha gente que compraría partidos de fútbol no lo hace por esos precios tan altos. Y que no todos van a preguntar por la oferta, por lo que posiblemente estén perdiendo más de lo que ganarán al cobrar precios tan exagerados....
En fin, no sé, es sólo una opinión... Supongo que lo tendrán estudiado... O NO... (qué juego de palabras, eh???)

Saludos!

jueves, 23 de agosto de 2007

RequiredFielValidator, Buttons y ValidationGroup

Esta mañana me he encontrado con un pequeño obstáculo en la programación de mi proyecto. Como considero que es interesante que la gente lo sepa, pues aquí os lo dejo, por si alguna vez os hace falta.
Primero os pongo en situación...

En un control de usuario, necesitaba insertar unos controles de validación de ASP.NET. Concretamente, necesitaba el control RequiredFieldValidator. Como supongo que sabéis, este control evalúa el valor de un control de entrada en una aplicación ASP.NET para asegurarnos que tiene algún valor. De esta forma evitamos errores en la introducción de valores.
Este control forma parte de un grupo de controles de validación que nos permiten no sólo evitar que un control de entrada se deje vacío, sino además podemos hacer que sigan ciertas normas.

El caso es que en el control había diferentes popups cada uno con su texto de entrada y sus botones asociados para introducir los datos o cancelar la introducción. La verdad es que es un tema un poco difícil de explicar, así que propondré un escenario parecido pero más sencillo.

Imaginad que estamos programando una web en la que, entre otras cosas, tenemos que poder introducir nuevos productos que luego podremos vender. Asimismo, tenemos que poder introducir algún tipo de clasificación. Concretamente, tenemos una página de la web en la que podemos crear nuevos tipos y subtipos de productos. Simplificando al máximo, el código sería el siguiente:

<h3>Nuevo Tipo</h3>

<asp:label id="tipoLabel" runat="server" text="Introducir nuevo tipo:"></asp:label>
<asp:textbox id="tipoTextBox" runat="server"></asp:textbox>

<asp:button id="introducirTipoButton" runat="server" text="Introducir" >
</asp:button>

<h3>Nuevo Subtipo</h3>

<asp:label id="subtipoLabel" runat="server" text="Introducir nuevo subtipo:"></asp:label>
<asp:textbox id="subtipoTextBox" runat="server"></asp:textbox>
<asp:button id="introducirSubtipoButton" runat="server" text="Introducir" validationgroup="subtipoValidation">
</asp:button>


A este código le añadimos dos controles de validación del tipo RequiredFielValidator para evitar que un usuario "despistado" pueda darle a cualquiera de los botones e introducir una clase o subclase vacías. El código resultante será:
<h3>Nuevo Tipo</h3>

<asp:label id="tipoLabel" runat="server" text="Introducir nuevo tipo:"></asp:label>
<asp:textbox id="tipoTextBox" runat="server"></asp:textbox>
<asp:RequiredFieldValidator ID="tipoRequiredFieldValidator"
runat="server"
ErrorMessage="Escribe algo!!"
ControlToValidate="tipoTextBox"/
<
<asp:button id="introducirTipoButton" runat="server" text="Introducir" validationgroup="tipoValidation">
</asp:button>

<h3>Nuevo Subtipo</h3>

<asp:label id="subtipoLabel" runat="server" text="Introducir nuevo subtipo:"></asp:label>
<asp:textbox id="subtipoTextBox" runat="server"></asp:textbox>
<asp:button id="introducirSubtipoButton" runat="server" text="Introducir" >
</asp:button>
<asp:RequiredFieldValidator ID="subtipoRequiredFieldValidator"
runat="server"
ErrorMessage="Aquí también tienes que escribir algo!!"
ControlToValidate="subtipoTextBox" /
>

Parece que todo está correcto, ¿verdad? Pues bien, probadlo y veréis como no es así.
El problema reside en que los controles de validación están esperando una señal para comprobar si el usuario ha rellenado o no el textbox correspondiente. Como los dos botones causan validación (es el comportamiento por defecto) en cuanto apretamos uno de ellos, pues los controles de validación comprueban si hemos escrito algo en los controles que ellos controlan, valga la redundancia, de forma que apretemos el que apretemos siempre saldrán los mensajes de comprobación.
La solución que se creó para esto es bien sencilla. Podemos asociar los controles (el Button y el RequiredFielValidator) a un grupo de validación mediante la propiedad ValidationGroup. De esta forma, el Button sólo enviará la señal a aquellos controles que formen parte del mismo grupo de validación.
El código quedaría así:
<h3>Nuevo Tipo</h3>

<asp:label id="tipoLabel" runat="server" text="Introducir nuevo tipo:"></asp:label>
<asp:textbox id="tipoTextBox" runat="server"></asp:textbox>
<asp:RequiredFieldValidator ID="tipoRequiredFieldValidator"
runat="server"
ErrorMessage="Escribe algo!!"
ControlToValidate="tipoTextBox"
ValidationGroup="tipoValidation" /
<
<asp:button id="introducirTipoButton" runat="server" text="Introducir" validationgroup="tipoValidation">
</asp:button>

<h3>Nuevo Subtipo</h3>

<asp:label id="subtipoLabel" runat="server" text="Introducir nuevo subtipo:"></asp:label>
<asp:textbox id="subtipoTextBox" runat="server"></asp:textbox>
<asp:button id="introducirSubtipoButton" runat="server" text="Introducir" validationgroup="subtipoValidation">
</asp:button>
<asp:RequiredFieldValidator ID="subtipoRequiredFieldValidator"
runat="server"
ErrorMessage="Aquí también tienes que escribir algo!!"
ControlToValidate="subtipoTextBox"
ValidationGroup="subtipoValidation" /
>
Sencillo, ¿verdad? Una vez se conoce la solución, sí que es sencillo. Por si os sirve de algo, la solución la encontre en este post de los foros de ASP.NET.

¿Le ponemos la guinda al pastel?
Imaginad que todo esto lo tengáis en un popup y queráis poner un botón que cancele la introducción y cierre el popup. Independientemente del código asociado, al introducir un botón, cuando hagamos click en él, se producirá la validación de nuevo y, si tenemos algún control de validación sin grupo de validación asociado, puede que haga que dicho control salte porque no se cumple la condición que el valida. Por supuesto, no se cerrará el popup...
¿Y esto por qué pasa? Sencillamente, porque, como hemos dicho, los controles Button por defecto tienen una propiedad activada que se llama CausesValidation (causa validación).
Lo único que tenemos que hacer es poner dicha propiedad a false... (OJO, siempre que no necesitemos dicha validación!!).
Por ejemplo, el botón quedaría así:
<asp:Button ID="cancelButton"
runat="server"
Text="Cancelar"
CausesValidation="false" /
>

Esta solución la tuve que aplicar en un PopupControlExtender del Ajax Control Tookit de ASP.NET para cerrar el popup que se abre y que no me causara la validación de los datos introducidos. El post dónde encontré la solución lo podéis leer aquí.
Espero que os pueda servir de algo.

Un saludo!