From this section you can manage your own event listeners reacting to JMap Server NG library events.
For all your listeners, you need to provide a listener id. We introduced this notion of listener ids in order
to be able to know what's the problem if something goes wrong in a listener.
Like that we are able to identify more easily the problem in the javascript console.
Listener ids have to be unique for the namespace, regardless to the type of event you register your listener to.
For example, for all Map Context events, you can register only one listener named "my-custom-listener"".
A good practice could be prefixing all your listener ids. For example if you work for the city of Montreal
they could all start with "montreal-city-"".
Listeners can be deactivated and reactivated.
Deactivating a listener keeps it in the JMap Server NG library, but ignores it when an event is triggered.
JMap.Application.Event
From this section you can manage your own event listeners reacting to JMap Server NG library events.
For all your listeners, you need to provide a listener id. We introduced this notion of listener ids in order to be able to know what's the problem if something goes wrong in a listener.
Like that we are able to identify more easily the problem in the javascript console.
Listener ids have to be unique for the namespace, regardless to the type of event you register your listener to.
For example, for all Map Context events, you can register only one listener named "my-custom-listener"".
A good practice could be prefixing all your listener ids. For example if you work for the city of Montreal they could all start with "montreal-city-"".
Listeners can be deactivated and reactivated.
Deactivating a listener keeps it in the JMap Server NG library, but ignores it when an event is triggered.