[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [udig-devel] Re: Breakdown of scope between projects
|
Matthias Basler wrote:
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
I should point out that I ment events from the model changing, user
feedback (either by events or callbacks) are sent from the widget to the
controller. The two are *completely* different things..
Basically:
+----------+
| model |
+------+ | +------+ |
| data | vs | | data | |
+------+ | +------+ |
+----------+
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.
Events into geotools, check on 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.
Lets call it command/controller (so we don't get confused with our model
events?). The controller is in my mind better situtated with the
widgets (the control only manipulates the model via its API, and the
controller represents the common ground of feedback you accept from your
widgets.
Basically this is a three part parttern: Model / View / Controller
(each are equal and separate).
If you want to consider it dynamicly we have:
- Model - events
- View - repaint, resize
- Controller - commands
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.
It seems we have arrived at the same conclusion.
- 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.
Ack don't ask me how much time I have wasted on legend icons. The
threading issues with getLegendGraphics from a WMS Layer will drive you
insane.
- 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.
Um shouldn't they be communicating at the model level? Both SWT and
Swing provide a model for things as simple as a button. This is one of
the motivations for using Model/View/Controller.
(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?
The widgets don't actually get to know about each other, there is the
model of Map/Layer/Style and if the legend widget modifies the SLD the
Map pane responds to the change in the model (the change could of come
come from something else).
Jody
