[Geoprisma-dev] XMLMapContextConfig prototype driver

[Alexandre Dube]

Hi devs,

  There has been some discussion regarding a new config driver : 
XMLMapContextConfig.  Some conceptualization work has been done and a 
first config.xml prototype is now available (see attached).  At this 
point, no development has been done yet.

  We'll cover every general details in this e-mail so you'll have a 
basic understanding of how it works and what has changed from the old 
XMLConfig and XMLWorkspaceConfig drivers.

  N.B.: In this e-mail, I use the future and present tenses instead of 
conditional.  You understand that this new config is hypothetical at 
this point and the use of these tenses are grammatically wrong.  Sorry 
about that.


=== WHY ===
The main reason this new config was conceptualized :
* To be able to share a resource list in a specific geospatial context.  
This is the new <mapcontext> node.


=== OTHER NEEDS ===
Following countless discussions and comments from users and devs, more 
needs were required and they are added as well in this new config :
* Have a 'lighter' config file
* To be able to define an infinite number of maps (previously <map> 
nodes in the old configs, now being the <mapcontext> node) and to be 
able to choose the one we want.
* No more Resource-specific options in widgets
* No more mandatory Widget+Resource manual link
* Filters (logical, comparison and spatial)


=== DETAILS ===
Here are the new nodes and ones that are going to change while using the 
XMLMapContextConfig driver :

+++ <mapcontext> +++
* replaces the <map> node
* contains a list of resources to use in the map
* contains map options (projection, units, extent on startup, etc)
* note : resources in the mapcontext node can have their options 
partially or completely overwritten


+++ <resource> +++
* note: since the <map> node no longer exists, the <layer> nodes are 
gone as well.
* note: the options that were in <layer> nodes are now resource options
* note: by default, the OpenLayers.Layer objects created and added to 
the map are done automatically depending on the available servicetypes, 
see [1] for more about this.
* note: it is possible to overwrite this behavior (see above) by 
choosing a list of specific service types.  This is the <layersenabled> 
node.  It can be defined in a resource node (either directly in the 
<resources> or in a <mapcontext>).
* note : resources can have their options partially or completely 
overwritten (directly in the <resources>, in a <mapcontext> or both).
* note: resources from the same WMS service will *always* be combined in 
a single OpenLayers.Layer object from now on.  This won't have do be 
done manually anymore.
* Resources now have new options to allow them to *talk* to widgets.  
This is the new way to *link* the widgets to the resources. For example :
  * <editable> : allows the resource to be automatically linked to 
edition widgets
  * <queryable> : to query widgets
  * <layertreepath> : this is the option used by the layertree widgets.  
Each '/' means a new node and the following name is either the key to a 
i18n text or directly the text to display as a layertree node (folder).
  * <zoomField> : used by all widget that use a specific field as a key 
to zoom to a feature, like quickzoom, recenter, shortcut, etc.
  * etc...

[1] --- The OpenLayers.Layer auto-creation rules (the default behavior) :
* if the resource is linked to a TileCache service, a TileCache layer 
will always be added to the map
* else (see above), use the WMS service
* FeatureServer (vector) layers are only added if a widget directly use 
them (for exemple an edition widget)
* gymo are simply added


+++ <widget> +++
* widgets have no more resource-specific options
* widgets are automatically linked to the resources that have the option 
needed by the widget, like <queryable> for the query widgets
* no more map widget (replaced by <mapcontext> node)
* the mapfishlayertree (and future layertree widgets) are now much 
simpler, lighter and are automatically build by using the 
<layertreepath> option of the resources


+++ <application> +++
* replaces the <template> node to do basically the same things :
  * select a template file
  * select a drawmode
* contains a widget list to use
* widget options can be overwritten in an application
* widgets listed in an application are automatically linked to the 
resources that have the option needed by the widget, like <queryable> 
for the query widgets


+++ <session> +++
* note: the name 'session' is being discussed
* these nodes are optionals
* only goal : link one <mapcontext> to one <application>
* this could also be done directly in the .php file, in the url for 
example :
     geoprisma.php?mapcontext=MyMC2&application=MyApp3
* if sessions are used, you could use them instead :
     geoprisma.php?session=MySess8


+++ <filter> +++
* defined in the <filters> node
* linked directly to a resource, either in <resources> or in a <mapcontext>
* many can be linked at the same time.  They are combined by a logical 
'AND'.  For example: filter1 AND filter2 AND filter3.
* the node names and values are purely conceptual at this point.  More 
work and discuss needs to be done.
* Current filters are inspired from :
  * MapServer expressions
  * OpenLayers Filter objects
  * OGC Filter Encoding standard

=== end of : DETAILS ===


=== PROS ===
* resource sharing is now possible and easy
* no more illogical Resource+Widget mandatory links (like toolbar, 
scale, measure, etc)
* lighter reusable config files
* lighter and less widgets definition (since they have no more resources 
options)
* no backward compatibility (the same config_secur file would be 
outputed to be read by the .xslt widget files)
* this new driver is a phase 1.  A phase 2 could be a 
PDOMapContextConfig, resulting in a config completely stored in a 
database instead of a xml file.  A countless number of <mapcontext> 
nodes could be easilly created and maintained.


=== CONS ===
* changes are needed in all widget .php file to let them know which 
resource option to talk to
* a lot more of *automated* stuff, meaning a loss of flexibility but a 
huge gain of simplicity
* with the official release of this driver, the other 2 old ones will be 
completely removed and no longer supported.


=== CONCLUSION ===
* There's no time frame for this functionality yet.
* As soon as it is released, this way of writing a GeoPrisma config 
would become *the* official standard way of doing so.
* Comments are welcomed


Happy holidays,

-- 
Alexandre Dubé
Mapgears
www.mapgears.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: config.xml
Type: text/xml
Size: 23529 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/geoprisma-dev/attachments/20091223/a650af3c/config.xml