Al igual que sucedía con la parte de la lógica, la presentación también estará dividida en dos proyectos, por un lado el API y por otro la implementación.

• org.gvsig.visor.swing.api
• org.gvsig.visor.swing.impl

De forma similar a como sucedía con la lógica en la presentación, en el proyecto del API sólo tenemos los interfaces y clases abstractas que definen nuestro API. El API de la parte de presentación está formado por el interface del manager junto con una serie de clases abstractas que definen el API público de nuestros componentes, generalmente componentes que extenderán al componente de swing JPanel. Son clases abstractas y no interfaces debido a que swing no presenta un modelo de interfaces para sus componentes. En nuestro ejemplo, el único componente que tendremos es el componente visual asociado a una manzana, el JVisorBlockPanel,que extiende de JPanel añadiéndole a nivel de API un único método que nos permita obtener el componente lógico VisorBlock que tiene asociado en un momento dado.

En la parte de implementación nos encontraremos con la clase DefaultJVisorBlockPanel que recibe en su constructor la instancia de VisorBlock de la que debe presentar sus datos. En general la parte de presentación no tiene una complicación mas allá de la propia que pueda tener el manejo de swing. Lo único a resaltar es que la parte de presentación no debería usar nada que no este expuesto en el API de nuestra librería de lógica.