I like to see this changes, but may be we need more, I think it's the time to move the indexOf and toFloat methods from Util to base types. For backward compatibility, we let OpenLayers.Util.indexOf link to OpenLayers.Array.indexOf
Li XinGang EMail: [email protected] Blog: avlee.cnblogs.com Site: www.mapboost.org On Thu, Jan 6, 2011 at 5:03 AM, Tim Schaub <[email protected]> wrote: > So I've made changes in the trunk to simplify build configurations. > > http://trac.osgeo.org/openlayers/changeset/11006/ > > This allows for circular dependencies (imposing an arbitrary sort order). > Then I changed things to break the one circular dependency that we have > that cannot be resolved with an arbitrary sort order. > > http://trac.osgeo.org/openlayers/changeset/11003/ > > The result is that dependencies can now be entirely declared within the > library (and, in the future, in your application code). > > As a consequence, people using custom build profiles will likely want to > remove the "first" section from their configuration files. > > E.g. http://trac.osgeo.org/openlayers/changeset/11008 > > Hope that makes sense, > Tim > > > On 1/1/11 4:34 PM, Tim Schaub wrote: > >> Hey- >> >> I'd like to make it easier to correctly build custom profiles of the >> library. One restriction that we currently face is that our toposort >> method is unnecessarily strict with regard to circular dependencies. >> With a more tolerant toposort, we could safely declare more dependencies >> in our source files (where they belong) instead of in configuration files. >> >> One current circular dependency that will not be satisfied with an >> arbitrary sort order is the Class -> Util -> BaseTypes -> Class loop. >> Our Class function really only requires the extend method from Util. If >> we define the extend method in the Class.js file, then things can be >> resolved properly. >> >> I've made changes in a sandbox that include a simplified & more tolerant >> topological sort [1], extend in Class instead of Util [2], and proper >> dependency declarations in the source comments. This results in simpler >> build configuration files [3] (closer to something that could be handled >> by @require comments in an application file instead of a separate build >> configuration file). >> >> I've put up a patch that moves the extend method into Class.js [4]. I >> thought this one deserved review & input. All the other changes are >> comments only or changes in the build tools. >> >> Thanks for any feedback, >> Tim >> >> >> [1] http://trac.osgeo.org/openlayers/changeset/10979/ >> >> [2] http://trac.osgeo.org/openlayers/changeset/10982/ >> >> [3] >> >> http://trac.osgeo.org/openlayers/browser/sandbox/tschaub/uncircular/build/lite.cfg >> >> >> [4] http://trac.osgeo.org/openlayers/ticket/2992 >> >> > > -- > Tim Schaub > OpenGeo - http://opengeo.org > Expert service straight from the developers. > _______________________________________________ > Dev mailing list > [email protected] > http://lists.osgeo.org/mailman/listinfo/openlayers-dev >
_______________________________________________ Dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/openlayers-dev
