Improve Build System to Account of User Widget Inclusion

[theduckylittle]

The built-in distributed JS works if you are okay with the current widget set. If all you want is a custom dialog with buttons and layouts, etc. etc., its fine since those widgets are all included and you're basically writing a new combination of those elements.

It's when a widget, like DataGrid, is missing that errors are occuring.

This needs to be addressed in a useful fashion.

I think we would need to document the creation of a "local_includes.js" file. And then account for that in the build system.

Jim also suggested that all extensions use the "local_includes.js" file and we remove the need to edit the HTML.

[theduckylittle]

r932

[theduckylittle]

Someone will need to doc this better but here goes something.

There is a new directory htdocs/site. Inside of htdocs/site it is possible to add includes that will be used with the build system.

1. Create htdocs/site/includes.js. In that file add something like this:

   dojo.require('dojox.grid.DataGrid');
   

2. Goto htdocs/libs/dojo-1.6.1/util/buildscripts.
3. Run:

   ./build_geomoose2.sh
   

4. Win?

[jimk]

Fixed geomoose_dev.html for paths and include site/includes.js too. r935, r936

[jimk]

There are a few options for extensions now. Old GeoMoose.UX extensions should be fine so long as they don't use dojo. New extensions (using dojo) have a two options for implementation. The preferred method is to include the extension in site/includes.js (as an admin configurable file to enable the extension) and rebuild GeoMoose. This means the extension will end up as part of the build and it will run quickest.

Alternatively, you can add the dojo.require's that the extension needs and add the extension as a <script src="..."> tag in the HTML. This is more cumbersome, but insures that the modules the extension needs are available. Personally, I think this method may be ok for development (GeoMoose compiled, extension not), but isn't really suitable for production use.

Extension boilerplate now looks like

In htdocs/extensions/MyExtension.js

dojo.require("extensions.MyExtension.tab");

dojo.provide("extensions.MyExtension");
dojo.declare('MyExtension', null, {
    // Executed when GeoMOOSE is starting after UI loaded, before Mapbook loaded.
    load: function() {
        // Or whatever else you need to do to startup...
        this.tab = new extensions.MyExtension.tab();
        GeoMOOSE.addTab('my_extension_tab', this.tab);
    }
});

GeoMOOSE.UX.register('MyExtension', MyExtension);

There is a bug right now where the "main" extension class does not use the "extensions." namespace. (If you use extensions.MyExtension as the class name (and update the register line), the extension hides all the sub-namespaced items such as extensions.MyExtension.tab.) The idea is the bulk of the extension code, templates, themes (CSS) live in a directory with the extensions name. (e.g. htdocs/extensions/MyExtension/tab.js, htdocs/extensions/MyExtension/templates/tab.html, htdocs/extensions/MyExtension/themes/tundra/tab.css)

Then creating (or adding to htdocs/site/includes.js)

dojo.require('extensions.MyExtension');

This causes dojo to look for htdocs/extensions/MyExtension.js to load the extensions.MyExtension.js class. Of course, due to the bug above, this class doesn't exist, but nothing seems to mind. Also, as MyExtension.js is executed in place on load, the last line that registers the extension to be called at load time still works. Ideally, I would like to see this registration replaced by a publish/subscribe event model for a onStartup type event (after dojo.onLoad is done (which creates the UI) and before the mapbook fetch is attempted).

For extension configuration by the mapbook there are a couple of options. (1) parse the mapbook and look for tags on layers, etc. (2) look for (add to) the global CONFIGURATION parameters. To implement the latter, I did the following:

dojo.declare('extensions.MyExtension.tab', [GeoMOOSE.Tab, dijit._Widget, dijit._Templated], {
    title: 'My Extension', /* GeoMOOSE.Tab */

    templateString: dojo.cache("extensions.MyExtension", "templates/tab.html"),
    widgetsInTemplate: true, // makes propertyNode, et. al. JS objects instead of DOMNodes

    // Default configuration
    config: {
        csw_url: "/geonetwork/srv/eng/csw",
        templates: {
            metadata_url: "/geonetwork/srv/eng/metadata.show?uuid=%uuid%&currTab=simple",
            wms_base_url: "/cgi-bin/wms.rb?uuid=%uuid%&"
        }
    },

    query: null,
    store: null,
    grid: null,

    constructor: function() {
        this.inherited(arguments);

        // Create elements in CONFIGURATION for mapbook based config.
        // TODO: problem --- can't have two csw tabs!
        // Should this be passed into the constructor instead?
        if(CONFIGURATION) {
            if(!CONFIGURATION['extensions'])
                CONFIGURATION['extensions'] = {};
            if(!CONFIGURATION.extensions['MyExtension'])
                CONFIGURATION.extensions['MyExtension'] = this.config; // BY REF!
        }
    },

  …
});

Which adds extensions.MyExtensions.csw_url et.al. as parameters that can be set with a <param name="extensions.MyExtensions.csw_url">Value</param> in the mapbook.

[sheppard]

These changes look like a good approach. The addition of the site folder seems promising - would we go further and propose that most/all interface customizations (including custom extension code) go there? It might make upgrading quite a bit easier...

I ended up using the CONFIGURATION approach as well:
​http://osgeo-org.1560.n6.nabble.com/Geomoose-users-standard-extension-configuration-tt4987696.html
and an example:
​http://trac.osgeo.org/geomoose/browser/geomoose2/trunk/htdocs/extensions/BasemapButtons.js

Since the extension naming scheme already provides a high probability of uniqueness, I opted to go without the 'extension' namespace in the configuration for the sake of simplicity - what do you think?

Also for the sake of simplicity, I'm thinking it would make sense to have custom extensions define the default configuration right after the extension is declared (as in BasemapButtons), rather than in the constructor. Or is there a reason the constructor approach would be preferred?

(In the future, we should also take a look at the module.config() API which is provided in the latest AMD implementations.)

[bfischer]

moved to ​https://github.com/geomoose/geomoose/issues/9