On Jun 28, 2010, at 15:57 , Sebastian Benthall wrote:

> How much time would you estimate that this further simplification work would 
> take?

On the JavaScript side, it is more about removing code than writing new code, 
so just a few hours. Maybe David can better estimate the amount of work on the 
Django side.

> Is there a ticket for it?

I have not created one yet. Let me know if you want me to, or just create one 
and I'll add a comment.

-Andreas.

> 
> On Sun, Jun 27, 2010 at 1:57 PM, Andreas Hocevar <[email protected]> wrote:
> 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.
> 
> 
> 
> 
> -- 
> Sebastian Benthall
> OpenGeo - http://opengeo.org
> 

-- 
Andreas Hocevar
OpenGeo - http://opengeo.org/
Expert service straight from the developers.

Reply via email to