This is the first of a series of posts where we are going to explain all the novelties at the Scripting module, from its new integration to the new developed tools.

A small reminder about the Scripting Module. Its development is focused on Jython libraries and scripts, because of its ease, versatility and power. This language allows us to mix Java and Python in the same application. Apart from it there are another options to create scripts like Groovy or R.

You can test this new integration in the new gvSIG 2.3 RC2 version already. There’s some bug in the libraries, and if you find any other error you can inform us at the gvSIG mailing lists. We also will publish new documentation.

New integration

What have we done?

For the new gvSIG 2.3 version we have done several important changes at the Python libraries integration with the gvSIG API. At this new integration we have followed an approximation that is different to the previous gvSIG versions.

Instead of rewriting all the classes that gvSIG has in its API already, we have delivered extra methods, developed in Jython, on these existing classes. We also have added new methods to the gvSIG API. It will be very useful because Java developers will be able to use them too.

Why have we done it?

At that way we decrease the efforts required to maintain these libraries, and we increase the compatibility with the rest of the gvSIG API too.

One of the errors of the previous version was that we had to work with Java and Python objects at the same time and it was very difficult because of their incompatibility.

What consequences does it have?

At this way we always are going to work with Java objects in our scripts (if we only are working on the gvSIG API).

We remember that, as we are working with Python, we will be able to create classes that have characteristics from Java and Python. We will be able to import Python libraries, Jython libraries that mix Java and Python, and Java libraries that gvSIG includes, or external ones.

Is the compatibility with gvSIG 2.2 version kept?

In spite of the important changes that have been applied in an internal level, they won’t be noted in an external one. We have tried to keep the compatibility with gvSIG 2.2 as much as we have been able to. In the next weeks we will publish a new post about these changes, showing source code, where you will be able to change the libraries path or some lines of code.

We’ve also added a compatibility option for gvSIG 2.2 scripts, that we are testing.

What part of the libraries are affected by this implementation?

It affect mainly to the classes that refer to the data processing. We’ve wanted to simplify this part to encourage inexperienced users that are interested in creation of new geoprocesses or data analysis to do it in an easy and fast way, like in the 2.2 version.

In the same way, we’ve created some functions that will make easy the creation of objects, for example layers, or the accessing to the loaded ones.

The geometry (geom) and window manager (commonsdialog) libraries have increased their capacity and ease of use in a considerable way.

Besides, we’ve developed some extra libraries made in Jython, like formpanel, that will help us to generate scripts with graphical interface, or classes that will help us to implement scripts as geoprocesses at the Toolbox.

What are the main advantages?

It will make the communication easy between our scripts and the gvSIG API. At this way, we want to encourage new developers making easy all the typical processing data operations, as well as to the advanced developers, ensuring the compatibility between different extensions developed on Jython, Java and gvSIG.

As there have been a lot of changes at the libraries and tools, we encourage you to inform us about the errors that you detect in the scripting libraries at the Users and Developers mailing lists.