GeoExplorer and Tool configuration

[Ivan Willig]

I have a couple of questions about geoexplorer and gxp,
maybe not be important to a lot of people.

I notice that we currently store some of the gxp tools as
configuration objects in the geonode database. For what I understand
the reason for doing this is to allow for these tools to be
configurable across different mapping applications. Is that correct?

I just bring this up because it seems like we are storing map
configuration properties in the tool json config as well. Like the
following,

https://gist.github.com/iwillig/797f33eb88ea8e4d6f0a#file-gistfile1-json-L71-L76

The map properties widget allows users to modify three properties and as
it turns out, also takes care of storing these proprieties in the
database. This widget also manages modifying the map object when this
widget added to the application.

I think this combining the tool with the state it manages makes this
code hard to work with. For example because the state management is
done in the widget, one would have to do a lot of code copying in
order to allow users to modify the background color with a different
widget.

I feel that we have important state that effects the running of the
GeoExplorer application hidden away in these tool objects.

Its seems like one thing we could do is to move this information into
the map configuration object itself. Centralized all core state
management into a single location and provide an api for modifying
this information. This would allow the tools/widgets to talk to the
map config object in a uniform way. Less coping  of code in order to
build different interfaces.

One place were this might help is the metadata widget.

the save method,

https://github.com/opengeo/geonode/blob/mapstory/src/geonode-client/app/static/script/app/GeoExplorer.js#L937

and the save as method,

https://github.com/opengeo/geonode/blob/mapstory/src/geonode-client/app/static/script/app/GeoExplorer.js#L948

These are very similar. 

Maybe the api could look something like,

this.mapAttributes.set('title', 'This is a great map');
or
this.mapAttributes.get('title');

I am sure that Ext.js has something for this type of code. Could we use something like
http://docs.sencha.com/extjs/3.4.0/#!/api/Ext.data.JsonStore?

Do other people have thoughts on centralizing this information in our application? I don't
it would be that hard or a ton of time.

Sorry for the long email....

Ivan.

--

Ivan Willig
OpenGeo - http://opengeo.org

[Ivan Willig]

Sorry,

Just for a little context I bring this up because last week I was trying to merge  the functionality of the map properties widget and the metadata widget. I found this process hard because of the above mentioned issues.

[Andreas Hocevar]

Hey Ivan,

I'll try to reply. See responses inline.

On Tue, Apr 16, 2013 at 6:11 PM, Ivan Willig <iwi...@opengeo.org> wrote:
> I have a couple of questions about geoexplorer and gxp,
> maybe not be important to a lot of people.
>
> I notice that we currently store some of the gxp tools as
> configuration objects in the geonode database. For what I understand
> the reason for doing this is to allow for these tools to be
> configurable across different mapping applications. Is that correct?

In plain GeoExplorer (i.e. without GeoNode), the whole configuration
is stored in a SQLite database. Configurations in a gxp.Viewer
instance are serialized with viewer.getState(), which calls getState()
on each tool and builds a JavaScript object. GeoExplorer has two
frontends: the Composer and the Viewer. The gxp.Viewer's loadConfig
method can be overridden to asynchronously load configuration, and to
strip out tools from the configuration that are not needed.

> I just bring this up because it seems like we are storing map
> configuration properties in the tool json config as well. Like the
> following,
>
> https://gist.github.com/iwillig/797f33eb88ea8e4d6f0a#file-gistfile1-json-L71-L76

You are right, some of these properties do not belong there. The
reason for this particular piece of configuration (if I remember
correctly) is that when the MapProperties tool was introduced, an
empty base layer that defines the map defaults was also introduced,
but was initially not created by the gxp.Viewer, but by the
MapProperties tool.

> The map properties widget allows users to modify three properties and as
> it turns out, also takes care of storing these proprieties in the
> database. This widget also manages modifying the map object when this
> widget added to the application.
>
> I think this combining the tool with the state it manages makes this
> code hard to work with. For example because the state management is
> done in the widget, one would have to do a lot of code copying in
> order to allow users to modify the background color with a different
> widget.

Right. To change that, the empty base layer needs to be made part of
gxp.Viewer, instead of maintaining it with the MapProperties tool.

> I feel that we have important state that effects the running of the
> GeoExplorer application hidden away in these tool objects.

You are absolutely right. There is nothing wrong about tools having
state though, it's only that if a state affects the map, it should be
part on the gxp.Viewer state.

> Its seems like one thing we could do is to move this information into
> the map configuration object itself. Centralized all core state
> management into a single location and provide an api for modifying
> this information. This would allow the tools/widgets to talk to the
> map config object in a uniform way. Less coping of code in order to
> build different interfaces.

Agreed.

> One place were this might help is the metadata widget.

That widget does not store map properties in its own state though :-).

>
> the save method,
>
> https://github.com/opengeo/geonode/blob/mapstory/src/geonode-client/app/static/script/app/GeoExplorer.js#L937
>
> and the save as method,
>
> https://github.com/opengeo/geonode/blob/mapstory/src/geonode-client/app/static/script/app/GeoExplorer.js#L948
>
> These are very similar.
>
> Maybe the api could look something like,
>
> this.mapAttributes.set('title', 'This is a great map');
> or
> this.mapAttributes.get('title');

The save and saveAs methods would still be very similar, and whether
you have viewer.config or viewer.mapAttributes does not make much of a
difference. I do see the benefit of having a setter method though.
Widgets could listen to changes in an MVC manner this way.

> I am sure that Ext.js has something for this type of code. Could we use
> something like
> http://docs.sencha.com/extjs/3.4.0/#!/api/Ext.data.JsonStore?

This could be done, yes. But the flat structure also raises other
questions: what belongs in the map configuration (i.e. what becomes
part of the gxp.MapPanel instance)? What belongs in the viewer
configuration? What belongs in the layer configuration?

> Do other people have thoughts on centralizing this information in our
> application? I don't
> it would be that hard or a ton of time.

The one thing to keep in mind is backwards compatibility for our
exiting users and applications. If you can ensure that, I'd not be
opposed to your suggested changes. I'm just not sure if it's worth the
effort, as for now we don't really have a future path for gxp.

Andreas.

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