Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make ol.control.Control extends ol.Object #800

Merged
merged 4 commits into from Jun 21, 2013

Conversation

fredj
Copy link
Member

@fredj fredj commented Jun 20, 2013

As suggested by @twpayne in #688 (comment), make the controls extends ol.Object instead of goog.Disposable.

@twpayne
Copy link
Contributor

twpayne commented Jun 20, 2013

Nice. I like what you're doing with this :)

* @inheritDoc
*/
ol.control.ScaleLine.prototype.handleMapPostrender = function(mapEvent) {
this.updateElement_(mapEvent.frameState);
this.frameState_ = mapEvent.frameState;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm a bit unsure with storing the frameState in the instance, and reusing it later when handleUnitsChanged_ is called.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because we have to call this.updateElement_() when the units changed but we don't have a frameState at this moment.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good points both. I would be tempted just to store the values from frameState that we need in this.updateElement_().

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know. I just don't like the idea of storing the frameState in the instance. A frameState is a volatile object that has a meaning within its frame only.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good points both. I would be tempted just to store the values from frameState that we need in this.updateElement_().

Which means center, resolution and projection. We can maybe store the entire view2DState object. I'm probably a bit pedantic here, but storing the "frame state" for use outside a "frame" bothers me :)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point; storing the view2DState (or a subset) is perfectly fine (and much more logical).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1 on view2DState. Good idea.

@fredj
Copy link
Member Author

fredj commented Jun 20, 2013

ready for review, thanks.

}, false);
var projection = new ol.dom.Input(document.getElementById('projection'));
projection.on('change:value', function() {
control.setProjection(ol.proj.get(this.getValue()));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Using projection rather than this here would be more explicit.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

good point, fixed (also for precision)

@elemoine
Copy link
Member

I also like this.

goog.require('ol.layer.TileLayer');
goog.require('ol.source.OSM');


var control = new ol.control.ScaleLine();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd rename control to scaleLineControl to make the following code a little clearer.

@twpayne
Copy link
Contributor

twpayne commented Jun 20, 2013

A couple of minor comments, but otherwise this looks VGTM.

fredj added a commit that referenced this pull request Jun 21, 2013
Make ol.control.Control extends ol.Object
@fredj fredj merged commit f83fe42 into openlayers:master Jun 21, 2013
@fredj fredj deleted the control_object branch June 21, 2013 05:44
afabiani pushed a commit to geosolutions-it/openlayers that referenced this pull request May 22, 2017
Use GPU where available; animated zooming. r=@elemoine
afabiani pushed a commit to geosolutions-it/openlayers that referenced this pull request May 22, 2017
With the map's applyTransform method, the control does not need and have
its own applyTransform and center management any more.
afabiani pushed a commit to geosolutions-it/openlayers that referenced this pull request May 22, 2017
This still doesn't address the broken ZoomBox test (see openlayers#800), it fails in the same way with or without this change.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants