Integrating with gvSIG
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:
<AndamiProperties>
<ApplicationImages>
<SplashImages>
<Splash
path="splash.png"
timer="10000"
x="270" y="240"
fontsize="18"
color="80,170,240"
version="2.0"/>
</SplashImages>
<!--BackgroundImage path="theme/logo_es.png"/-->
<!--WallpaperType value="CENTERED"/-->
<Icon path="$GVSIG_INSTALL/theme/icon.png"/>
</ApplicationImages>
<ApplicationName value="gvSIG 2.0.0"/>
</AndamiProperties>
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.
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:
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:
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:
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:
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:
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:
ApplicationManager application = ApplicationLocator.getManager(); ProjectManager projectManager = application.getProjectManager();
Once we have these references, we can create our view:
// 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:
// 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:
// 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:
// 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:
// 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:
// 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:
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:
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.