**Direct translation from google Translator**

So far we have seen how to create our components, logic and user interface, using
gvSIG libraries to access the geographic data or to present as well as a
simple way to create a small application that uses them. Let's see now as integrate
implementing these features in gvSIG.

If we look at the projects we have in your workspace you will see that there is still one on which we have not worked, **org.gvsig.visor.app.mainplugin** . That is where we implemented
plugin. Before the plugin code to see a detailed comment. When we described what had
to do our extension, we said we had to present a *splash* customized. Let us first
how we can do this.

In the folder *"src/main/resources"* folder find a *theme*, and within this one
*andami-theme.xml* file. This file is responsible for specifying the andami framework which *splash* must dislay as well as must be used a background image in the application MDI or the gvSIG windows icons. Andami, when starts, searchs into the extensions folder anyone wich contains a *theme* folder and within this file and when it finds it, it uses it. Xml file in our example contains:

.. code-block:: xml

  
    
      
        
      
      
      
      
    
    
  

By default routes appear in the file will be interpreted on
the location of this file, having a variable *GVSIG_INSTALL*
point to the folder where gvSIG is installed. In the example we
see how the tag *Splash* not indicated path to the file *"splash.png"*
Authors used the files in the folder while the plugin tag
*Icon* variable *GVSIG_INSTALL* is used to refer the file
is in the default theme of Andami.

GvSIG can start and check out the *splash* indicated in
our *andami-theme.xml*.

Having seen how we can change the *splash*, we take a look at the
extension of our plugin.

.. note el config.xml !!!!!!!!!!

Now let's see the code for our *plugin*. We will see that there are only
two classes, *VisorExtension* and PropertiesOfBlockListener VisorExtension. The class that integrates our functionality in gvSIG is *VisorExtension*. This class extends the *Andami* class *Extension* to integrate with the menus and toolbars, and implements the *ExclusiveUIExtension* interface to control the visibility of other gvSIG extensions.

To control the visibility of the other areas of gvSIG, the interface
*ExclusiveUIExtension* provides methods:

- **isEnabled** receiving as parameter the extension on which
  want to know whether to be enabled or not:

  .. code-block:: java

    public boolean isEnabled(IExtension extension)
  
  In our case, as we want to disable all extensions editing, check if the extension that comes in the java package *"org.gvsig.editing"*  and for all who are in that package return *false*, while for the rest, delegating them to
  determine whether or not to be enabled.
  
- **isVisible** receiving as parameter the extension on which want to find out whether it should be visible or not:

  .. code-block:: java

    public boolean isVisible(IExtension extension)
  
  In our case, we will use to determine which areas should be visible
  the same we use to determine whether they should be disabled.

It is very important delegate *isEnabled* or *isVisible* methods of each extension and not return *true* as you may specify the extent of certain specified conditions; to be visible and active checks herself.

The methods that we find in our class *VisorExtension* that needs to extend to *Extension* are:

- **initialize**. Is invoked when loading a. Here we will simply record
  services provided by our extension. In our case we will simply inform the
  *plugins* *Manager* that our viewer class wants our to act as controller of the
  visibility of all extensions. This is done through the method *SetExclusiveUIExtension*:
  
  .. code-block:: java

    PluginsManager manager = PluginsLocator.getManager();
    manager.setExclusiveUIExtension(this);

- **PostInitialize**. Invoked during the initialization of the plugin, once invoked
  *initialize* method of all extensions. This guarantees that when you run
  will become available virtually all parts of gvSIG. Take advantage of this method
  for:
  
  - Add our information *about gvSIG*, this is done through our *addToAbout function*. The code that does is:
    
    .. code-block:: java

      AboutManager about = AboutLocator.getManager();
      
      URL description = getResourceURL("about/description.html");
      URL icon = getResourceURL("about/icon.png");
      AboutParticipant dev = about.addDeveloper("Mi empresa", description, 1, icon);
      dev.addContribution("Mi visor", "Visor para consulta de parcelas catastrales", 2011, 5, 1, 2011, 7, 1);

    When we add our information to *"about"*, we have to do two
    things:
  
    - Add an entry and developers with our information. We
      provide the name of our company and a description of this by
      the URL to an HTML document. Normally this document is
      resources of our project.
      
      If two extensions try to add more than once as a business developer
      with the same name will be added only the first.
      
    - Added information about our company development we have done, a
      name and a brief description.
        
    Normally we make each plugin register the company, such information
    concrete development of the plugin.
  
  - Create the manager of the logic part of our library.
  
  - Initialize *stores* through our function *initializeStores*. As the manager of our logical library has methods available to initialize the *stores*, we will be limited to
    invoke them:

    .. code-block:: java
    
      manager.initialize(
        getResource("data/properties.shp"), 
        getResource("data/blocks.shp")
      );
      
  - And finally create and display for sale with our eyes, through the method *createViewWindow*. 
    let's see a little more detail how this is done. Before you start
    first thing to do is to obtain an object reference *application* and
    *projects* Manager:

    .. code-block:: java

        ApplicationManager application = ApplicationLocator.getManager();
        ProjectManager projectManager = application.getProjectManager();

    Once we have these references, we can create our view:
    
    .. code-block:: java

      // 1. Create a new view and set the name.
      ViewManager viewManager = (ViewManager) projectManager.getDocumentManagers(ViewManager.TYPENAME);
      ViewDocument view = (ViewDocument) viewManager.createDocument();
      view.setName(MY_VIEW_NAME);

    To create the view, ask to *ProjectManager* to return the manager views as
    This will ask a new instance of the document view. We recall here
    one of the main
    features of the *manager* is to act as a factory for instances of the
    managed objects that *manager*. Once we have the document view, assign the
    name that we deem appropriate.
    
    With the view already created, we will see what we do to add to this the layers
    need it. This will create a layer with the Manzamo this end we use
    *createLayer* method, indicating the name of the layer and the *store* on that we want to be based:

    .. code-block:: java
    
      // 2. Create a new layer with the blocks
      FLyrVect layer = (FLyrVect) application.getMapContextManager().createLayer("Blocks", this.manager.getBlocks());

    With the layer already created, add the * map * of the view the new layer:

    .. code-block:: java
    
      // 3. Add this layer to the mapcontext of the new view.
      view.getMapContext().getLayers().addLayer(layer);

    We will add th view to the current project:

    .. code-block:: java
    
      // 4. Add the view to the current project.
      projectManager.getCurrentProject().add(view);

    And finally we will present the window Join the view that
    just created:

    .. code-block:: java
    
    .. code-block:: java
    
      // 5. Force to show the view's window.
      IView viewWindow = (IView) viewManager.getMainWindow(view);

      application.getUIManager().addWindow(viewWindow, GridBagConstraints.CENTER);
      try {
        application.getUIManager().setMaximum((IWindow) viewWindow, true);
      } catch (PropertyVetoException e) {
        logger.info("Can't maximize view.",e);
      }

    Once we have shown our view window, be recorded in the
    map graphic component we bring the new tool, similar to
    as we did to add it to our map in the test project:

    .. code-block:: java
    
      // 6. Register my tool in the mapcontrol of the view.
      PropertiesOfBlockListener listener = new PropertiesOfBlockListener();
      viewWindow.getMapControl().addBehavior(TOOL_NAME, new PointBehavior(listener));

  With all this we initialize our plugin.
  
- *execute*. This method will be invoked whenever the user interacts with the options
  menu or buttons that are configured in the *config.xml* file of our plugin.
  In our case, was set to trigger this event when the user
  wanted to activate the tool of information on cadastral parcels
  an apple. So the code would have to have there must correspond
  with this:

  .. code-block:: java
  
    if( ACTION_SETINFOTOOL.equalsIgnoreCase(actionCommand) ) {
      // Set the tool in the mapcontrol of the active view.
      ApplicationManager application = ApplicationLocator.getManager();
      if( application.getActiveWindow() != viewWindow ) {
        return;
      }
      viewWindow.getMapControl().setTool(TOOL_NAME);
      }
    }

  Observe that the first thing we do is check if the command received
  is that corresponding to the activation of our tool, and we set
  in *config.xml*. This is because in the same extension can
  group several tools, indicating different command names in the
  *config.xml* for each.
  
  Once we know that you are trying to activate our reporting tool,
  check if the window is active in our view, since on other views or
  other document types, we should not do anything. And finally, we will work
  to activate our tool in the map view. Toolmakers we recorded
  postInitialize * in * our extension.
  

- *isVisible*. In this method we report if the menus and buttons associated with our
  tool should be visible. In our case, our tool will leave visible
  where is the active window from view:
  
  .. code-block:: java

    ApplicationManager application = ApplicationLocator.getManager();
    return application.getActiveWindow() == viewWindow;

- *isEnabled*, which always return 'true', since our tool is active
  whenever it is visible, and there he put the necessary checks. If the
  logic allows our tool is not active in some cases
  which itself is allowed to be visible, will be here where we make these checks.

Basically, we have reviewed as is the integration of our functionality in gvSIG.
It remains to be seen *PropertiesOfBlockListener* class we use to create our
tool. The code of the *listener* is basically similar to that used by our
test application.