On 28 mar, 20:58, Justin Bronn wrote:
> I see what you're talking about now, and I agree it's a bug. Please
> open up a ticket and we'll consider the design decisions there.
> Thanks for the clarification.
I did just that, it's ticket #10660: http://code.djangoproject.com/ticket/10660
I don't
> I hope I made myself clearer this time. Opinions please? If this
> should be fixed, and I seriously think it must, I'll open a ticket and
> attach a patch.
I see what you're talking about now, and I agree it's a bug. Please
open up a ticket and we'll consider the design decisions there.
Thanks
On 27 mar, 19:49, Justin Bronn wrote:
> Isn't the checking of `self.null` that you've identified as the
> problem already in the `GeometryField.clean` method? Are you
> proposing a recursive call?
>
> I agree that GeometryField is ripe to be improved -- but I'm unclear
> on exactly what is the p
On Mar 25, 12:20 pm, Fidel Ramos wrote:
> My proposed solution would be to call Field's clean() instead of
> checking self.null.
Isn't the checking of `self.null` that you've identified as the
problem already in the `GeometryField.clean` method? Are you
proposing a recursive call?
I agree th
django.contrib.gis.forms.fields.GeometryField completely ignores the
required attribute in its clean() method. Instead it checks if the
model field is nullable, which needlessly ties forms and model code. I
realized this because I have a model with a non-nullable GeometryField
but need a non-requi
