Geometry cleaning confusion

[Paul Winkler]

I'm using django-olwidget and trying rig up a subclass of
GeoModelAdmin that by default uses a different FormField subclass
(which in turn would use a different default Widget subclass).

This is proving... rather difficult :-\

The current stumbling block is that I'm looking at the django-olwidget
code and I'm a bit baffled at when/how anything ever gets turned into
a geometry.

AFAICT the only way it happens is when GeoModelAdmin or MapModelForm
uses metaclass magic to invoke
apply_maps_to_modelform_fields(), which finds underlying
GeometryFields and clobbers their widgets with EditableLayer. I want
to use a different widget, so I can't just call that.

That seems to be crucial: the WKT -> geometry transformation happens
only in contrib.gis.forms.fields.GeometryField.clean().
And the olwidget Field subclasses don't inherit from GeometryField
(why not?).

Unless I'm missing something - which is likely - this makes it non-
obvious how to use the fields and widgets of django-olwidget without
using MapModelForm and/or GeoModelAdmin.

Does anybody use them that way?

[Charlie DeTar]

On 05/27/2011 05:41 PM, Paul Winkler wrote:
> I'm using django-olwidget and trying rig up a subclass of
> GeoModelAdmin that by default uses a different FormField subclass
> (which in turn would use a different default Widget subclass).

Have you looked at the examples in the included `test_project`? The top
of admin.py:

https://github.com/yourcelf/olwidget/blob/master/django-olwidget/test_project/testolwidget/admin.py

Does this do what you want it to? `TestAdminForm` is customized plain
ModelForm used with GeoModelAdmin.

> That seems to be crucial: the WKT -> geometry transformation happens
> only in contrib.gis.forms.fields.GeometryField.clean().
> And the olwidget Field subclasses don't inherit from GeometryField
> (why not?).

You're right; it looks like olwidget is not ever converting WKT to
python geometries. This still works for postgres and spatialite; the
gis ORM just serializes geometries back to WKT on the way in anyway.
But leaving it as WKT does leave it less accessible to python -- and now
that I look into it, Django is converting it to geometry on the way
through the gis.db.models.field to verify it anyway, so there isn't even
a performance argument. So I'd consider it a bug that it's left as WKT.

Changing `EditableLayerField` to subclass from
`django.contrib.gis.forms.fields.GeometryField` doesn't sound like a bad
idea. It might also resolve
https://github.com/yourcelf/olwidget/issues/54 .

`InfoLayerField` is read-only, so it wouldn't be necessary there, though
I suppose it wouldn't hurt if someone wanted to read back the values as
geometries.

If you're interested in whipping up a patch to try this and testing the
implications, I'd be happy to pull. I won't be able to get to it myself
for about a week and a half; rather swamped at the moment.

This wouldn't solve the need for the metaclass magic: that stuff is
there to do the jujitsu that allows you to edit multiple model fields as
layers on a single map.

> Unless I'm missing something - which is likely - this makes it non-
> obvious how to use the fields and widgets of django-olwidget without
> using MapModelForm and/or GeoModelAdmin.
>
> Does anybody use them that way?

I haven't done a formal survey, but from mailing list chatter on this
list and geodjango's list, my impression is that the most widespread use
of olwidget is in admin (or at least, that's the place people talk about
it). Which is ironic, as I originally started this project for the
out-of-admin use case. Honestly, I've personally used olwidget.js
without django more than with.

-charlie

[Paul Winkler]

On Fri, May 27, 2011 at 06:54:02PM -0400, Charlie DeTar wrote:
> On 05/27/2011 05:41 PM, Paul Winkler wrote:
> > I'm using django-olwidget and trying rig up a subclass of
> > GeoModelAdmin that by default uses a different FormField subclass
> > (which in turn would use a different default Widget subclass).
>
> Have you looked at the examples in the included `test_project`? The top
> of admin.py:
>
> https://github.com/yourcelf/olwidget/blob/master/django-olwidget/test_project/testolwidget/admin.py
>
> Does this do what you want it to? `TestAdminForm` is customized plain
> ModelForm used with GeoModelAdmin.

Yeah, thanks, I should've explained more what I've tried.
That works - explicitly assigning fields is fine, although
still with the cleaning oddity mentioned below.

Now I'm trying to see if I can get something more automagic working,
like GeoModelAdmin but using a custom field/widget instead. I've got a fork
which adds a simple hook to make that easier, will send a pull
request.

> > That seems to be crucial: the WKT -> geometry transformation happens
> > only in contrib.gis.forms.fields.GeometryField.clean().
> > And the olwidget Field subclasses don't inherit from GeometryField
> > (why not?).
>
> You're right; it looks like olwidget is not ever converting WKT to
> python geometries. This still works for postgres and spatialite; the
> gis ORM just serializes geometries back to WKT on the way in anyway.
> But leaving it as WKT does leave it less accessible to python -- and now
> that I look into it, Django is converting it to geometry on the way
> through the gis.db.models.field to verify it anyway, so there isn't even
> a performance argument. So I'd consider it a bug that it's left as WKT.
>
> Changing `EditableLayerField` to subclass from
> `django.contrib.gis.forms.fields.GeometryField` doesn't sound like a bad
> idea. It might also resolve
> https://github.com/yourcelf/olwidget/issues/54 .
>
> `InfoLayerField` is read-only, so it wouldn't be necessary there, though
> I suppose it wouldn't hurt if someone wanted to read back the values as
> geometries.
>
> If you're interested in whipping up a patch to try this and testing the
> implications, I'd be happy to pull. I won't be able to get to it myself
> for about a week and a half; rather swamped at the moment.

That's fine; I'll see if I can get something working.
Remind me to remind you to remind me if I don't ;)

> This wouldn't solve the need for the metaclass magic: that stuff is
> there to do the jujitsu that allows you to edit multiple model fields as
> layers on a single map.

I see. Thanks.

--

Paul Winkler
http://www.slinkp.com

[Charlie DeTar]

Apologies for the delay on moderation of the message below... I only
just got the notification that it was sent today.

I'll try to respond to the content later today.

-charlie