Supongamos que queremos crear una página web llamada articulos.htm que contiene un botón de formulario que al ser pulsado nos va a mostrar, en otra pantalla, una lista de artículos de ferretería procedente de una tabla. Por ejemplo:
<HTML> <HEAD><TITLE>Ferreteria </TITLE></HEAD> <BODY> <CENTER> <H3>La ferreteria virtual</H3> <FORM ACTION="/aplicaciones/articulos.idc" METHOD="POST"> <INPUT TYPE="SUBMIT" VALUE="Pulse aqui para ver nuestros articulos"> </FORM> </CENTER> </BODY> </HTML>
Paso 1.- Comenzaremos creando un origen de datos llamado pruebas que accede a una base de datos cualquiera (pero de Access o SQL Server), que contenga una tabla llamada articulos. Esta tabla tiene cuatro campos: codigo de tipo numérico, tipo de tipo texto, nombre de tipo texto, y precio de tipo numérico. Algo así:
codigo tipo nombre precio -------------------------------------------------- 1 HERRAMIENTAS Martillo 120 2 HERRAMIENTAS Alicates 140 3 MATERIAL Clavos 2 4 MATERIAL Tornillos 3
Paso 2.- A continuación hay que escribir el fichero articulos.idc que sería así:
Datasource: pruebas Username: web Password: Translationfile: C:\aplicaciones\translator.txt Template: articulos.htx SQLStatement: +SELECT tipo, nombre + FROM articulosAnalicemos cada línea:
La primera de ellas es Datasource: Es decir, origen de datos, recuerda que el origen de datos es creado por el administrador de ODBC, y el valor de este parámetro tiene que ser un origen de datos ODBC, no un nombre de base de datos.
A continuación vienen Username: y Password: en los que tendremos que escribir el usuario y palabra de paso que se hayan definido durante la creación del origen de datos.
El siguiente es Translationfile: y su valor en nuestro ejemplo es: C:\aplicaciones\translator.txt
Este valor no es más que la dirección física en un disco del servidor de un simple fichero de texto llamado translator.txt (o como quieras llamarle) cuyo contenido sirve para convertir caracteres que no se ven bien en pantalla, como eñes o acentuaciones a su valor correcto. Es parecido a lo que se puede definir en la creación del origen de datos, pero como en el ODBC sólo esta prevista la conversión OEM a ANSI o ANSI a OEM, que son las más habituales, si en las tablas hay algun caracter que no es de ninguno de estos dos juegos, desde el Translationfile: podemos hacer que se vea correctamente. Es recomendable mantener este parámetro, incluso aunque no se utilice. Si se mantiene, el fichero translator.txt debe existir, aunque puede estar vacío. He aquí una muestra:
Después tenemos Template: Aquí es donde se indica el nombre del fichero plantilla que presentará los datos finales, y que habitualmente tiene el mismo nombre que el fichero .idc que le invoca, aunque puede tener cualquier otro, siempre que se mantenga su extensión: .htx En nuestro ejemplo es el llamado articulos.htx
Y por fin tenemos la estrella de todo este invento: SQLStatement: Esta es la instrucción o instrucciones escritas en SQL para la base de datos. Todo lo hecho hasta ahora es para conseguir extraer o guardar un dato en la DB, y es en este punto donde muchas aplicaciones naufragan lamentablemente.
SQL no es un lenguaje trivial. Además de su sintaxis, que puede variar sensiblemente de una DB a otra, se deben tener nociones del funcionamiento interno de la DB, conocer sus prestaciones máximas y mínimas, y sobre todo se debe tener clara la estructura de las tablas tanto a la hora de crear la DB como a la hora de explotarla. Es buena idea dedicar algun tiempo a estudiar el SQL en general y el de nuestra DB en particular. Si tienes que utilizar una DB que no has creado tú, nunca dejes de hablar con su creador. Infórmate de su estructura, lo que se pretendía de ella cuando fue creada, qué campos estan indexados, cual es su juego de caracteres por defecto, si existen relaciones definidas entre tablas, si hay integridad referencial, y en fin, cualquier detalle que te pueda ayudar a la hora de diseñar la aplicación y optimizar las consultas SQL.
Recuerda que si una determinada consulta hecha directamente a la DB es lenta en su respuesta, via internet lo será mucho más. Cualquier defecto de estructura o de programación que en local no tendrían demasiadas consecuencias, en internet pueden ser desastrosos, llegando incluso a "colgar" la base de datos. Tener siempre presente esta jocosa ecuación:
Donde, si problemilla tiende a cero, la cosa mejora. Los tres siguientes factores de la ecuación son irresolubles y sólo cabe aceptarlos con resignación.
Y continuando con nuestro idc, concretamente con la SQLStatement, en este caso se trata de una simplísima instrucción: SELECT tipo, nombre FROM articulos en la que se solicita a la DB que nos devuelva solamente los campos tipo y nombre de la tabla articulos, sin ninguna limitación ni condición. El signo + que hay delante de las cláusulas SELECT y FROM es la forma que tiene el IDC de concatenar cadenas de texto, por lo que no hay que olvidar poner un espacio en blanco delante de la primera cosa que se escriba en la segunda y siguientes líneas de la sentencia SQL y después del correspondiente signo +.
Paso 3.- El tercer y último paso consistirá en escribir el fichero articulos.htx donde daremos formato a los datos que nos devuelva la consulta SQL. Podría ser algo así:
<HTML>
<HEAD><TITLE>Lista de articulos </TITLE></HEAD>
<BODY>
<CENTER>
<H3>La ferreteria virtual</H3>
<TABLE BORDER=1>
<TR><TH>Tipo articulo</TH><TH>Nombre articulo</TH></TR>
<%begindetail%>
<TR>
<TD><%tipo%></TD>
<TD><%nombre%></TD>
</TR>
<%enddetail%>
</TABLE>
</CENTER>
</BODY>
</HTML>
Y este sería el resultado obtenido, si todo funciona como debe (y en la tabla hemos escrito esto, claro...):
| Tipo articulo | Nombre articulo |
|---|---|
| HERRAMIENTAS | Martillo |
| HERRAMIENTAS | Alicates |
| MATERIAL | Clavos |
| MATERIAL | Tornillos |
Paso 3 bis.- Aquí haremos una segunda versión del fichero .htx para que puedas ver como se utiliza el comando de decisión del IDC: if. Como ejemplo haremos que los artículos del tipo "MATERIAL" se escriban en rojo y el resto en azul:
<HTML>
<HEAD><TITLE>Lista de articulos coloreada</TITLE></HEAD>
<BODY>
<CENTER>
<H3>La ferreteria virtual</H3>
<TABLE BORDER=1>
<TR><TH>Tipo articulo</TH><TH>Nombre articulo</TH></TR>
<%begindetail%>
<TR>
<TD><%tipo%></TD>
<TD><%if tipo EQ "MATERIAL"%>
<FONT COLOR="red"><%nombre%></FONT>
<%else%>
<FONT COLOR="blue"><%nombre%></FONT>
<%endif%>
</TD>
</TR>
<%enddetail%>
</TABLE>
</CENTER>
</BODY>
</HTML>
Y este debe ser el resultado obtenido:
| Tipo articulo | Nombre articulo |
|---|---|
| HERRAMIENTAS | Martillo |
| HERRAMIENTAS | Alicates |
| MATERIAL | Clavos |
| MATERIAL | Tornillos |
Verás que en la condición <%if tipo EQ "MATERIAL"%> el valor de tipo, "MATERIAL" va entre comillas dobles. Esto es así porque el campo tipo es alfanumérico, y se hace la comparación como cadena de caracteres. Si fuera numérico no debería llevar comillas y la comparación sería numérica. En los ficheros .htx los campos de texto van entre comillas dobles como ya has visto, pero en los ficheros .idc tienen que ir entre comillas simples ( ' ) OJO: no es un acento, es un apóstrofe.
En el ejemplo hemos utilizado la condición if para cambiar el color de un texto, pero puede utilizarse para cualquier cosa que se te ocurra. En combinación con el HTML sabiamente utilizado, se pueden conseguir aplicaciones muy potentes, aunque no debes forzar demasiado los .htx, la verdadera potencia del IDC está en el SQL. Y hablando de SQL, no olvidar que en los .idc se puede escribir más de una sentencia SQL siempre que la DB sea de SQL Server, si es de Access sólo se puede escribir una sentencia cada vez, como en este ejemplo.
Si tienes un SQL Server puedes escribir varias sentencias SQL en el IDC, y el HTX se escribe igual, solo que poniendo una pareja de instrucciones <%begindetail%> <%enddetail%> en el momento de utilizar el resultado devuelto por cada sentencia SQL, y teniendo en cuenta que han de ser secuenciales, es decir, que hay que utilizarlas en el mismo orden en que fueron escritas en el IDC. No es posible anidarlas, ya que no tienen nombre.
Otra cosa que se puede hacer si tienes un SQL Server, es arrastrar o crear valores durante varios ficheros .idc incluso aunque lo que se quiera arrastrar no exista realmente en ninguna tabla de la DB. Por ejemplo si en el primer .idc escribimos una consulta como esta:
+SELECT 'Hola que tal' AS saludo
El valor del campo "saludo" estará disponible en un segundo .idc de esta forma:
+SELECT '%saludo%' AS saludo2
En este ejemplo se ha creado un string (cadena de texto) que no existe en ninguna tabla de la DB. También pueden arrastrarse valores obtenidos de una consulta real a una o varias tablas de la DB, sin necesidad de ejecutar la misma consulta dos .idc más allá. Y por supuesto, pueden generarse valores numéricos, cálculos, etc., utilizando las funciones de todo tipo que posee SQL Server. No olvidar que para acceder a los datos de cada sentencia SELECT, en los .htx siempre se necesitan parejas de instrucciones <%begindetail%> <%enddetail%>, una por cada SELECT escrita en los .idc