[Users] Tree node disabling with min/max scale

Pierre Giraud pierre.giraud at camptocamp.com
Fri Oct 22 09:43:12 CEST 2010


Hi all,

Sorry about that but I forgot to mention that there's something
special with the code I proposed.

In my case, I had to deal with LayerParamNodes which are not tightly
bound to a layer but to a WMS sub-layer. I couldn't listen to
"visibilitychanged" because the OL Layer visibibility doesn't change
actually.
Code is better than talks so imagine the following tree (manual) configuration:

{
    text: "Tourisme et vie local",
    children: [{
        text: "Tourisme",
        children: [{
            nodeType: "gx_layerparam",
            text: "Piste de ski",
            item: "pistes_ski",
            maxScale: 50000
        }, {
            nodeType: "gx_layerparam",
            text: "Piste de ski de fond",
            item: "pistes_fond"
        }]
    }]
}

In this example, the maxScale value is set adequately to the
configuration in the mapfile. This is a bit specific because it is
configured manually, but we could imagine a way to get this
information by reading Capabilities.

So, the goal is probably not the same as the one Alexandre or Matt are
trying to reach.

Regards,
Pierre


On Thu, Oct 21, 2010 at 9:54 PM, Andreas Hocevar <ahocevar at opengeo.org> wrote:
> Hi,
>
> I think the approach with the visibilitychanged event has less overhead. And if people prefer a plugin, it could also be combined with a plugin approach: whenever a layer node is added to the tree, the plugin could register the event.
>
> But even if it's going to be default behavior, it can easily be disabled by making the css class for the disabled layer configurable.
>
> Having said that, I don't have a strong opinion on plugin or not, but I do like the visibilitychanged approach better.
>
> Regards,
> Andreas.
>
> On Oct 21, 2010, at 21:14 , Eric Lemoine wrote:
>
>> On Thu, Oct 21, 2010 at 8:14 PM, Alexandre Dube <adube at mapgears.com> wrote:
>>> Matt,
>>>
>>>   Like I mentioned, I would need this feature rather quickly.  Do you
>>> wish to do the fix ?  If not, I'm willing to make the changes (with the
>>> appropriate ticket + patch).
>>>
>>>   Andreas, do you agree with the change or would you rather see it as a
>>> plugin as Pierre and Matt proposed ?
>>
>> A plugin would be great.
>>
>>
>> --
>> Eric Lemoine
>>
>> Camptocamp France SAS
>> Savoie Technolac, BP 352
>> 73377 Le Bourget du Lac, Cedex
>>
>> Tel : 00 33 4 79 44 44 96
>> Mail : eric.lemoine at camptocamp.com
>> http://www.camptocamp.com
>> _______________________________________________
>> Users mailing list
>> Users at geoext.org
>> http://www.geoext.org/cgi-bin/mailman/listinfo/users
>
> --
> Andreas Hocevar
> OpenGeo - http://opengeo.org/
> Expert service straight from the developers.
>
> _______________________________________________
> Users mailing list
> Users at geoext.org
> http://www.geoext.org/cgi-bin/mailman/listinfo/users
>



-- 
Pierre GIRAUD
Géomaticien, Analyste

Camptocamp France SAS
Savoie Technolac, BP 352
73377 Le Bourget du Lac, Cedex

Tel : 00 33 4 79 44 44 93
Mail : pierre.giraud at camptocamp.com
http://www.camptocamp.com


More information about the Users mailing list