[udig-devel] How integratable is uDig?

[Matthias Basler]

Hi uDiggers,

this is an extension of a topic I already brought up last week with the mail "uDig as IDE extension". My concept has taken a bit shape, so there are a few things to discuss.

UDig is an extensible application - no question. So is the Eclipse IDE and my own RCP code.
Now I want to take things a bit further: I wondered if it is possible to create ONE application that contains uDIG (as GIS viewer/editor), my own code (adding specific business components) and the IDE (for scripting). While this idea in general is not very new, I am not sure many people have done this with Eclipse and, in particular, with uDig.

The problems/questions arising from this are:

1. Application component dependencies and assumptions

How much dependent are the uDig views and editors on uDig specific concepts? For example take uDIg projects. In my application I'd have no need for the uDig typical projects, since my concept for projects is quite different.

Ideally the different components of uDig (i.e. map editor, layer view, catalog ...) do not make any assumption about specific implementations of other components, but just work via interfaces or Adaptables. The latter is, what uDig uses, if I am not mistaken.

2. Internal classes used on startup

One problem that I encountered with the IDE is, that it performs some required startup initializations (in the ApplicationWorkbenchAdvisor, ActionBarAdvisor and friends). Often this code uses internal classes, because it is not expected that code outside the own application would need to perform such steps.
I am currently investigating if this is an issue with uDig as well. On a first glance it looks to be more integration-friendly.

3. Permanent actions vs. action sets

Combining three applications also brings another conceptional problem: There will be only one "Application" entry point, and therefore only one ActionBarAdvisor etc.

Usually applications define some "permanent actions" in this ActionBarAdvisor: Eclipse IDE does, uDig does and so does my own application. When doing integration this turns out to be problematic:

- The combined application needs all the actions

- Having many actions as permanent actions is problematic, because permanent actions are - well - permanent. That is, the IDE actions would f.e. show up in a map perspective and the uDig actions would show up in any IDE-related perspective.
AFAIK the only way around is to define all - except the very general actions - declaratively using action sets. It is possible to turn action sets off in perspectives - either by the user ("Configure perspective") or programmatically. The latter is a bit of a workaround using a perspective listener, but it works.

That's how far I have proceeded. Any thoughts are welcome.

The reason I tell you all this is because I wonder if you have ever considered the step from being "easily extendable" to being "easily integratable".

P.S.:
Jody wrote:
> One thing we do not have is a Map "ViewPart", we do have a MapEditor
> and the model used there can serve as the basis for your own view
> if you want. But right now we have focused on hooking into the Editor
> lifecycle.  We are very interested in making a more general purpose
> component as several of the applications based on uDig simply want
> display and do not really want to save/load that display.

Actually I am fine with the map being an editor. In the uDig application this fits like a glove imho. And there's nothing preventing the use of an editor component for just displaying data. Ok, you cannot stack the editor with other views, but I wouldn't do this anyway.
Why would YOU want a map view part instead? Because of the map actions being visible only when the map is active? (Just guessing.)
-- 
Matthias Basler
matthiasbasler at earthflight.org