[udig-devel] Target as hook for Issues (vs Groups)

[Jody Garnett]

So the Issue model has been refined over the last couple of weeks - but 
not on this public email list.
Now that I have developers looking to implement, there are a few things 
to resolve - and I ask that we work through them on the public 
(development) list. If you are working on a uDig based project this 
topic is of interest to you, as we are trying to provide a new facility 
that will help automate some interaction with your custom applications. 
This represents the first step of the uDig project offering you more 
then just visualization :-) And yes I am thinking of projects like 
DivaGIS here.

Very exciting!

Issues appear to be have, a type and a group (I assume the TreeTable can 
be grouped by either for display much like eclipse problems view)
What is missing from this array, is an Issue "target" - let me explain 
what that is - and why we cannot simply map this onto "group".

Issues need to be "raised" against specific objects in a domain model 
being hosted by uDig. Applications such as DivaGIS place domain objects 
on their map blackboard for fun and profit. We are trying to set up an 
issue model that lets us represent issues against these sorts of things.

And in proper eclipse style we should make use of the same facilities 
ourselves; so lets do that ....
Map - a map could have various issues (say data not being available)
Layer - a layer could have various issues (say feature not passing 
validation tests)
GeoResource - may have some issues raised against it (perhaps it is 
missing projection information)

Those examples may be too specific (since they are classes we are 
familiar with), so let me add one:
ReviewQueue - perhaps the uDig based application has a queue of maps 
that are in need of review

So in order to make an Issue not dependent directly on Map, Layer, or 
GeoResource we need to seperate out the concern.

For inspiration we can look to a "workflow system" (basically the real 
J2EE solution for these problems), workflow systems take on the job of 
managing an objects state, including allowing normal users to define the 
states an object can go through. As such you need to pick up your domain 
object and ask it to delegate a lot of functionality to a common module 
called the workflow system. To communicate with these systems they 
usually give you an "ID" that you can used to ask what you current state 
is, and what actions are allowed from there etc...

We have a similar situation, we need to give out an "ID" that people 
writing their Domain Model can hold onto, and then they can ask the 
issue system for a list of issues associated with them.

And we can kickstart this process in uDig by making use of a "target" ID 
for Map, and Layer.

Now Map and Layer are never supposed to change when we add new 
functionality like this, we are supposed to use the MapBlackboard. So if 
we had a key on the map black board to hold this ID from the issue 
system we would be set.  However I do not think the MapBlackboard is 
persisted, for specific applications people are supposed to persist the 
information they care about off the blackboard (often to database or disk).

To make this kind of thing easier it would be nice to make good on a 
couple of map black board ideas:
- persist entries on the map blackboard that are Serializable
- visualize entries on the map blackboard that are Features
(both of these would ease the pain of making new tools, and using udig 
for your own custom work)


So the question is:
- do we need a Target interface (single method that can return a target 
ID used to query into the issue model)
- or just the ID enough?

Answer is we need the interface, so that if a Target appears as the 
current selection we can adjust the Issues view to track it.

Next question is - Map and Layer form a hierarchy do we need Target to 
form a heirarchy?

Formal answer is "no", hierarchy is from the domain Map can traverse its 
layers and build up a list of all issues
Pragmatic answer is "yes", is Target can have child targets, our single 
issues view would work out of the box for Map/Layer, and the same 
facility would be available for other domain models.
Final answer is "no", we can click around to the different layers, lets 
not make things complicated unless people really find the pragmatic 
answer saves them time.

Sorry to not be more involved on this one, I had hoped the target thing 
was being sorted out.
Jody