[udig-devel] CRS, Map, Viewpor + preferences

["Vitali Diatchkov" <vitali@xxxxxxxxxxxx>]

Hi! Some words about CRS, Map, Viewport, etc..

I have created preferences framework with some pages as examples  but didn't
add to the repository while it is unclear where to persist preferences. For
example there is a "Map" preference page where the user specifies default
CRS for all new created maps.  As I mentioned in one of old letters (see
attachment) there should be unified way to persist preferences:

-through default IPreferenceStore that AbstractUIPlugin has
-through custom IPreferenceStore if plugin class doesn't extend
AbstractUIPlugin
-whatever else

Then from different parts of code those preferences are requested.. 

for example ViewportModel.getDefaultCRS() actually asks preferences and
instantiates default CRS from preferences, not hard-coded WGS84, etc.


The problem: ViewportModel is in Project plugin that is not AbstractUIPlugin
, so, no default IPreferenceStore - the custom is needed (one of the
solution). Custom means the same as in Catalog plugin where "Catalog" view
content is persisted. If to save preferences in Project.Ui plugin (It
extends AbstractUIPlugin) - there is no dependency from Project.Ui plugin in
Project plugin, etc..  Always there are workarounds but the solid unified
solution is needed.



As concerns CRS, from the point of view of "stupid user" the behavior should
be:

1) If the resource is added to the new map where there is no data at all and
this resource has determined CRS, then this CRS is selected as default for
the map.
2) If the resource is added to the map where there are already other
resources then nothing with map's CRS - it is already must be defined.
3) If the resource is added to the map where there is no data at all and
resource's CRS is undetermined then default CRS from preferences is chosen.

Another point of view of another "stupid user" is:

1) Always the default CRS from preferences is set to the newly created map.
That's it.


So what is the best solution that gives the most usability.. whatever. From
MY point of view the second stupid user is right.


Vitali.

--- Begin Message ---

• From: "Vitali Diatchkov" <vitali@xxxxxxxxxxxx>
• Date: Fri, 27 Jan 2006 17:50:21 +0200
• Thread-index: AcYh3H9d7uv/FuiRTpWr/TJghYlr7ABdRCsg

Hi!

1)

I have dome some work creating "Preferences" framework and  writing
description that will put to "Project Guide" or somewhere in
documentation...

The main issue how to manage preferences among plugins.

If the developer implements own plug-in and contributes own set of
preferences pages - in general it is up to him where to store preferences.

But for "core" preferences there should be general way.

IPreferencesStore provides good API for dealing. If main plugin class
extends AbstractUIPlugin - the support of IReferenceStore is automatically
available. ProjectPlugin has another "nature" .. So should we add manually
loading and persisting custom IPreferencesStore instance while starting and
stopping ProjectPlugin?

Project model classes will lazily ask default properties from
IPreferenceStore and initialize if necessary, for example as default CRS for
the new MapImpl.. and UI preferences pages deal directly with
IPreferenceStore - it is a kind of "preferences exchange bus":  through UI
properties are set to IPreferenceStore - model classes ask IPreferenceStore
and instantiate default values, probably cache objects in static variables
or whatever..

Then in javadoc of each preference page the list of keys should be
described, e.g.

<ul>
<li><code><b>org.udig.project.preferences.default_map_crs</b><code> - WKT of
default Coordinate Reference System for new opened maps.


 In a such way we have framework where:
- unified access and management of properties through IPreferenceStore API,
using of FieldEditor's makes the life easier, etc.
- for developers the javadoc with keys and values description in each
PreferencePage implementation.

The main issue for me what API to use: is IPreferenceStore is good enough -
in that case how to deal if plugin doesn't extend AbstractUIPlugin.

Vitali.

--- End Message ---