Lycka Bonita

Quién dice que esta profesión es un campo de nabos ?

Como mola trabajar aquí

AdBlock Plus es un complemento de Mozilla Firefox que bloquea los banners e imágenes de publicidad, para que al navegar por internet no se nos abrasen los ojos de lucecitas parpadeantes y gillichorradas. Funciona como si fuera un firewall de imágenes: defines listas negras de imágenes que no se mostrarán, y listas blancas de páginas web donde no actuará este complemento.

Es fácil de configurar y utilizar. Puedes suscribirte a una lista de imágenes bloqueadas, con la ventaja de que se actualiza automáticamente; o puedes bloquear manualmente las imágenes que quieras, simplemente botón derecho encima y "Bloquear imagen"; incluso puedes utilizar comodines (como el asterísco) para bloquear URLs a mano.

Descarga

• AdBlock Plus en Complementos Firefox.

Más info en 

• Adblock Plus en Difunde Firefox.

Sabemos de las bondades de la modularización: facilitar el trabajo en equipo y la reutilización de las partes para otros proyectos. Ya hemos visto que es posible fragmentar (dividirlos en módulos) otros ficheros que utilizamos en las aplicaciones web que se tornan también monstruosos, Fragmentar Ficheros de Configuración de Frameworks. Y también es posible fragmentar los archivos que contienen los mensajes de nuestra aplicación.

Para ello debemos de declarar las partes en nuestro struts-config.xml:

<message-resources

  parameter="es/lycka/pruebas/propiedades/MessageResources"/>

<message-resources

  parameter="es.lyck.pruebas.propiedades.ErroresResources"

  key="errores">

</message-resources>

<message-resources

  parameter="es.lyck.pruebas.propiedades.TitulosResources"

  key="titulos">

</message-resources>

No existe limitación en el número de recursos a utilizar, pero estos recursos NO se recombinan en un único recurso: simplemente se organizan en grupos o categorías de mensajes definidos por la propiedad key de las anteriores declaraciones. Típicamente se organizan estas categorías o bien por tipo de mensajes (errores, cabeceras, nombres de campo, mensajes de información…) o bien por áreas de trabajo para facilitar el trabajo en equipo (login, clientes, productos, compras, ventas…).

La manera de invocarlos dentro de nuestras JSPs sería:

<bean:message bundle="labels" key="label.url"/>

Si la aplicación web está dividida en módulos ([Struts] - Aplicaciones modulares), cada módulo utiliza sus propios ficheros de mensajes, con lo cual en dos módulos diferentes pueden existir dos mensajes con las mismas claves (internamente se identifican por el nombre del módulo a modo de prefijo y la clave del mensaje).

Como decía arriba, los distintos ficheros de mensajes NO se recombinan en un único recurso; por tanto, no podemos tener un fichero de mensajes comunes a una organización, y otro particular para cada aplicación que se recombinen en uno único. Se os ocurre alguna solución para esto ? que no sea el copia y pega del fichero común en cada fichero particular, y no implique reescribir Struts

Technorati Tags: J2EE, Struts

El éxito de Java sobre los cientos de lenguajes de programación existentes se debe a que fue el primero en promover y apoyar dos principios básicos: modularización y reutilización. Yo creo que todos conocemos y utilizamos estos principios. 

Para aplicarlos al nivel de una aplicación web, Struts desde su versión 1.1 nos permite sudividir nuestra aplicación en subaplicaciones (módulos) para facilitar el trabajo simultáneo de diferentes equipos sobre la misma aplicación y facilitar la reutilización de módulos enteros (como un login común, administración, consulta de datos comunes…).

Para ello en la configuración del ActionServlet en el fichero web.xml introducimos algo similar a :

<!– Action Servlet Configuration –>

<servlet>

  <servlet-name>action</servlet-name>

  <servlet-class>org.apache.struts.action.ActionServlet</servlet-class>

  <init-param>

    <param-name>config</param-name>

    <param-value>/WEB-INF/struts-config.xml</param-value>

  </init-param>

  <init-param>

    <param-name>config/login</param-name>

    <param-value>/WEB-INF/struts-config-login.xml</param-value>

  </init-param>

  <init-param>

    <param-name>config/consultasComunes</param-name>

    <param-value>/WEB-INF/struts-config-consultasComunes.xml</param-value>

  </init-param>

  <load-on-startup>1</load-on-startup>

</servlet>

Esta declaración nos define

• un módulo llamado login, que está definido por el fichero /WEB-INF/struts-config-login.xml; la URL necesaria para acceder vía web a este módulo será http://servidor:puerto/nombre_aplicación/login.
• otro módulo llamado consultasComunes, definido por el fichero /WEB-INF/struts-config-consultasComunes.xml; la URL necesaria para acceder vía web a este módulo será http://servidor:puerto/nombre_aplicación/consultasComunes.
• y un último módulo, tomado por defecto y sin nombre declarado en primer lugar y definido por el fichero /WEB-INF/struts-config.xml ;la URL necesaria para acceder vía web a este módulo será la normal, http://servidor:puerto/nombre_aplicación.

Por defecto, Struts antepone el prefijo del módulo a las URL declaradas en cada fichero de configuración de cada módulo. Es decir, si en nuestro módulo de login tenemos una acción llamada "/nuevoUsuario" que apunta a una JSP llamada "nuevoUsuario.jsp", Struts automáticamente buscará en las URLs http://servidor:puerto/nombre_aplicación/login/nuevoUsuario.do y http://servidor:puerto/nombre_aplicación/login/nuevoUsuario.jsp respectivamente.

Ocurre lo mismo para las etiquetas como html:link o html:img, por lo que

• para enlaces entre distintos módulos en la versión 1.1 habrá que utilizar un action especial (SwitchAction); a partir de 1.2 soporta también el nombre del módulo (atributo module).
• habrá que separar las imágenes por módulos.

A pesar de que tiene compatibilidad con Struts 1.0, 1.1, 1.2 y posteriores, por bugs en las etiquetas se recomienda utilizar módulos únicamente en las versiones 1.2 y posteriores.

Technorati Tags: J2EE, Struts, modular

En algunas aplicaciones permitimos la subida de archivos de los usuarios al servidor. En algunas aplicaciones existe una limitación en el tamaño de los ficheros por requisitos del sistema o de negocio. Pero siempre debería de estar limitado por razones de seguridad, para evitar que un usuario malintencionado ataque la aplicación subiendo archivos excesivamente pesados. Por defecto, el tamaño máximo está limitado a 250 Megabytes.

Existe una forma muy simple de lograrlo, y es mediante una propiedad del controlador en el struts-config.xml, maxFileSize.

<controller>

<set-property property="maxFileSize" value="1M" />

</controller>

o simplemente

<controller maxFileSize="1M"/>

Esta propiedad admite un valor entero seguido de "K", "M" ó "G" para referirse a kilobytes, megabytes o gigabytes. Sin ningún sufijo se interpreta como bytes. En los dos ejemplos permitimos un máximo de 1 Mega(byte).

Si un usuario intenta subir un fichero de un tamaño mayor al permitido, la propiedad FormFile del formulario (clase ActionForm) llegará a la clase Action como null, y por tanto podemos controlar este evento en nuestra clase Action para lanzar una excepción para avisar al usuario de que su fichero no ha sido subido por sobrepasar el tamaño máximo permitido.

Memoria del servidor utilizada

Por defecto, la memoria que dedicará el servidor a la subida del fichero será 500 Kilobytes. En caso de superar este valor se utilizará otro soporte externo, típicamente el sistema físico de ficheros. Podemos modificar este valor de forma análoga, utilizando la propiedad memFileSize.

<controller maxFileSize="1M" memFileSize="300K"/>

Technorati Tags: J2EE, Struts, fileupload, seguridad