Mostrando entradas con la etiqueta Java. Mostrar todas las entradas
Mostrando entradas con la etiqueta Java. Mostrar todas las entradas
jueves, 13 de marzo de 2008
Esta directiva nos permite incluir ficheros en el momento en que la página JSP es traducida a un servlet. La directiva se parece a esto:
<%@ include file="cabecera.html" %>La URL especificada normalmente se interpreta como relativa a la página JSP a la que se refiere, pero, al igual que las URLs relativas en general, podemos decirle al sistema que interpreta la URL relativa al directorio home del servidor Web empezando la URL con una barra invertida. Los contenidos del fichero incluido son analizados como texto normal JSP, y así pueden incluir HTML estático, elementos de script, directivas y acciones. Por ejemplo, muchas sites incluyen una pequeña barra de navegación en cada página. Debido a los problemas con los marcos HTML, esto normalmente se implementa mediante una pequeña tabla que cruza la parte superior de la página o el lado izquierdo, con el HTML repetido para cada página de la site. La directiva include es una forma natural de hacer esto, ahorrando a los desarroladores el mantenimiento engorroso de copiar realmente el HTML en cada fichero separado. Aquí tenemos un código representativo:
<HTML> <HEAD> <TITLE>Ejemplo del uso de la directiva include en JSP</TITLE> </HEAD> <BODY> <%@ include file="/navbar.html" %> <!-- Contenido de la página --> </BODY> </HTML>Es importante tener presente que como la directiva include inserta los ficheros en el momento en que la página es traducida, si la página incluida cambia, necesitamos re-traducir todas las páginas JSP que la refieren. Esto es un buen compromiso en una situación como esta, ya que esto generalmente se utiliza en las páginas de un sitio que no cambian frecuentemente, y queremos que el proceso de inclusión sea tan eficiente como sea posible. Si los ficheros incluidos cambian de forma más frecuente, podríamos usar la acción jsp:include en su lugar. Esto incluye el fichero en el momento en que se solicita la página JSP. Continuar leyendo
miércoles, 12 de marzo de 2008
Indica al contenedor JSP que la página va a utilizar "tag libraries" o librerías de etiquetas. Estas librerías contienen etiquetas creadas por el propio programador con sus correspondientes atributos que encapsulan determinada funcionalidad. Lo habitual es utilizar librerías públicas que han diseñado otros programadores y han sido profundamente probadas. La sintaxis de esta directiva tiene dos atributos. El contenido del atributo uri permite localizar el fichero descriptor de la librería de extensión tld. El atributo prefix especifica el identificador que todas las etiquetas de la librería deben incorporar. Es una directiva muy interesante que facilita y complementa la programación habitual de las páginas JSP. Las taglibs son simplemente un cambio de interfaz con respecto al código Java normal; te ahorran insertar código dentro de las páginas, y son, en general, más fáciles de mantener, porque, en el más puro estilo OO, encapsulan su lógica y el que las usa no tiene que preocuparse por cómo hacen lo que hacen, sólo por acceder a ellas. Desarrollar sitios web utilizando etiquetas presenta ciertas ventajas como: • Facilitar el aprendizaje. • Facilitar el mantenimiento. • Fomentar la modularidad y la reutilización. • Simplificar el código y reducir el número de líneas necesarias. Su sintaxis es como se muestra en el ejemplo siguiente:
<%@ taglib uri="/taglib/lycka" prefix="lycka" %> <!-- ( ... ) --> <lycka:hola/> <!-- ( ... ) -->A la hora de generar el código Java de la Servlet, esta etiqueta hola será interpretada por el Servidor como perteneciente a la librería de etiquetas (Tag Library) lycka. Esta librería estará identificada en el fichero descriptor de nuestra aplicación (web.xml) con el nombre de recurso (URI) /taglib/lycka de la siguiente forma:
<taglib-uri>/taglib/lycka</taglib-uri> <taglib-location>/WEB-INF/tags/lycka.tld</taglib-location>Para profundizar sobre el tema de la directiva taglib le recomiendo este archivo PDF con una descripción más detallada y con algunos ejemplos prácticos. Continuar leyendo
martes, 11 de marzo de 2008
Esta directiva da instrucciones al motor que procesa las páginas JSP; estas instrucciones se aplican a todo el fichero fuente. Utilizando esta directiva se podría especificar un comentario informativo que formará parte del fichero JSP compilado, el lenguaje de script usado en el fichero fuente JSP, los paquetes de ficheros fuentes que serán importados, o la página de error que se llamará si ocurren errores o excepciones, entre otros aspectos. Podemos usar la directiva page en cualquier lugar del fichero JSP, pero es muy recomendable situarlo en la parte superior del fichero. Como es una etiqueta JSP, podemos situarla antes de la etiqueta de apertura <html>. Un ejemplo de uso de esta directiva es el siguiente:
<%@ page language='java' contentType="text/html" info='Mi primera página en JSP" import='java.util.*' errorPage='paginadeerror.jsp' %>A continuación detallamos todos los parámetros que se pueden definir utilizando la directiva page, con un ejemplo en cada caso.
Atributo |
Sintaxis |
Utilización |
import |
<%@ page import="java.utils.*" %> |
Importa clases y paquetes Java para ser utilizadas dentro del fichero JSP. |
session |
<%@ page session="false" %> |
Especifica si utiliza los datos contenidos en sesión; por defecto "true". |
contentType |
<%@ page contentType="class; class" %> |
Especifica el tipo MIME del objeto "response"; por defecto "text/html; charset=ISO-8859-1". |
buffer |
<%@ page buffer="12KB" %> |
Buffer utilizado por el objeto writer "out"; puede tomar el valor de "none"; por defecto "8KB". |
errorPage |
<%@ page errorPage="/error_page.jsp" %> |
Especifíca la ruta de la página de error que será invocada en caso de producirse una excepción durante la ejecución de este fichero JSP. |
isThreadSafe |
<%@ page isThreadSafe="false" %> |
Un valor de true (por defecto) indica un procesamiento del servlet normal, donde múltiples peticiones pueden procesarse simultáneamente con un sólo ejemplar del servlet, bajo la suposición que del autor sincroniza las variables de ejemplar. Un valor de false indica que el servlet debería implementar SingleThreadModel, con peticiones enviadas serialmente o con peticiones simultáneas siendo entregadas por ejemplares separados del servelt. |
autoflush |
<%@ page autoflush="true" %> |
Un valor de true (por defecto) indica que el buffer debería descargase cuando esté lleno. Un valor de false, raramente utilizado, indica que se debe lanzar una excepción cuando el buffer se sobrecargue. Un valor de false es ilegal cuando usamos buffer="none". |
extends |
<%@ page extends="package.class" %> |
Esto indica la superclase del servlet que se va a generar. Debemos usarla con extrema precaución, ya que el servidor podría utilizar una superclase personalizada. |
info |
<%@ page info="Mi página JSP" %> |
Define un string que puede usarse para ser recuperado mediante el método getServletInfo. |
language |
<%@ page language="java" %> |
En algunos momentos, esto está pensado para especificar el lenguaje a utilizar. Por ahora, no debemos preocuparnos por él ya que java es tanto el valor por defecto como la única opción legal. |
isErrorPage |
<%@ page isErrorPage="true" %> |
Determina si este fichero JSP es una página que maneja excepciones. Únicamente a este tipo de páginas pueden acceder a la variable implícita "exception", que contiene la excepción que provocó la llamada a la página de error. |
lunes, 10 de marzo de 2008
Las directivas en las Java Server Pages son órdenes que se ejecutan antes de que se comience a procesar el archivo JSP y modifican de alguna forma el resultado del mismo. Todas las directivas en JSP se indican con una arroba (@) después del comienzo de la orden JSP (<%). La sintaxis de una directiva es como se muestra en el ejemplo siguiente:
<%@ directiva atributo="valor" %>Es importante destacar que los atributos de estas directivas son sensibles a las mayúsculas. En los post siguientes abordaremos las características más importantes de las directivas page, taglib e inlude. Continuar leyendo
jueves, 6 de marzo de 2008
Un applet es un componente de una aplicación que se ejecuta en el contexto de otro programa, por ejemplo un navegador web. El applet debe ejecutarse en un contenedor, que lo proporciona un programa anfitrión, mediante un plugin, o en aplicaciones como teléfonos móviles que soportan el modelo de programación por applets. A diferencia de un programa, un applet no puede ejecutarse de manera independiente, ofrece información gráfica y a veces interactúa con el usuario, típicamente carece de sesión y tiene privilegios de seguridad restringidos. Un applet normalmente lleva a cabo una función muy específica que carece de uso independiente. Cuando un Navegador carga una página Web que contiene un Applet, este se descarga en el navegador Web y comienza a ejecutarse esto nos permite crear programas que cualquier usuario puede ejecutar con tan solo cargar la página Web en su navegador. Ejemplos comunes de applets son las Java applets y las animaciones Flash. Otro ejemplo es el Windows Media Player utilizado para desplegar archivos de video incrustados en los navegadores como el Internet Explorer. Otros plugins permiten mostrar modelos 3D que funcionan con un applet. Applet de Java Un Java applet es un código Java que carece de un método main, por eso se utiliza principalmente para el trabajo de páginas web, ya que es un subprograma o pequeño programa que es utilizado en una página HTML y representado por una pequeña pantalla gráfica dentro de ésta. Por otra parte, la diferencia entre una aplicación Java y un applet radica en cómo se ejecutan. Para cargar una aplicación Java se utiliza el intérprete de Java. En cambio, un applet se puede cargar y ejecutar desde cualquier explorador que soporte Java (Nescape, Internet Explorer de Windows, Mozilla Firefox, etc.). Entre sus características podemos mencionar un esquema de seguridad que permite que los applets que se ejecutan en el equipo no tengan acceso a partes sensibles, por ejemplo no pueden escribir archivos, a menos que uno mismo le dé los permisos necesarios en el sistema; la desventaja de este enfoque es que la entrega de permisos es engorrosa para el usuario común, lo cual juega en contra de uno de los objetivos de los Java applets: proporcionar una forma fácil de ejecutar aplicaciones desde el navegador web. Ventajas de los applet de Java • Funcionan en Linux, Windows y Mac OS, son multiplataforma • El mismo applet pueden trabajar en "todas" las versiones de Java, y no sólo la última versión del plug-in. Sin embargo, si un applet requiere una versión posterior de la JRE, el cliente se verá obligado a esperar durante la gran descarga. • Es soportado por la mayoría de los navegadores Web • Puede ser almacenado en la memoria cache de la mayoría de los navegadores Web, de modo que se cargará rápidamente cuando se vuelva a cargar la página Web, aunque puede quedar atascado en la caché, causando problemas cuando se liberan nuevas versiones. • Puede tener acceso completo a la máquina en la que se está ejecutando, si el usuario lo permite • Puede ejecutarse con velocidades comparables (pero en general más lento) a la de otros lenguajes compilados, como C + +, pero muchas veces más rápida que la de JavaScript • Puede trasladar el trabajo del servidor al cliente, haciendo una solución Web más escalable tomando en cuenta el número de usuarios / clientes Desventajas de los applet de Java • Requiere el plug-in de Java, que no está disponible por defecto en todos los navegadores web. • Sun no ha creado una implementación del plug-in para los procesadores de 64 bits • No puede iniciar la ejecución hasta que la Máquina virtual de Java está en funcionamiento, y esto puede tomar tiempo la primera vez que se ejecuta un applet. • Si no esta firmado como confiable, tiene un acceso limitado al sistema del usuario - en particular no tiene acceso directo al disco duro del cliente o al portapapeles. • Algunas organizaciones sólo permiten la instalación de software a los administradores. Como resultado, muchos usuarios (sin privilegios para instalar el plug-in en su navegador) no pueden ver los applets. • Un Applet podría exigir una versión específica del JRE. Cómo crear un applet de java Para crear un applet necesitamos escribir una clase que herede de la clase Applet del paquete java.applet.*;
import java.applet.*; public class MiApplet extends Applet { //Cuerpo del ''applet''. }El código anterior declara una nueva clase MiApplet que hereda todas las capacidades de la clase Applet de Java. El resultado es un fichero MiApplet.java. Una vez creada la clase que compone el applet, escribimos el resto del código y después lo compilamos, obteniendo el fichero MiApplet.class. Para poder crear el applet se necesita compilar el código Java en un intérprete.
import java.applet.*; import java.awt.*; import java.util.*; import java.text.DateFormat; public class MiApplet extends Applet implements Runnable { private Thread hilo = null; private Font fuente; private String horaActual = "00:00:00"; public void init() { fuente = new Font("Verdana", Font.BOLD, 24); } public void start() { if (hilo == null) { hilo = new Thread(this, "Reloj"); hilo.start(); } } public void run() { Thread hiloActual = Thread.currentThread(); while (hilo == hiloActual) { //obtener la hora actual Calendar cal = Calendar.getInstance(); Date hora = cal.getTime(); DateFormat df = DateFormat.getTimeInstance(); horaActual = df.format(hora); repaint(); try { Thread.sleep(1000); } catch (InterruptedException e){} } } public void paint(Graphics g) { //Dibujar un rectangulo alrededor del contenedor g.draw3DRect(1, 1, getSize().width-3, getSize().height-3, false); //Establecer la Fuente g.setFont(fuente); //mostrar la Hora g.drawString(horaActual,14,40); } public void stop() { hilo = null; } }Finalmente, para ejecutar el applet hay que crear una página Web que haga referencia al mismo. La etiqueta HTML que permite hacer eso es <applet>:
<html> <applet code="MiApplet.class" width="370" height="270"> </applet> </html>Los parámetros "MiApplet.class", "370" y "270" correspondientes a la ubicación del archivo que contiene la clase, el ancho y el alto del applet, se pueden modificar. Continuar leyendo
miércoles, 5 de marzo de 2008
Una Máquina virtual Java (en inglés Java Virtual Machine, JVM) es un programa nativo, es decir, ejecutable en una plataforma específica, capaz de interpretar y ejecutar instrucciones expresadas en un código binario especial (el Java bytecode), el cual es generado por el compilador del lenguaje Java.
El código binario de Java no es un lenguaje de alto nivel, sino un verdadero código máquina de bajo nivel, viable incluso como lenguaje de entrada para un microprocesador físico. Como todas las piezas del rompecabezas Java, fue desarrollado originalmente por Sun Microsystems.
La JVM es una de las piezas fundamentales de la plataforma Java. Básicamente se sitúa en un nivel superior al Hardware del sistema sobre el que se pretende ejecutar la aplicación, y este actúa como un puente que entiende tanto el bytecode, como el sistema sobre el que se pretende ejecutar. Así, cuando se escribe una aplicación Java, se hace pensando que será ejecutada en una máquina virtual Java en concreto, siendo ésta la que en última instancia convierte de código bytecode a código nativo del dispositivo final.
La gran ventaja de la máquina virtual java es aportar portabilidad al lenguaje de manera que desde Sun Microsystems se han creado diferentes máquinas virtuales java para diferentes arquitecturas y así un programa .class escrito en un Windows puede ser interpretado en un entorno Linux. Tan solo es necesario disponer de dicha máquina virtual para dichos entornos. De ahí el famoso axioma que sigue a Java, "escríbelo una vez, ejecútalo en cualquier parte", o "Write once, run anywhere".
La máquina virtual de Java puede estar implementada en software, hardware, una herramienta de desarrollo o un Web browser; lee y ejecuta código precompilado bytecode que es independiente de la plataforma multiplataforma. La JVM provee definiciones para un conjunto de instrucciones, un conjunto de registros, un formato para archivos de clases, la pila, un heap con recolector de basura y un área de memoria. Cualquier implementación de la JVM que sea aprobada por SUN debe ser capaz de ejecutar cualquier clase que cumpla con la especificación.
Existen varias versiones, en orden cronológico, de la máquina virtual de Java. En general la definición del Java bytecode no cambia significativamente entre versiones, y si lo hacen, los desarrolladores del lenguaje procuran que exista compatibilidad hacia atrás con los productos anteriores.
En un sentido amplio, la Máquina Virtual de Java actúa como un puente entre el resultado de la compilación (el bytecode) y el sistema sobre el que se ejecuta la aplicación. Para cada dispositivo debe haber una JVM específica, ya sea un teléfono móvil, un PC con Windows XP, o un microondas. En cualquier caso, cada máquina virtual conoce el conjunto de instrucciones de la plataforma destino, y traduce un código escrito en lenguaje Java (común para todas) al código nativo que es capaz de entender el Hardware de la plataforma.
Una arquitectura de maquina virtual permite un control granular fino sobre las acciones que el código puede hacer dentro de la máquina. Esto está diseñado para permitir ejecución segura de código no confiable desde fuentes remotas, un modelo usado muy famoso son las Java applets. Applets se ejecutan dentro de una VM incorporada en el navegador del usuario, ejecutando código descargado desde un servidor HTTP remoto. El código remoto se ejecuta en un entorno cerrado y altamente restringido, llamado también sandbox, el cual está diseñado para proteger al usuario de código erróneo o malicioso. Los Publicadores con recursos financieros suficientes pueden conseguir un certificado con el cual hacer applets con firma digital que las caractericen como seguras ("safe"), dándoles entonces permisos para salir de la sandbox y acceder al sistema de ficheros local y sistema de red, presumiblemente bajo el control del usuario.
Continuar leyendo
domingo, 2 de marzo de 2008
Un plugin o plug-in (en inglés "enchufar", también conocido como addin, add-in, addon o add-on) es una aplicación informática que interactúa con otra aplicación para aportarle una función o utilidad específica, generalmente muy específica, como por ejemplo servir como driver (controlador) en una aplicación, para hacer así funcionar un dispositivo en otro programa. Ésta aplicación adicional es ejecutada por la aplicación principal. Los plugins típicos tienen la función de reproducir determinados formatos de gráficos, reproducir datos multimedia, codificar/decodificar emails, filtrar imágenes de programas gráficos, etc.
Se utilizan como una forma de expandir programas de forma modular, de manera que se puedan añadir nuevas funcionalidades sin afectar a las ya existentes ni complicar el desarrollo del programa principal.
En los navegadores web esto se refleja al intentar abrir un archivo que no posee un plugin en el sistema, como los documentos en PDF o las animaciones en Flash, lo que generará un error y se entrega, generalmente, un enlace para conseguir el plugin que no existe en el navegador.
Algunos de los plugins más populares que se ejecutan en las aplicaciones web de lado del cliente son Adobe Flash Player, para ejecutar aplicaciones Flash dentro de las páginas; Adobe Shockwave Player para aplicaciones Shockwave y Java Virtual Machine para la ejecución de los Applet de Java.
Continuar leyendo
Suscribirse a:
Entradas (Atom)
