Tipos anulables en .NET 2.0

Una interesante característica nueva que ofrece la versión 2.0 de la plataforma.NET es la de «Tipos anulables» o, en inglés, «Nullable types».


Se trata de un tipo especial de dato que permite que los tipos base por valor se puedan comportar como valores por referencia nulos cuando sea necesario (repasa mi post sobre tipos por valor y por referencia).


De este modo este nuevo tipo anulable permite representar valores concretos o la ausencia de valor. Por ejemplo, una variable de tipo ‘int’ siempre contiene un número entero. Aunque no le asignemos explícitamente nada, al ser un tipo base por valor siempre toma un valor por defecto, en este caso concreto un 0. Pero claro, un 0 no es lo mismo que decir ‘esta variable no contiene valor alguno’.


En el caso de las clases (tipos por referencia) la ausencia de «valor» se representa asignándole un nulo a la variable, pero en los tipos por valor esto no es posible.


¿No sería estupendo disponer de un híbrido entre estos dos comportamientos?


Pues sí. Veamos el porqué…


El caso prototípico en el que esto es muy útil es al obtener ciertos campos desde una base de datos los cuales contienen tipos base (enteros, cadenas, etc…) pero que permiten albergar valores nulos. Este tipo de datos pueden existir (en cuyo caso es un valor concreto) o ser nulos (o sea, no existen). Sin embargo al intentar asignar un valor nulo (o también un System.DBNull) a un tipo por valor como un entero se producirá una excepción. Esto es lo que pasaba en las versiones anteriores de .NET.


¿Cómo se definen?


Para definir un tipo anulable en C# se usa una interrogación al final de la declaración del tipo, así por ejemplo:



int? miEnteroAnulable;


Es decir se declara igual que un entero normal pero con una interrogación.


En VB.NET la sintaxis es diferente y sería así:



Dim miEnteroAnulable As Nullable(Of Integer)


Como vemos en este lenguaje se indica de manera menos sútil, pero ambas declaraciones son equivalentes.


¿Es una onda o es una partícula? ¿Cómo se comporta?


Cuando declaramos un tipo como Nullable, cuando este contiene un valor se comporta a todos los efectos como un tipo por valor, o sea, como siempre. Cuando se le asigna un nulo no se queja (no hay excepción) y, en realidad, se convierte en un tipo por referencia para permitirlo mediante una operación de ‘Boxing’. Es como la luz que es dos cosas al mismo tiempo 😉


Lo que pasa por debajo es que la CLR trata el tipo anulable como una estructura (por lo tanto como un tipo por valor) cuando éste se comporta como un valor, y como una clase (o sea, un tipo por referencia) cuando se comporta como una referencia. Esto lo hace de modo transparente para nosotros.


El tipo Nullable dispone de dos propiedades fundamentales que nos permiten lidiar con él de forma idéntica bien sea una clase o bien una estructura.


La propiedad HasValue nos permite saber si el tipo contiene un valor o por el contrario es nulo.


La propiedad Value nos devuelve el valor subyacente al tipo (un entero o lo que sea) siempre y cuando HasValue sea verdadera. Si intentamos leer esta propiedad cuando HasValue es falsa se genera una excepción de tipo InvalidOperationException.


En resumen…


Los tipos anulables tienen grandes aplicaciones, sobre todo en el mundo de las bases de datos y están integrados en la propia CLR por lo que se pueden usar desde cualqueir lenguaje. Aunque tras haber leído lo anterior te puedan parecer alejados de tus necesidades actuales dales una oportunidad. Una vez que empieces a utilizarlos no podrá vivir sin ellos 🙂

SSL y algunos conceptos erróneos sobre seguridad

El otro día en el Blog de George Ou en ZDNet apareció este artículo sobre seguridad HTTPS (SSL) en los bancos: «Many Banks failing to use SSL authentication«. En él George hablaba sobre muchos bancos americanos y el problema que suponía para ellos el hecho aparentemente inocente de que su página principal, en la que está también el login a su banca electrónica, no usase SSL. Por suuesto en cuanto metías los datos y dabas a «Entrar» las comunicaciones se encriptaban, pero quizá era ya demasiado tarde. Vale la pena echarle una lectura rápida…


El caso es que el artículo en cuestión levantó mucha polémica (a más de un mal webmaster le tocó las narices) y poco después, hace unos días, sacó otro artículo en respuesta a esas críticas en el que analizaba las declaraciones oficiales al respecto que se hacían en una página de la Marina Estadounidense.


Si bien los conceptos relacionados son básicos a más de uno le vendrá bien echarle un repaso a lo que comenta ya que si el Ejército de los USA tiene algunas convicciones tan erradas acerca de la seguridad, mejor apaga y vámonos.


Primero dicen que, dado que a partir de que envías los datos, la comunicación es segura no hay que preocuparse. Como bien dice George el que afirma esto debería estar en la calle o al menos deberían obligarlo a asistir a alguno de los seminarios de Chema Alonso y el Padre Parada para comprobar lo fácil que es realizar envenenamiento de DNS con herramientas gratuitas como Cain.


Otra de las disculpas alegadas es que «lo hace mucha otra gente». Bueno, sin comentarios.

Funcionalidad AJAX en el control GridView de ASP.NET 2.0

Volviendo un poco sobre el tema de AJAX que ya he tratado en muchos de los post anteriores, voy a hacer un pequeño comentario respecto a dotar de funcionalidad similar a la esperada en un entorno AJAX cuando estamos usando el nuevo control GridView de ASP.NET 2.0.


Como es sabido este estupendo control nos permite dotar de funcioalidades de paginación y ordenación de datos a un origen de datos sin necesidad de escribir código alguno. Lo que ya no sabe mucha otra gente es que, además, en la mayoría de los casos se puede conseguir esta funcionalidad sin tener que refrescar la página completa, al más puro estilo AJAX. De este modo al pulsar sobre la cabecera de la rejilla o al cambiar de página se recargan exclusivamente los contenidos de ésta, pero sin realizar un «PostBack» al servidor que fuerza el refresco de la página completa.


Para ello sólo es necesario establecer a true la propiedad EnableSortingAndPagingCallbacks del control, como ilustra la figura del lateral.


Al hacerlo se consigue este efecto tan útil y espectacular. Para ello lo que han hecho los programadores de ASP.NET es implementar la interfaz ICallBackEventHandler en el control GridView, y en concreto en el código de los métodos GetCallBackResultRaiseCallbackEvent. Se puede ver el códgo con cualquier decompilador:



protected virtual string GetCallbackResult()
{
  StringWriter writer1 = new StringWriter(CultureInfo.InvariantCulture);
  HtmlTextWriter writer2 = new HtmlTextWriter(writer1);
  IStateFormatter formatter1 = this.StateFormatter;
  this.RenderTableContents(writer2);
  writer2.Flush();
  writer2.Close();
  string text1 = formatter1.Serialize(this.SaveDataKeysState());
  string text2 = formatter1.Serialize(this.SortExpression);
  return (Convert.ToString(this.PageIndex, CultureInfo.InvariantCulture) + «|» + Convert.ToString((int) this.SortDirection, CultureInfo.InvariantCulture) + «|» + text2 + «|» + text1 + «|» + writer1.ToString());
}


y



protected virtual void RaiseCallbackEvent(string eventArgument)
{
  string[] textArray1 = eventArgument.Split(new char[] { ‘|‘ });
  IStateFormatter formatter1 = this.StateFormatter;
  base.ValidateEvent(this.UniqueID, «»» + textArray1[0] + «|» + textArray1[1] + «|» + textArray1[2] + «|» + textArray1[3] + «»»);
  this.LoadHiddenFieldState(textArray1[4], textArray1[5], textArray1[6], textArray1[7]);
  int num1 = int.Parse(textArray1[0], CultureInfo.InvariantCulture);
  string text1 = textArray1[2];
  int.Parse(textArray1[1], CultureInfo.InvariantCulture);
  if (num1 == this.PageIndex)
  {
    SortDirection direction1 = SortDirection.Ascending;
    string text2 = (string) formatter1.Deserialize(text1);
    if ((text2 == this.SortExpressionInternal) && (this.SortDirectionInternal == SortDirection.Ascending))
    {
      direction1 = SortDirection.Descending;
    }
    this.SortExpressionInternal = text2;
    this.SortDirectionInternal = direction1;
    this._pageIndex = 0;
  }
  else
  {
    this.EditIndex = -1;
    this._pageIndex = num1;
  }
  this.DataBind();
}


Dentro de unos días, en cuanto saque tiempo, intentaré publicar unos cuantos post sobre cómo implementar este tipo de llamadas asíncronas estilo AJAX con lo que nos ofrece «de serie» la plataforma .NET 2.0. La verdad es que es un tema muy chulo, ya lo vereis, y así le doy una cierta continuidad a la serie sobre AJAX que comencé ateriormente.


Un par de cosas a tener en cuenta


Ojo con esta propiedad. Aunque es muy útil y funciona muy bien en muchos casos tiene un par de cuestiones que se deben tener en cuenta para que funcione.


Primero: no funcionará si metemos alguna columna de la rejilla que sea una plantilla, es decir, alguna que no sea un control BoundField o derivado que son los que añade autoáticamente el GridView y cuyo HTM es capaz de generr por si mismo. Si metemos una plantilla la próxima vez que ejecutemos la página que contiene la rejilla se producirá una excepción que nos avisa precisamente de eso.


Segundo: si no hemos usado como origen de datos un control (un SqlDataSource o un ObjectDataSource, etc…) no funcionará la ordenación ni la paginación estilo AJAX. Ello es debido a que se debe llamar a DataBind al final (puedes verlo en el código anterior) y por lo tanto debe haber algún control enlazado permanentemente a la rejilla. Lo explican los chicos de Microsoft en la Web de comentarios del producto de MSDN.


Ya sabeis como quedar biencon vuestros clientes y colegas gracias a esta propiedad 🙂

XHTML (y IV) – Uso del estándar desde ASP.NET 1.1

Todo lo que he contado hasta ahora es estupendo si ya te has pasado a ASP.NET 2.0 y VS2005 Pero ¿qué pasa con los que todavía siguen usando la versión anterior, ASP.NET 1.1?


Pues que están bastante fastidiados si necesitan XHTML, la verdad.


RDKeyPero como casi todo en esta vida tiene solución y encima está en Internet 😉 los amigos de RiderDesing.com (especializados en sitios Web ecuestres, lo flipas) han creado un gestor de peticiones para ASP.NET 1.1 que se encarga de que las páginas hechas en ésta versión generen XHTML 1.1 Strict, incluso quitando el atributo ‘target’ de los enlaces y otras lindezas por el estilo.


Y encima es gratuito (o eso parece).


Por si fuera poco tiene otro más que genera XHTML 1.0 Transitional, para cuando no se necesita tanta rigidez. Muy interesante.


Los puedes descargar desde la página de productos de RiderDesign.

XHTML (III) – Validación desde el entorno de desarrollo

Siguiendo con la serie iniciada hace poco sobre XHTML, y para terminarla, vamos a ver cómo establecer las opciones de validación de éste desde Visual Studio 2005.


Cuando editamos una página en modo «Marcadores» (es decir, viendo el código HTML) el editor nos ayuda con «Intellisense» (es decir, adelantándose a lo que vamos a escribir para no tener que aprendernos los atributos y valores) y además valida los posibles errores de una manera similar a como lo hace Word cuando encuentra faltas ortográficas: subrayándolos con una línea ondulada de color azul:



Además del subrayado también nos ofrece información sobre el error en el «Tooltip» que aparece cuando nos colocamos encima con el cursor, y si tenemos abierta la ventana de errores veremos una lista con todos ellos.


La validación se realiza contra el esquema definido para la página actual, que puede ser uno cualquiera de los disponibles en Visual Studio o alguno definido por terceras partes que le añadamos. Por defecto se utiliza XHTML 1.0 Transitional, que es el que usan Internet Explorer 6, Opera 7, Netscape 7 y Firefox. Pero podemos escoger muchos otros.


Para decidir qué esquema vamos a utilizar se usa la lista desplegable ubicada en la parte superior:



Como se puede observar existen todas las posibilidades para XHTML que comentábamos en los post anteriores y algunas más, incluso para compatibilidad con navegadores tan viejos como Netscape 3 o IE 3.


Por cierto, quiero llamar tu atención sobre el botón situado justo a la derecha de la lista que parece el de una señal de aparcamiento para discapacitados. En efecto, lo has adivinado: sirve para validar nuestra página contra los estándares de accesibilidad de la W3C. ¡Genial! ¿verdad?


IMPORTANTE: La opción de validación que elijamos aquí no tiene nada que ver con el HTML que generan los controles ASP.NET. Éstos siemrpe se adaptan al navegador que solicita la página y, siempre que pueden, generan XHTML 1.1, así que no debemos preocuparnos de ellos, sólo de las etiquetas que introduzcamos nosotros a mano. Que quede claro: una cosa es la validación y otra la generación de código.


Ajustes del entorno para validación


Se puede controlar qué aspectos de cada esquema se verifican por parte del editor en cada caso acudiendo al diálogo de opciones (Herramientas·Opciones) del entorno de desarrollo y acudiendo al nodo HTML·Validación, como se observa en la figura siguiente:



Aquí basta con elegir de la lista un esquema para poder decidir qué aspectos concretos de éste se usarán en la validación e, incluso, poder desactivarlo por completo.

DotnetNuke starter kit: ¡no lo instales, es un peligro!

Estoy fastidiado 🙁


Hoy se me ocurrió la brillante idea de instalar en mi equipo de trabajo el Starter Kit de DotNetNuke 4.x (no me voy a molestar ni en poner la URL a este programa). Se trata de un software de código abierto para ASP.NET 2.0 que permite crear aplicaciones de contenido Web sin mucho esfuerzo.


El caso es que al hacerlo me ha fundido por completo mi Visual Studio 2005. Ahora o puedo hacer absolutamente nada. Lo he intentado reparar, reinstalar e incluso volver a un estado anterior con un punto de restauración del sistema. NADA. No hay forma de recuperar el entorno. Muerto, eliminado, kaput… 🙁 En cuanto intentas crear cualquier nuevo proyecto se te queda el entorno colgado y no hay manera.


Lo peor es que no hay manera de deshacerse de este problema (o yo al menos no la he encontrado). El instalador de contenidos de Visual Studio no tiene opción alguna para desinstalar (ya les vale), y he probado también a resetear los ajustes todos, borrar la caché de plantillas, borrar los archivos del Starter Kit, etc… Nada que hacer… En Google (luz de occidente) no aparece nada sobre el tema.


El caso es que en los foros de DNN hay gente a la que le pasa lo mismo y nadie les ha dado aún una solución.


Tenía que habérmelo imaginado y no haber instalado esta cosa en mi equipo. La versión que yo conocía a fondo de este programa es de hace ya años (las primeras versiones para .NET 1.0) y la verdad es que era un código nefasto en el que me tiré trabajando un verano entero retocándolo para que funcionara medianamente bien. Imaginé que yendo por la versión 4 y con VS2005 la cosa estaría mucho mejor, pero no me ha dado tiempo a comrpobarlo siquiera porque se ha cargado mi entorno de desarrollo :-(((


Si alguien sabe como librarse de esta m13r$a, por favor, que me mande un correo (acuérdate de quitar el ‘quitaesto’ delante de la arroba) o me deje un comentario aquí. Y desde luego si apreciais vuestro sistema no instaleis esta cosa, al menos en su versión Starter Kit. ¡Ah! y si alguien conoce algún proyecto Open Source de gestor de contenido extensible con módulos que sea medianamente decente también le agradeceré el comentario (no me vale Axinom, ni Rainbow…. La verdad es que en este ámbito PHP o Java nos comen muchísimo terreno a los de .NET, una pena).


Espero que esta advertencia le evite un disgusto a alguno 🙁


ACTUALIZACIÓN 19-6-2006:


¡Por fin he recuperado mi Visual Studio 2005!
Pero me ha costado sangre sudor y lágrimas porque ni siquiera reinstalando o desinstalando todo y volviendo a instalar arreglas el asunto.
La solución ha sido borrar todo rastro de Visual Studio 2005 y productos relacionados del equipo, pero para eso no llega con desinstalar. Yo usé las instrucciones que da Aaron Stebner, de Microsoft. Un rollo total. No sé como no mejoran esto de una vez y por favor a ver si los chicos de Microsoft sacan una herramienta para desinstalar Starter Kits que clama al cielo 🙁

XHTML (II) – Cómo usarlo desde ASP.NET 2.0

En mi anterior post sobre XHTML presentaba este estándar y cómo afectaba a nuestras aplicaciones HTML de toda la vida. Ahora vamos a ver cómo conseguir que nuestras aplicaciones ASP.NET 2.0 cumplan con este estándar.


Por defecto ASP.NET 2.0 genera XHTML 1.0 Transtional, en el que la mayor parte del HTML generado para los controles Web cumple con XHTML 1.1 pero que tiene ciertas características que hacen que no lo cumpla.


Existe una sencilla forma de configurar el entorno de ejecución para generar otros tipos de marcado más o menos compatibles (esto último puede ser interesante para migrar aplicaciones antiguas en ASP.NET 1.x).


Lo único que hay que hacer es configurar un nodo de tipo xhtmlConformance en nuestro web.config, así:



<system.web>
    <xhtmlConformance
        mode=»strict» />
</system.web>


para conseguir marcado XHTML Strict, o bien:



<system.web>
    <xhtmlConformance
        mode=»legacy» />
</system.web>


para que el HTML generado sea compatible con las versiones anteriores aunque no se comporte como marca XHTML. Si no incluimos este elemento se generará XHTML Transtional.


El modo Legacy


¿Qué deferencias con XHTML tiene el código generado en modo Legacy?. Pues según la documentación de Microsoft son las siguientes:




  • Los formularios incluyen el atributo name, explícitamente prohibido en XHTML, como hemos visto.


  • No se incluye un elemento <div> a continuación el elemento <form> para contener a todos los elementos y controles, cosa que sí ocurre en el modo normal.


  • Los controles de validación se renderizan como elementos <span> con atributos especiales.


  • Los elementos de imagen (<img>) no incluyen atributos ‘alt’ a menos que los incluyamos nosotros.


  • Se incluye el atributo ‘language’ en los elementos que tienen habilitado el Auto-post-back.


  • Se usa el atributo ‘nowrap’ en los elementos <div> cuya propiedad ‘Wrap’ sea ‘false’.


  • Los botones ImageButton incluyen un atributo ‘border’.


  • Los cambios de línea <br> no incluyen el cierre.

Excepciones


Incluso aunque utilicemos el modo ‘strict’ para conseguir XHTML 1.0 Strict hay excepciones en las que no seremos capaces de conseguir realmente una compatibilidad total.


Obviamente los controles que no sean nativos de ASP.NET 2.0 (es decir, que hayamos comprado a otras empresas) es probable que su HTML generado no cumpla con el estándar. Habrá que preguntarle al fabricante si ello es importante para nosotros.


Por otra parte todo el HTML estático que creemos nosotros y que no proceda de un control de servidor, así como los elementos que incluyamos dentro de controles de servidor Literal (pensados para mostrar su contenido inalterado), no se modifican en modo alguno. Por ello es necesario que tengamos cuidado por nuestra cuenta sobre lo que metemos en ellos, para que cumpla con el estándar deseado.


Una excepción más chocante es que algunos controles del propio ASP.NET no cumplen con XHTML aunque lo forcemos con el ajuste mencionado. Por ejemplo, algunos controles permiten ajustar una propiedad de su comportamiento que hace que se generen atributos ‘target’ en el HTML resultante, no cumpliendo entonces con XHTML. El más obvio de éstos es el control HyperLink, para crear enlaces, pero hay otros: HyperLinkColumn, AdRotator, MenuItem, TreeNode, ImageMap y BulletedList.


Los controles que generan una lista HTML (como por ejemplo el ListBox o el DropDownList), si no contienen elementos no generarán elementos <option> hijos, por lo que tampoco validarán contra XHTML 1.1.

El estándar XHTML (I) – Qué debemos saber los desarrolladores Web

XHTMLHace poco un alumno de mi curso de ASP.NET 2.0 de campusMVP me preguntaba por el estándar XHTML 1.0 Strict y cómo conseguir que ASP.NET fuera capaz de generar páginas compatibles con él. Retomo ahora el tema para publicar unas cuantas cosas sobre él en el Blog, ya que en algunos tipos de apliaciones (por ejemplo, si trabajamos para un organismo público) puede ser importante.


Primeramente veremos qué es XHTML y qué niveles tiene. En sucesivos post explicaré cómo sacarle partido en ASP.NET 2.0 y cómo nos podemos «columpiar» fácilmente con esto a menos que tengamos un cuidado extremo. Espero que os parezca interesante.


¿Qué es XHTML?


El estándar XHTML está definido por la W3C (World Wide Web Consortium) y define las páginas HTML como si se tratara de documentos XML bien formados. Esta es su principal ventaja ya que pueden ser tratadas y procesadas por un analizador XML cualquiera sin problemas, lo cual las convierte en algo mucho más fácil de usar y transformar por máquinas. Además, las páginas XHTML tienen otras ventajas como que son más fáciles de adaptar a estándares de accesibilidad, nos garantiza que no hemos metido la pata en la definición de la página (olvidándonos de cerrar un elemento, por ejemplo) y, sobre todo, nos aseguramos que serán bien interpretadas por casi cualquier navegador moderno a medida que todos ellos implementan el estándar.


Aunque el estándar XHTML es uno sólo, en realidad se definen varios niveles de cumplimiento del mismo, siendo más o menos estrictos en cada caso respecto a los requerimientos del código generado. Existen:




  • XHTML 1.0 Transitional


  • XHTML 1.0 Frameset


  • XHTML 1.0 Strict


  • XHTML 1.1

Incluso hay ya una nueva especificación XHTML 2.0 que está en borrador desde hace casi un año, pero de momento no debe preocuparnos.


El más estricto en cuanto a condiciones del código es el último de ellos, XHTML 1.1, aunque por su nombre pudiera parecer que iba a ser el anterior. Los dos primeros permiten bastante flexibilidad y además soportan sintaxis antiguas de HTML como veremos luego.


¿En qué consiste la sintaxis XHTML?


Bueno, en realidad define un montón de reglas especiales, pero nos podemos hacer una idea muy buena si pensamos en lo dicho antes y consideramos un documento HTML como si fuera XML puro y duro. De ello deducimos fácilmente algunas reglas:




  • Todas las etiquetas que se abren deben tener su correspondiente cierre. Es decir, se acabó usar sólo un <image> o un <br>, ahora hay que cerrarlos: <image />, <br />


  • Todos los elementos deben estar incluidos dentro de algún otro elemento. Es decir, no puede haber etiquetas «colgando» que no estén contenidas en ninguna otra. Al fin y al cabo se trata de una jerarquía XML.


  • Las etiquetas de apertura y cierre deben ser exactamente iguales, incluso en el uso de mayúsculas y minúsculas.


  • El código de Script se debe incluir dentro comentarios XML.

Además de estas hay otras reglas menos obvias pero que, sin embargo, parecen razonables siguiendo la filosofía XML:




  • Dado que en XML la diferencia entre minúsculas y mayúsculas es tenida en cuenta, los atributos de las etiquetas deberán escribirse todos igual. En este caso implica que todos ellos deben ser definidos en letras minúsculas.


  • Todos los valores de los atributos deben estar incluidos entre comillas dobles. Nada de comillas simples o directamente sin comillas.


  • Existen unas reglas de como nombrar a los elementos. Éstos se identifican opcionalmente con un atributo ‘id’ que debe segir estas reglas (que se parecen a las de cualquier lenguaje de programación tradicional: letras y números, no comenzar por un número, no usar espacios, etc…)


  • Codificación de caracteres: todos los caracteres no ASCII se codifican siguiendo la sintaxis HTML que comienza con un operador ‘et’ (&).

Aparte de estas reglas hay un montón de ellas más que, a mi parecer, son bastante aleatorias y dificultan el trabajo bastante, aunque algunas de ellas tienen cierta lógica:




  • No se puede especificar información de formato como nodos XHTML. Es decir, no podemos especificar un tipo de letra, tamaño, negrita, etc… usando etiquetas <FONT> o <B>. La forma de hacerlo es obligatoriamente medienta atributos ‘style’ y clases de hojas de estilo en cascada (CSS). La lógica detrás de esto imagino que es que el XML de la página XHTML incluya sólo información sobre el contenido, dejando el formato como atributos. O sea, que no haya elementos en el XML que no sean contenido puro y duro. Repito: tiene cierta lógica pero me parece ir en contra del espíritu del HTML original que buscaba justo lo contrario. De hecho ni siquiera se admiten atributos de formato como podría ser bgcolor y similares. En fin…


  • Los formularios no pueden contener un atributo ‘name’ como toda la vida para identificarlos. En XHTML 1.0 Transational se admite (pero no se aconseja), pero en XHTML 1.1 ya no está permitido. Nuevamente esto sigue cierta lógica ya que existe el atributo ‘id’ genérico para identificar cualquier elemento de una página y localizarla con getElementById en JavaScript, pero ¿no os parece un poco radical?. A mi sí.


  • El código de Script que incluyamos debe llevar el atributo type=»text/javaScript» aplicado y además no puede llevar el atributo ‘language’. Me deja alucinado. Ya sé que a estas alturas de la película es un poco de bicho raro querer usar VBScript o cosas más esotéricas en páginas Web, pero ¿por qué sólo JavaScript?. Bueno, pues porque es lo único que entienden todos los navegadores. A mi me viene estupendamente pues tengo un libro de JavaScript que se vende como los churros y con esto mucho mejor ¿no?, pero hombre…


  • Esta es la que más me «gusta»: no se puede usar el atributo ‘target’ en ningún elemento. ¿Por qué? Pues por lo visto porque el XML del documento no debería expresar intenciones sobre el contenido, sólo contenido. A mi me parece una chorrada en este caso concreto y creo que el engorro que entraña sustituir este tipo de atributo no merece la pena por un motivo como este.
    Debido a esto algo tan sencillo y directo como este enlace:

    <a href=»http://www.jasoft.org» target=_blank>JASoft.org</a>

    Se convierte en el siguiente engorro:

    <a href=»http://www.jasoft.org»
           onclick=»window.open(this.href); return false;»
           onkeypress=»window.open(this.href); return false;»>JASoft.org</a>


    ¡Buff! Yo no le veo la ventaja, la verdad.
    Además debido a esto (y como veremos en otro post) los controles de servidor como HyperLink, LinkButton, Treeview, Calendar o los controles de validación, directamente no son compatibles con XHTML 1.1.

El que quiera estudiar a fondo el estándar puede hacerlo desde la página correspondiente del W3C.


En el siguiente post voy a explicar cómo se relaciona ASP.NET con XHTML, y como podemos conseguir compatibilidad (o al menos cierta compatibilidad) con este estándar desde nuestras aplicaciones Web.