[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
developments.
Regards,
--
Christopher Schmidt
MetaCarta
More information about the Dev
mailing list