Comments (6)
That's more responsibility for the application developer but that sounds good to me.
from ol2.
I think more interesting to follow the current requirements, but allows to build compressed code as proposed in http://trac.osgeo.org/openlayers/ticket/3496
This is what I use in production, e.g. to remove required features as OpenLayers/Tween.js
in maps without controls
(But the programmer must ensure that the resulting code works e.g. without Tween
currently it requires a dummy as OpenLayers.Easing={Expo:{easeOut:null}};
)
from ol2.
I think I would distinguish between 'real' requires (meaning, code won't function without it) and 'optiional' requires (code will function ok as long as you don't try and use a function that needs that class). I think the requires instructions for the build program should be limited to the former - stuff that really is required. The formats are clearly the latter case - if you only have point data, there is no requirement for LineString, Polygon etc: the code works perfectly well without them. I think the optional requires should be written up in the docs, so people know what to include in their build config.
There are quite a few inconsistencies at present, for example, with the Formats, WKT has no requires of geometries at all. I would propose standardising this, to the lowest common denominator.
from ol2.
Yes I agree (sometimes I think too much in the inexperienced user, sorry, is best to minimize @requires
, but ticket/3496 is designed for the experienced user)
To fix some inconsistencies would be nice to have the clause @include
as in jstools
(e.g. OpenLayers/BaseTypes/Bounds.js
fails without OpenLayers/Utils.js
, but do not have @requires OpenLayers/Utils.js
to avoid circular requires, and more... I'm not OpenLayers team and I can do little in this way, sorry)
In WKT did not requires geometries to avoid a circular inclusion, because geometry requires WKT. I think currently (after SHA: 66de55e) it should be added @requires OpenLayers/Geometry/Point.js
in WKT
from ol2.
hm, I'm no longer so sure about this. I realised when changing Format/KML that you don't necessarily know at build time what geometries are going to be needed, for example if you're reading someone else's data - even if you're only interested in the point data in, say, a kml file, if the file contains other geometry types the read will fail. You could put in checks for each geometry type whether the actual class is present, but that seems more trouble than it's worth.
So perhaps it's better to leave the geometry requires in there as the default and use the excludes section for those situations when you know you are only dealing with particular geometries (or, of course, don't use the build system :-) ).
from ol2.
ok, as 'excludes' works well, I've convinced myself that it's better to stick with the existing situation.
Issue closed
from ol2.
Related Issues (20)
- Maps do not pan in Chrome 55 or Microsoft Edge HOT 2
- implement openlayers with bing offline server
- Featureclick eventListeners randomly not work on chrome 51 HOT 1
- Get OpenLayers from packagist
- Clojure Compiler Link is dead
- Scroll bar does not show in Popup.FramedCloud in mobile devices (OL 2.13.1) HOT 3
- Need to add set style feature to Google Layer HOT 1
- OpenStreetMap newly redirecting tile URLs. Problem on safari HOT 1
- Incorrect Web Mercator transforms with newest versions of proj4js
- Map extent is increased after setting base layer
- How to Convert Circle Polygon Geometry to Line in openlayers 2 HOT 1
- Snapping another layer point with Create Circle Polygon in Openlayers 2
- how to show a arrow feature by some longitude
- Ping (ICMP) send during Layer/Map request
- Image getting stretched in Image layer
- How to Change style of point feature to polygon?
- Open source License obligations of openlayers-2.13.1 HOT 3
- Responsible disclosure policy
- Dev.openlayers.org is gone HOT 10
- Google Map Layers not rendering anymore HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from ol2.