Hi,

Thanks for explanation. I think your reasoning make sense. 

Cheers
Kamil Gałuszka

On Monday, May 27, 2013 10:48:35 AM UTC+2, Claude Paroz wrote:
>
>
>
> Le lundi 27 mai 2013 07:38:54 UTC+2, Carl Meyer a écrit :
>>
>> Hi Kamil, 
>>
>> On 05/26/2013 05:39 PM, Kamil Gałuszka wrote: 
>> > Hi Django developers! 
>> >   
>> > This is my first time here posting, so if I'm wrong please forgive me 
>> :) 
>> > I wanna learn as much as possible about django development process from 
>> > you guys! 
>> > Thank you all for inspiring time on DjangoCon.eu sprints ! 
>> > 
>> > I'm writing because I'm concerned about OpenLayers that are used in 
>> > django.contrib.gis.admin. For now JS of OpenLayers is shipped with 
>> > external url from openlayers hosting. 
>> > 
>> > There are some drawback of this situation and it's causing bugs in 
>> > specific circumstances. For example if you are using Chrome browser and 
>> > your website is using https all non https javascript are blocked by 
>> > default. So widget in django admin isn't rendering and it's broken (I 
>> > think that should be considered as a bug and possibility of security 
>> > problems if someone switch openlayer.js on external hosting). 
>> > 
>> > I think the best approach to that problem is that we should ship 
>> > OpenLayer.js in Django statics. OpenLayers documentation is encouraging 
>> > to ship in applications own builds of this library. To read more: 
>> > http://docs.openlayers.org/library/deploying.html 
>> > 
>> > I have question is this approach good for Django (to actually compile 
>> > own build of OpenLayer and ship it in statics) and is this change can 
>> be 
>> > possible place of breaking something with backward compatibility. 
>> > 
>> > Things in my mind to consider: 
>> > 1) With every next Django release I think there should be building of 
>> > most actual OL. 
>> > 2) Shipping OL actually should be optional and documented in docs. 
>> > 
>> > If there isn't any problem with that approach I'm ready to implement 
>> this. 
>>
>> I'm not familiar with any history in this area (so I'll defer to anyone 
>> who knows a good reason why we do it the way we do), but it makes sense 
>> to me that it would be better to ship an OpenLayers.js build than link 
>> to it externally, for security and reliability reasons. 
>>
>
> I was not there at the time of this design decision either, however I can 
> imagine that including a lib weighing more than 700 Ko in every Django 
> release just for a contrib app is not something to be taken lightly.
>
> Note that Django 1.6 will introduce some new template-based widgets for 
> GeoDjango, so changing the OpenLayers source is as simple as subclassing 
> the new BaseGeometryWidget and redefining its Media class.
>
> Claude
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.


Reply via email to