[OpenLayers-Dev] [OpenLayers-Trac] [OpenLayers] #1059: Mark drawFeature(..) as stable

Christopher Schmidt crschmidt at metacarta.com
Thu Nov 22 07:24:17 EST 2007

On Thu, Nov 22, 2007 at 10:31:12AM +0100, Andreas Hocevar wrote:
> Hi,
> On Nov 21, 2007 9:31 PM, OpenLayers <trac at openlayers.org> wrote:
> >  (In [5244]) Mark drawFeature as stable (Closes #1059)
> I would reconsider that, especially since no one has obviously taken
> notice of my posting a few days ago
> (http://www.nabble.com/Features,-Styling-and-Rendering-t4823880.html).

I had read the post: my understanding is that your post was addressing
renderer.drawFeature. Sorry that I didn't fully read and understand
before now.

However, I think that if we do go the route you have suggested: that is,
passing a 'key' into drawFeature instead of a style object, we should
*still* maintain the existing capability. Determining whether we were
passed a key or an object is easy (typeof style == "string"), and I have
no problems *extending* the existing API once we have it.

So, I think that breaking the current behavior would be wrong at this
point: too many users are already using it, whether it was documented
that way or not, and we should ensure we d on't break it. So, with your
posting in mind, I think it is even more important to mark it as an API
method, since it is already in use that way, so we on't break it.

> After some discussion with Tim, I tried to figure out a way on how to
> work with kml style maps in the future. I came up with the idea that
> drawFeature have a style as second parameter, but a renderIntent,
> which would be the key of a style map. In the above posting I also
> discribed the advantages of this approach.

Yes, I see the value here, and I think that can be extended onto the API
method that I'd like to continue to support. 

> By marking drawFeature as stable, you are taking away the opportunity
> to get this done prior to 3.0.

I disagree: we just have to be more cautious :) Extensions of the API
are fine, and I think that this one is a cost we should be prepared to
take on. If it becomes a problem, I'll help accomodate for it in your

Christopher Schmidt

More information about the Dev mailing list