Support both ExtJS 4.2.1 and ExtJS 5.1.0

[marcjansen]

This PR makes GeoExt ready for working atop of ExtJS 4.2.1 or (at your choice) ExtJS 5.1.0.

The commit history is IMHO a little cleaner than the one of #274, but still it is a lot to review.

I'd be very glad if e.g. @bartvde, @chrismayer, @weskamm, @KaiVolland, @buehner, @dnlkoch, @bentrm, @hutzelknecht, @bjornharrtell, @annarieger & @juliensam had a look at the changes introduced here. Everybody else is invited to test this as well, of course. If you have any comments, just leave them in this PR.

This PR contains commits by @chrismayer, @KaiVolland and me. Thanks to everyone that was involved.

I will try to make reviewing this a little bit easier by giving some facts that possible reviewers may double check:

• All examples work with ExtJS 4.2.1 and ExtJS 5.1.0
• Testsuite passes in IEs (just now I only know about v11, other versions very much appreciated)
• Testsuite passes in recent Chrome
• Testsuite passes in recent Firefox
• Headless Testsuite passes as well

Some main changes, which may need another pair of eyes

• All examples now use ExtJS 5.1.0 as default
• All examples can be run on top of ExtJS 4.2.1 by appending ?extjs=4.2.1
• All examples should look fine with every theme (Use the switcher in the top-right corner to change the theme). Also note that the number of available themes varies dependent on the ExtJS version (4 vs. 6)
• The tests can now be run on top of ExtJS 4.2.1 or ExtJS 5.1.0
  • Both the headless testsuite and the one running in an actual browser run all tests on both versions of ExtJS
  • effectively this doubled the number of tests that are run each time, so a little patience is needed.

Specific changes that were needed:

• Two new boolean flags are introduced: GeoExt.isExt4 and its counterpart GeoExt.isExt5 for those parts where we need different code paths depending on the ExtJS version.
• We no longer use addEvents internally, but we only declare our events by documenting them, see e.g. src/GeoExt/FeatureRenderer.js
• We no longer use removeAllListeners, but instead use clearListeners
• Internal event handlers on stores, that listen to e.g. the remove event, now can handle both the case when they are called with a single record (ExtJS 4) and where they are called with an array of records (ExtJS 5). See e.g. GeoExt.container.VectorLegend
• When we need to get the raw data of a record, we need to access under a different key depending on the ExtJS version. The name can be obtain like this: GeoExt.isExt4 ? 'raw' : 'data'; See e.g. src/GeoExt/data/FeatureStore.js
• Stores do no longer define (and in ExtJS 5 override) a method bind. Instead more distinguishable names have been chosen. See e.g. src/GeoExt/data/LayerStore.js
• The loadRawData method has different code paths for ExtJS 4 and 5. See e.g. src/GeoExt/data/LayerStore.js
• We now more often use the setters of properties, as these a re supported in both ext versions, and the direct access of properties fails often in ExtJS 5. See e.g. src/GeoExt/data/OwsStore.js
• Our readRecords method (e.g. of the readers) now checks whether it gets called multiple times when the records already have been read and poscessed. See e.g. src/GeoExt/data/reader/Attribute.js

Other parts which may need special attention:

• src/GeoExt/data/FeatureStore.js see the comment in line 360ff
• src/GeoExt/data/LayerStore.js see the comment in line 168ff
• src/GeoExt/data/proxy/Protocol.js see the comment in line 58ff This should possibly have a follow up ticket. The same goes for src/GeoExt/data/reader/Attribute.js line 106ff. Where a similar handling is done
• src/GeoExt/data/reader/Feature.js the logic changed how we extract the record and create accesor.

Other TODOs:

• The app example has not been touched and is only working on top of ExtJS 4. We can do that later.
• There is duplicated code in src/GeoExt/data/LayerTreeModel.js & src/GeoExt/container/WmsLegend.js which we want to have at one place. We can do this later.
• src/GeoExt/data/VectorStyleModel.js has the logic of Version.js partly copyied. See line 62ff. We should check this again later.

Again: It won't be easy to review this, but any feedback is very helpful.

Once we have this in master, we can start thinking about cooking a v2.1.0-alpha.1.

[marcjansen]

The testsuite is all green in Chrome 33, Firefox 35 and IE 11; plus we have a passing travis build.

This will now be refactored by me to have a saner commit hierarchy.

[marcjansen]

That's what an alpha release ultimately is about.

Agreed ...

... we can avoid larger problems which might upset other app-devs or users

... Agreed as well 😉

[chrismayer]

I just tested two of my productive applications which are more or less complex. Everything seems to be working.

[dnlkoch]

I tested one of our main and most complex application as well and everything seems to be working as expected.

[marcjansen]

👍 @chrismayer

👍 @dnlkoch

So great.

I'd love to have a feedback from @bartvde, and hope he has some time for this.

[bjornharrtell]

@marcjansen, I've tested it with the application I mentioned and I cannot find any regressions.

[chrismayer]

Hi @bjornharrtell,
very cool, thanks a lot! Seems things are getting closer to the end.

[marcjansen]

Sounds good indeed, I pinged @bartvde, he'll have a look right now

[bartvde]

What were the modifications and why were they needed?

[marcjansen]

They were minor:

• support query parameter 'extjs'
• default to 'neptune' theme, as this one exists in both v4 and v5
• load the debug-variants of the resources

I'll add a commit explaining the differences.

[bartvde]

nice and solid work, please merge when you get a chance to address my minor remarks

[marcjansen]

I added some commits addressing all the comments of @bartvde. I will merge this once travis is happy.

[marcjansen]

Again: Thanks a lot to al those involved in this massive change! Will merge now.