geoadmin/mf-next — pull request #12 by gjn (2013-03-27 15:51:44+00:00)
Title: Replace @export flag mechanism with ol3 export mechanisms

For this, we are using the existing ol3 script generate-exports. For an
introduction regarding exports in ol3 (and from now on in geoadmin),
please read https://github.com/openlayers/ol3/wiki/Exports-Files

The change was made to be more consistent with ol3 as well as being able
to create customized builds (include/export only the things that need to
be included/exported).

Anyhow, there are still some things needing discussion and decision:
1. Nothing of the ol3 namespace is exported right now. If we want to
export ol3 stuff, we need to define what (we can export everything or
only specific stuff). It's all about size.
2. We don't have object literals exports right now. The ol3 way is to
export parameters for constructors as object literals. We don't as of
now. If we do, we have to decide how to do it if the object literal is
'derived' from existing ol3 object literal (e.g. ga.MapOptions could be
derived from ol.MapOptions)
3. We don't use type checking in the compiler yet. ol3 build system is
using it, especially for Options object literals. We have to decide if
we want the same.
4. It's unclear if ol3 export mechanisms supports
overloading/overwriting of existing functions from the library from the
outside.
5. We don't use closure linter yet. I didn't yet analyse what the
additional benefit would be in addition to jshint.
6. It took me a full day to comprehend the system in such way as to make it
all work in our environment. You can break things easily, and if they
are broken, it's hard to track down the reason. It's the first time I
have my doubts to jump through all these hoops just to save a maximum of
x00KB of payload, especially in a web application which quickly loads
additional data (tiles) that is a multitude of what we can save. I like
the technical challenge though.
6. I'm sure there are other open points...