[OpenLayers-Dev] library size & advanced geometry functions

Christopher Schmidt crschmidt at metacarta.com
Thu Feb 5 14:22:06 EST 2009


On Thu, Feb 05, 2009 at 12:03:35PM -0700, Tim Schaub wrote:
> Hey-
> 
> So, users can currently control the size of their library build with a 
> custom build profile.  This works well when there are entire classes 
> that are not needed in an application.
> 
> In the case of geometries, there is a good bit of functionality that 
> could be added.  I originally considered a separate library that would 
> extend OpenLayers geometries with more advanced functionality.  This 
> would keep the OpenLayers builds small and give more functionality just 
> to those who wanted it.
> 
> I also know that a whole lot more people would get the opportunity to 
> use the functionality if it were part of OpenLayers.  I like the 
> convention of keeping all extensions to our constructor prototypes in a 
> single file.  However, it is not strictly necessary.  On option for 
> adding functionality that could be excluded from a custom build would be 
> to have additional files that extended the geometry prototypes.
> 
> What do others think?  

I don't have any problem with this, but I do sort of wonder if there
isn't an amount of diminishing return with regard to smaller OpenLayers.js
files -- for most users, our library is no bigger than a handful of
tiles anyway, so users would get a lot more benefit out of just
configuring their application to have 'buffer: 0' on WMS layers than
they would from further work on making our core library smaller...

One nice thing about the existing setup is that building a custom
profile is pretty easy: look for any place in your code that says 'new',
take the classname after it, and include the file that contains that
class in your build profile. Everything else should be handled for you
(with a few exceptions, like renderers).

> 1) Keep piling code into the same geometry files.

I don't see a major problem with this.

> 2) Stop piling code into the geometry files, and go with the separate 
> library idea.

I like this one more than 3).

> 3) Put the stuff in separate files (GeometryEx/ or something).

I wouldn't be against this if others prefer it.  

Regards,
-- 
Christopher Schmidt
MetaCarta



More information about the Dev mailing list