This commit extends the generated Export constructors to support nested options objects. For example, this is now supported:
@exportObjectLiteralProperty ol.MapOptions.view ol.View|ol.View2DOptions|undefined
This specifies that the "view" property in the map options can reference an ol.View instance, an ol.View2DOptions literal object, or undefined. If the "view" property references an ol.View2DOptions literal object the ol.MapExport constructor will create an ol.View2DExport instance, and pass it to the parent constructor, ol.Map. In this way, extern types never cross the external/internal boundary. In other words, translations from non-renamed to renamed objects remain confined to the generated Export constructors.
We have constructors, like ol.View2D and ol.control.Attribution, whose "options" argument is optional (opt_options). But currently, we cannot do "new ol.View2D()" in uncompiled code that uses an ol3 build compiled in advanced mode. This commit fixes that by changing the generated Export constructors.
This is a workaround for our check-example.js PhantomJS script to work with this example. Without this check-example.js fails because xhr.status is 0. I tried to give the explicit file:/// scheme as indicated in https://groups.google.com/d/msg/phantomjs/wFGme0pE-Tk/WUjU5s-27NwJ, but that didn't work for me.
As more and more examples will be processed with this script, the
progresbar would grow way too long. This commit makes the width of
the bar fixed. Every character in the bar now equals 5% progress,
regardless of the number of examples.
When opening an example through the `file:`-protocol, e.g.
`file:///ol3/examples/full-screen.html` our `loader.js` would inject
a `<script>` tag with a `src` pointing to an illegal URL
`http://:9810/compile?mode=ADVANCED&id=full-screen`.
This changes the respective logic, so that in the case that we are accessed
through the `file:`-protocol, we fallback to using `localhost` as hostname
for the plovr-compiler.
The examples that do not use XHR (like e.g. `wms-capabilities.html`) now
work as expected when accessed through `file:`-protocol.
Take this example:
```
goog.require('ol.projection.addCommonProjections');
ol.projection.addCommonProjections();
```
Without this patch, the build_check_requires_timestamp target would report
that ``ol.projection`` is missing.
This is because ``ol.projection.addCommonProjections();`` would match both
``ol.projection.addCommonProjections and ``ol.projection`` provide
directives.
