[Geoprisma-dev] config.xml ideas : automatism

[Yves Moisan]

> Hey,
> 
>   I need opinions.
> 
>   Here's an example use case.  Currently, in the config.xml, when you 
> want to add edition on a Resource (for example) you need to :
> 
>   - setup a DS with <fields>
>   - setup an editfeature widget
>   - setup an featurepanel widget
>   - setup a layer node in the map object with needed options
>   - be sure that you think to set a min/max Scale or Resolution so that 
> your vector layer is not always visible
>   - also set it in the tree
>   - set some styling
>   - etc.
> 
>   What really pisses me off is to have to think to all that.  For that, 
> I'd propose to *automatize* as much stuff as possible.  The main 
> downside : less customization possible.
> 
>   My first idea is to  automatize the layer creation.  No more <layer> 
> node needed is my main objective.  The resources defined with their 
> datastore have to be enough.  For that, a couple options / behavior 
> would be needed :
> 
>   - Vector layers are *only* added if a widget use it.  No options.  
> This is the only behavior.
> 
>   - By default, only one of these type of layer is added : tilecache or 
> wms.  If set to false, all layer types are added.
>       <singleLayer>true</singleLayer>
>   - By default, tilecache is added first.
>       <layerPriorities>
>         <layer>tilecache</layer>
>         <type>wms</type>
>       </layerPriorities>
>   - By default, wms layers are automatically merged if they share the 
> same service, but you can turn that option off
>       <mergeWMSLayers>true<mergeWMSLayers>
> 
>    (for the above options, no one needs to be defined.  They all have a 
> 'default' value.  If you want a different behavior, change it.)  All the 
> above options are part of the <application> node.
> 
>   - Layers are automatically added to the layertree with a single option 
> in the resource : <layerTreePath>/my/path/</layerTreePath>
> 
> 
>   Again, the price to pay is : less customization, but more simplicity 
> to use.
> 
>   That's the main thing I'm aiming and that's what I want you to tell me 
> : does this makes sense ?

Off the top of my head :

- if only a tilecache layer is automatically defined, will the
queryonclick still be resolved (or will adding a queryonclick on a
resource automatically trigger a wms layer to be added) ?

I agree things are pretty complicated in the xml file now, but I'm not
sure adding lots of automagic things is really helpful in the end.
Implementers will have to go back and forth between their config file
and a view source just to see what was automagically generated.  

Could we think of adding some parameter to the config file that would
tell GP to use automatic behaviour or something ?  I don't know really.
Maybe we could use a model similar to POM.xml Maven files -- I just
happen to be in that now :-) -- where xml files can inherit and include
other xml files.  A top (root) config.xml would include modules (other
config.xml files) and each of those config.xml files would refer back to
their parent (root) file for potentially common
configuration/behaviour ?

Anyhow, I suggest we don't go and implement "automagicness" now and
concentrate on broadening the list of widgets in GP for a start.  I am
too rather concerned by the size and complexity of our config.xml file
but we need to step back and think how to factor things out and
obviously how to implement things.  Does that sound reasonable ?

Yves