[udig-devel] Re: Breakdown of scope between projects

[Matthias Basler <Matthias.Basler@xxxxxxxxxxx>]

Someone suggested:

> GeoAPI
> - specifications (such as SLD, Feature, Filter)
> GeoTools
> - data objects (such as SLD, Feature, Filter)
> - visualization (such as renderers, Canvas)
> GeoWidgets
> - model (wraps data w/ events)
> - controler (allows modification of model via commands)
> - widgets (swt,swing,opengl)
> - canvas (such as Java2D, Draw2D, OpenGL raster)
> UDig
> - Formal breakdown into plugins, tools, keyboard shortcuts

My plan until now was that GeoTools would provide ready-to-used objects, so
GeoWidgets would only contain "controller" and "view" (in the MVC paradigm).

However I can understand the point Jody makes saying that "[events] is a real
hinderence to reuse". A separate layer transforming "data objects" into
"gui-ready" objects by adding thinks like events would indeed be a good idea
under this point of view. Actually the "modification of model via commands"
could well be done in exactly this event layer as well, as I could imagine.

However I am not sure that such event/controler layer should be part of
GeoWidgets for two reasons:
1. I do NOT want that using GeoTools automatically requires using
   GeoWidgets. GeoTools should deliver "complete" objects and I would
   include things like event notification in that.

2. Also maintnance of the the event/controler layer would need to be
   tightly coupled with the data layer ... doing this within one project
   should be much better to organize.

So in the end this concludes exactly where I began: I'd prefer it if GeoTools
delivers gui-ready "models" and GeoWidgets just holds the view and its
controller.

---

The splitting of "canvas" and "rendering engine" makes sense on a first look,
but I do not yet have the needed knowledge about the rendering process to
discuss this with you.

---

On the uDig side of things I am not yet sure where exactly the border
should/will be. Just some current concepts of mine for things like the legends
view:

- The widgets shall be fully functional in their "default" configuration and
f.e. be usable as a GeoTools test environment.

- uDig should be able to override certain functions (by subclassing the
objects), f.e. to get custom icons or behaviour into the widget, where
necessary. Also if the widget cannot support anything uDig wants, than this can
simply get added either by extending the widget's code itself or within uDig.
Flexibility is the key.

- Since the widgets shall be independent of each other I will likely introduce
interfaces for each type of widget. This way they can communicate with each
other in an application without needing a certain implementation.
(E.g. Map pane communcates with legend and legend with SLD selection wizard or
CRS selection wizard ... and vice versa.)
Not sure this works but its worth a test, I believe.

Your comments on that?

Matthias Basler
c9bama@xxxxxxxxxxx


----------------------------------------------------------------
This mail was sent through http://webmail.uni-jena.de