search

yourcelf / olwidget

Javascript library to replace textareas that contain WKT data with editable OpenLayers maps, and a django app using it for django forms and admin.
Other
91 stars 43 forks source link

Docs: map_options keys get munged, but docs say they get passed directly #61

Closed slinkp closed 13 years ago

slinkp commented 13 years ago

At http://olwidget.org/olwidget/v0.4/doc/django-olwidget.html#options it says "Any additional parameters available to the OpenLayers.Map.Constructor may be included, and will be passed directly."

They don't actually get passed directly; they get translated from lowercase_with_underscores to camelCaseWithInitialLowercase. That's a bit confusing (and it's not obvious to me why lowercase_with_underscores needs to be supported here anyway).

yourcelf commented 13 years ago

It's true they are munged. It's due to this discussion. Basically, the javascript library (olwidget.js) works with and extends OpenLayers classes, which use camelCaseWithInitialLowercase by convention for options and parameters. Django uses PEP8, which requires lowercase_with_underscores. So is it better to violate Django's convention, violate OpenLayers' convention, or to support both? Olwidget is intended to work both inside and outside of Django.

But you're right; this should be clarified in the docs.

slinkp commented 13 years ago

Hmm, i see. I read the linked discussion. I'm not sure they really got what you were talking about: these are never Python identifiers at all, they're just dictionary keys on the Python side - so I don't see how PEP 8 applies.

But I noticed that the converter leaves camelCase names alone, so I can just write them whichever way I want :) I do think it creates a mismatch in the docs though.

yourcelf commented 13 years ago

I've updated the docs for this. I think at this point it's not worth changing the case_munging; as it would be pretty backwards incompatible, and the complexity saved isn't that much.