Tapestry vs Wicket - Second round

Según los autores de Tapestry and Wicket compared, una de las desventajas de Tapestry respecto a Wicket es la fuerte orientación al uso de XML en la declaración de componentes. Los autores usaron la manera ortodoxa de desarrollo de páginas y componentes en Tapestry. Desde la versión 3 de Tapestry, se puede reducir significativamente la declaración de componentes usando “componentes implícitos”.

Para ilustrar este concepto, reproduzco los listados 9 y 11 del artículo:

Tapestry vs Wicket

En DeveloperWorks se encuentra un artículo acerca de la comparación entre Tapestry y Wicket. El método de comparación es muy práctico ya que describen como solucionan ambos frameworks las típicas tareas de desarrollo de una aplicación web. Desafortunadamente los autores utilizaron la versión anterior de Tapestry, la 4.1, para la comparación, no obstante el artículo es una lectura altamente recomendable para tener una idea de como funcionan los frameworks de web orientados a componentes.

Death March

Dead march es un disfemismo para referirse a proyectos que están destinados a fracasar, es decir para proyectos que tienen serias restricciones en tiempo, personal y/o presupuesto. ¿Quién no ha participado en un proyecto de este tipo?

De acuerdo a Scott Adams, el autor de la famosa tira cómica Dilbert:

When I first started hearing these stories [about irrational corporate behavior] I was puzzled, but after careful analysis I have developed a sophisticated theory to explain the existence of this bizarre workplace behavior. People are idiots.
Including me. Everyone is an idiot, not just the people with low SAT scores. The only difference among us is that we’re idiots about different things at different times. No matter how smart you are, you spend much of your day being an idiot

Suena aterrador, proyectos plagados de idiotas.

Tipos de Vistas

Una vista es una representación de uno o más aspectos estructurales que ilustra como la arquitectura se ocupa de uno o más de los intereses de los stakeholders.

La idea no es nueva, sin embargo fue hasta 1995 cuando Phillipe Krutchen la hizo popular en su famoso manifiesto: Architectural Blueprints—The “4+1” View Model of Software Architecture.
A partir de ahí, todas las metodologías modernas para la elaboración de arquitecturas de software utilizan vistas.

El objetivo de un tipo de vista es proporcionar una librería de plantillas y patrones que puedan ser usados como la guía para la creación de vistas, ya que no sería práctico que cada vez que se definiera una vista se tuviera que especificar el tipo de contenido, guías, principios y modelos para su elaboración.

Un catálogo de los tipos de vistas puede ser el siguiente: