[udig-devel] Re: [Geotools-devel] Re: Breakdown of scope between project

[James Macgill <jmacgill@xxxxxxxxx>]

> 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).

Thats exactly what geotools should be, the Model.  (Rendering is a bit
tricky as it is a process rather than a view, control or model, for
now I would like to see rendering stay within GeoTools.  Jody's
earlier comment about me worring about the ShapeFile specific renderer
is actualy out of context, their are alternative solutions to my
concerns that result in the use of stratergy patters and a more
capable DataStore API...)

> 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.

Events are a cross cutting concern, so wrapping them over the top is
inapropriate, as it doing it through extention.  I have an urgent need
to add events to the Style objects but have held off as it is very
nasty (propogate events up though a very deep tree, which can wander
off into filters and expressions).

To solve this I was contemplating dynamic proxies or even aspects code
(behaviour injection in to the set methods) but I welcome an event's
discussion across the whole geotools board.  (aspects could give us
events for every set method everywhere btw)

> 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.

The canvas is the view and the control in this case, and it controls
several models.  e.g. a layer model, a selection model an AOI model.

James