Hi, I have modified the ConfigManager, but nothing of what I have done couldn't be also done on the Django side or even in gxp.plugins.WMSSource:
The client side configuration has two new options - useBackgroundCapabilities and useCapabilities. If set to false, the ConfigManager generates OLSource instead of WMSSource layers, which means that no capabilities docs will be loaded. For a longer term perspective, I would prefer adding a useCapabilities option to the WMSSource configuration. But it would require some work to make the WMSSource plugin work without loading capabilities, and the WMSSource would have to provide at least a minimal, config generated caps doc that applications can rely on. I'd say for now we can live with the Django configuration and the ConfigManager, but if we have time to further simplify the code base, we should get rid of it and make the WMSSource plugin smarter. Regards, Andreas. On Jun 24, 2010, at 22:01 , Andreas Hocevar wrote: > > On Jun 24, 2010, at 21:56 , David Winslow wrote: > >> On 06/24/2010 03:48 PM, Andreas Hocevar wrote: >>> ConfigManager [6] >>> ================= >>> >>> Replaces the BackgroundLayerManager [7]. It requires about 70 more lines of >>> code, and its purpose is to convert between the configuration objects that >>> come from Django in GeoNode and the configuration objects that gxp.Viewer >>> requires. The BackgroundLayerManager is still used by the MyHazard viewer, >>> and was moved to the MyHazard namespace. >>> >> >> We are doing a bit of juggling on the Django side >> (http://github.com/GeoNode/geonode/blob/master/src/GeoNodePy/geonode/maps/views.py#L422) >> >> to produce that JSON. Do you think there would be a win (in terms of >> performance, simpler code, whatever) if we changed the format that >> Django is producing to better mesh with gxp.Viewer? > > This would definitely be a win. Not a big performance gain, but simpler code. > > -Andreas. -- Andreas Hocevar OpenGeo - http://opengeo.org/ Expert service straight from the developers.
