Clear separation of graph node expansion and resource loading

[GoogleCodeExporter]

Expanding the neighbourhood of a node in the graph view can trigger the loading 
of resources. This should be handled transparently by the framework. The goal 
of this issue is to design, implement and document a node expansion mechanism 
that leads to a better separation of concerns. The design goals are:

1. The loading of resources should be handled in a transparent way by the 
framework. The graph view should just request a resource property that contains 
a URI list. If the URI list has not been loaded yet and a load manager has been 
registered, the loading should be done automatically. The results should be 
reported back asynchronously to allow for server calls.

2. The resources from the URI list should be added to the view, allowing for 
automatic grouping and arc display.

3. The grouping and arc display should be handled separately.

4. The new view items should be layed out around the expanded node. This is 
difficult because it requires us to identify the view items that are related to 
the node expansion.

Original issue reported on code.google.com by Lars.Grammel on 22 Dec 2010 at 11:45

[GoogleCodeExporter]

Original comment by Lars.Grammel on 22 Dec 2010 at 11:45

[GoogleCodeExporter]

It looks OK, but I have some questions about the asynchronous callback. First, 
how would it work? How does the framework know to request the loading of 
resources? Does it make a call to the load manager with a callback? Also, what 
happens when not all of the resources can be loaded (server error, or missing 
resource?). Do we just forget about the missing resources, or do we try again?

Original comment by delmyers...@gmail.com on 22 Dec 2010 at 6:41

[GoogleCodeExporter]

I was thinking that we would always pass an asynchronous callback into Resource 
whenever we try to access URIList properties (or maybe even any property), but 
this might make programming really awkward and complicated. I am not sure what 
the best solution to this is, as calling the server transparently requires 
asynchronous callbacks. Events might be an alternative, but this ends up with 
the same awkward indirection. We could also supply two variants for accessing 
resources, one with an async callback that loads resources/properties on demand 
if required, and another variant that is a regular method call which returns 
null if the property has not been loaded yet.

The framework would know to request the resources based on a mapping of 
resource type and property to a specific loader that we would need to set up. 
We could keep track of loaded resource properties using flags in resources.

The callback would also be notified whenever the resources could not be loaded 
(onFailure). That way, we could react to loading failures and missing resources 
in customizable ways.

Original comment by Lars.Grammel on 23 Dec 2010 at 12:38