[Geoprisma-dev] XMLMapContextConfig prototype driver

[Stephen Woodbridge]

Alexandre,

Wow, you have put a lot of work and thought into this proposal. Looks 
really great.

I have one question about your [1] note. If I have a vector only layer 
in featureserver and no wms services for it, will it get configured or 
would/could I need to take explicit action to have it configured 
appropriately? I guess to some extent you could just say you have to 
have a WMS service for each featureserver service, but this seems like 
an arbitrary constraint especially if I don't own the featureserver or 
proxy request off to another server.

Just food for thought. Very nice proposal and a lot of ideas and 
information to digest.

Merry Christmas to all,
   -Steve

Alexandre Dube wrote:
> 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,
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Geoprisma-dev mailing list
> Geoprisma-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/geoprisma-dev