Hi, I have finally committed refactored versions of the GeoNode map viewers and the composer. Note that this only affects GeoNode, not the MyHazard viewer. In this mail, I will explain the changes that I have made and how they affect future work on mapping related javascript components. GeoExplorer [1] =============== GeoExplorer is the base class for the map composer. It now inherits from gxp.Viewer and uses gxp.GoogleEarthPanel, and the CapabilitiesGrid is no longer required. All this saves us 690 lines of code. And it looks very similar to the OpenGeo Suite's GeoExplorer, which will make it easier to remove more code as gxp advances. As a side effect, with gxp.GoogleEarthPanel, WMS layers display fine again. Viewer [2] ========== Replaces Embed.js [3] and LayerPreview.js [4], saving us 80 lines of code. With the useMapOverlay and useToolbar options, a laver viewer can be configured as a lightweight viewer or just as a preview. To replace the old LayerPreview.js, the layer preview page now uses a gxp.LayerMenu configured on the application level instead of a tree to switch background layers [5]. The preview page now also sets the extent of the previewed layer correctly. 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. SearchTable [8] =============== Now also features a gxp.Viewer, saving us 50 lines of code. BTW, this component is a good example for a direct integration of a map into a web page, without using an iframe. With portalConfig, gxp.Viewer and subclasses make it easy to do such integration. Configuration (settings.py) [9] =============================== gxp.Viewer's WMSSource plugin does not require a GetCapabilities request url, just the base url of the WMS service. This is why I have removed ?service=WMS&request=GetCapabilities from the urls. Please contact me if there are any questions, and create bug reports assigned to me in case you find regressions. I will write about performance considerations and how we should work together on future ExtJS related JavaScript development in the future in separate mails. -Andreas. [1] http://bit.ly/asFdEZ [2] http://bit.ly/baGJPm [3] http://bit.ly/9B2mZY [4] http://bit.ly/9B2mZY [5] http://bit.ly/cQ0V1M [6| http://bit.ly/buf4WY [7] http://bit.ly/cmujxd [8] http://bit.ly/aov6xp [9] http://bit.ly/dhn0ez -- Andreas Hocevar OpenGeo - http://opengeo.org/ Expert service straight from the developers.
This is all such excellent stuff. It's really exciting to know that we're synced up with the tightest, most robust libraries now. Thanks for all this hard work, Andreas. It's going to make the client-side experience much better for both users and developers. Can't wait to get the live site update with the new front-end improvements. On Thu, Jun 24, 2010 at 3:48 PM, Andreas Hocevar <ahocevar@opengeo.org>wrote: > Hi, > > I have finally committed refactored versions of the GeoNode map viewers and > the composer. Note that this only affects GeoNode, not the MyHazard viewer. > In this mail, I will explain the changes that I have made and how they > affect future work on mapping related javascript components. > > GeoExplorer [1] > =============== > > GeoExplorer is the base class for the map composer. It now inherits from > gxp.Viewer and uses gxp.GoogleEarthPanel, and the CapabilitiesGrid is no > longer required. All this saves us 690 lines of code. And it looks very > similar to the OpenGeo Suite's GeoExplorer, which will make it easier to > remove more code as gxp advances. As a side effect, with > gxp.GoogleEarthPanel, WMS layers display fine again. > > Viewer [2] > ========== > > Replaces Embed.js [3] and LayerPreview.js [4], saving us 80 lines of code. > With the useMapOverlay and useToolbar options, a laver viewer can be > configured as a lightweight viewer or just as a preview. To replace the old > LayerPreview.js, the layer preview page now uses a gxp.LayerMenu configured > on the application level instead of a tree to switch background layers [5]. > The preview page now also sets the extent of the previewed layer correctly. > > 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. > > SearchTable [8] > =============== > > Now also features a gxp.Viewer, saving us 50 lines of code. BTW, this > component is a good example for a direct integration of a map into a web > page, without using an iframe. With portalConfig, gxp.Viewer and subclasses > make it easy to do such integration. > > Configuration (settings.py) [9] > =============================== > > gxp.Viewer's WMSSource plugin does not require a GetCapabilities request > url, just the base url of the WMS service. This is why I have removed > ?service=WMS&request=GetCapabilities from the urls. > > > Please contact me if there are any questions, and create bug reports > assigned to me in case you find regressions. > > I will write about performance considerations and how we should work > together on future ExtJS related JavaScript development in the future in > separate mails. > > -Andreas. > > [1] http://bit.ly/asFdEZ > [2] http://bit.ly/baGJPm > [3] http://bit.ly/9B2mZY > [4] http://bit.ly/9B2mZY > [5] http://bit.ly/cQ0V1M > [6| http://bit.ly/buf4WY > [7] http://bit.ly/cmujxd > [8] http://bit.ly/aov6xp > [9] http://bit.ly/dhn0ez > > -- > Andreas Hocevar > OpenGeo - http://opengeo.org/ > Expert service straight from the developers. > > -- Sebastian Benthall OpenGeo - http://opengeo.org
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? -- David Winslow OpenGeo - http://opengeo.org/
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.
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.
How much time would you estimate that this further simplification work would take? Is there a ticket for it? On Sun, Jun 27, 2010 at 1:57 PM, Andreas Hocevar <ahocevar@opengeo.org>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
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 <ahocevar@opengeo.org> 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.
>> 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. > I need a better spec before I can do that. What changes do you want made on the Django side? -d
Hi, the main change is to merge background layer config and viewer config into one object. I'll send an example config to the list when I get to it, so you can see how the gxp viewer config format looks. And what I said in my previous mail is nonsense - of course there is work on the javascript side: gxp.plugins.WMSSource needs to be modified to figure out portions of the missing Capabilities itself, and provide this to applications. My ballpark estimate for this would be 8 hours, in addition to 2 hours for removal of the ConfigManager. Sorry for the confusion -Andreas. On Jun 28, 2010, at 16:03 , David Winslow 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. >> > I need a better spec before I can do that. What changes do you want > made on the Django side? > > -d -- Andreas Hocevar OpenGeo - http://opengeo.org/ Expert service straight from the developers.