**Direct translation with Google Translator**

As happened with the logic, the presentation also will be divided into
two projects, on the one hand and on the other API implementation.

- org.gvsig.visor.swing.api

- org.gvsig.visor.swing.impl

Similar to as with the logic in the presentation, in the draft
We only have the API interfaces and abstract classes that define our API. the API
of the presenting part is formed by the interface along with *manager*
a set of abstract classes that define the public API of our components,
components usually extend to swing JPanel component. These classes are
interfaces and abstract because no swing model interfaces
for its components. In our example, the only component that is we
visual component associated with an apple, the *JVisorBlockPanel*, which extends from
*JPanel* API level by adding a single method that allows us to obtain the
*VisorBlock* logical component that is associated at any given time.

In the implementation we will find the class *DefaultJVisorBlockPanel*
it receives in its constructor the instance of the *VisorBlock* to be submitted
their data. In general the presentation is not a complication beyond
of persons as may be handling swing. The only thing to note
is that the presentation should not use anything that is not exposed in the API
from our library of logic.