On Thu, Nov 22, 2007 at 10:31:12AM +0100, Andreas Hocevar wrote: > Hi, > > On Nov 21, 2007 9:31 PM, OpenLayers <[EMAIL PROTECTED]> 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 _______________________________________________ Dev mailing list [email protected] http://openlayers.org/mailman/listinfo/dev
