A couple of newforms-admin questions
Karen Tracey
(http://code.djangoproject.com/wiki/NewformsAdminBranch) has
'Implement "edit inline" functionality' on the to-do list. But the
new syntax for inline editing is listed further down, and it all
seems to work fine for my site newly converted to newforms-admin. Is
the to-do list just out of date or is there more to be done with edit inline?
I'm also curious about something not on the to-do list: something to
replace the old radio_admin Field attribute. It seems radio_admin is
still allowed on fields, but has no effect on the field's display in
newforms-admin. Is the plan to remove radio_admin and provide
similar functionality in the new scheme (similar to raw_id_fields
maybe?). Or...? (I'm asking because I could take a look at doing
whatever the plan is, if you're just needing someone with a little
time to spend on doing it. It definitely seems that at a minimum
radio_admin ought to be disappearing?)
Karen
Joseph Kocherhans
>
> The branch page for newforms-admin
> (http://code.djangoproject.com/wiki/NewformsAdminBranch) has
> 'Implement "edit inline" functionality' on the to-do list. But the
> new syntax for inline editing is listed further down, and it all
> seems to work fine for my site newly converted to newforms-admin. Is
> the to-do list just out of date or is there more to be done with edit inline?
Mostly the to-do list is out of date. edit_inline is pretty much
functional at this point. There are still a bunch of somewhat obscure
bugs in trac that may or may not still be applicable.
> I'm also curious about something not on the to-do list: something to
> replace the old radio_admin Field attribute. It seems radio_admin is
> still allowed on fields, but has no effect on the field's display in
> newforms-admin. Is the plan to remove radio_admin and provide
> similar functionality in the new scheme (similar to raw_id_fields
> maybe?). Or...? (I'm asking because I could take a look at doing
> whatever the plan is, if you're just needing someone with a little
> time to spend on doing it. It definitely seems that at a minimum
> radio_admin ought to be disappearing?)
You're probably right. Something like radio_admin_fields on the
ModelAdmin class sounds reasonable. Could you file a ticket for this
so we don't lose track? I don't recall seeing one, but I could be
wrong.
Joseph
Karen Tracey
I couldn't find one either, so I opened one:
http://code.djangoproject.com/ticket/5731
I'll probably take a look at what's involved in doing it, but given
my unfamiliarity with the code it's quite possible someone else could
whip up a patch sooner.
Cheers,
Karen
Joseph Kocherhans
Here's a hint that will hopefully help you (or anyone else really) get
started: this should probably happen in the formfield_for_dbfield
method of the ModelAdmin class.
Joseph
Karen Tracey
> > >You're probably right. Something like radio_admin_fields on the
> > >ModelAdmin class sounds reasonable. Could you file a ticket for this
> > >so we don't lose track? I don't recall seeing one, but I could be
> > >wrong.
> >
> > I couldn't find one either, so I opened one:
> >
> > http://code.djangoproject.com/ticket/5731
> >
> > I'll probably take a look at what's involved in doing it, but given
> > my unfamiliarity with the code it's quite possible someone else could
> > whip up a patch sooner.
>
>Here's a hint that will hopefully help you (or anyone else really) get
>started: this should probably happen in the formfield_for_dbfield
>method of the ModelAdmin class.
Upon further investigation I'm not sure a replacement for radio_admin
is needed in newforms-admin. It seems the capability already exists,
since the user can supply their own custom widgets by overriding
formfield_for_dbfield. This thread shows it is already being done by
some people:
<http://groups.google.com/group/django-developers/browse_thread/thread/722ccaa9725293d0/4b52df7a428cb042?lnk=gst&q=RadioSelect&rnum=1#4b52df7a428cb042>http://groups.google.com/group/django-developers/browse_thread/thread/722ccaa9725293d0/4b52df7a428cb042?lnk=gst&q=RadioSelect&rnum=1#4b52df7a428cb042
It may not be as easy, and it may not be possible for the user to get
it to look quite exactly like it did in the old scheme, but the basic
capability exists. So perhaps all that is needed is to remove the
old radio_admin Field attribute?
(Before I discovered this I did get it working by adding support for
"radio_admin_fields" in a manner very similar to how "raw_id_fields"
is done, and it's not a lot of code or anything too hairy. But
coming to newforms-admin without the legacy of the old way, I think
I'd wonder why there's this "radio_admin_fields" special case when
the design supports a more general and flexible solution.)
Thoughts?
Karen
Brian Rosner
On Oct 11, 12:03 pm, Karen Tracey <kmtra...@gmail.com> wrote:
> At 06:00 PM 10/10/2007, Joseph Kocherhans wrote:
>
>
>
> > > >You're probably right. Something like radio_admin_fields on the
> > > >ModelAdmin class sounds reasonable. Could you file a ticket for this
> > > >so we don't lose track? I don't recall seeing one, but I could be
> > > >wrong.
>
> > > I couldn't find one either, so I opened one:
>
> > >http://code.djangoproject.com/ticket/5731
>
> > > I'll probably take a look at what's involved in doing it, but given
> > > my unfamiliarity with the code it's quite possible someone else could
> > > whip up a patch sooner.
>
> >Here's a hint that will hopefully help you (or anyone else really) get
> >started: this should probably happen in the formfield_for_dbfield
> >method of the ModelAdmin class.
>
> Upon further investigation I'm not sure a replacement for radio_admin
> is needed in newforms-admin. It seems the capability already exists,
> since the user can supply their own custom widgets by overriding
> formfield_for_dbfield. This thread shows it is already being done by
> some people:
>
> <http://groups.google.com/group/django-developers/browse_thread/thread...>http://groups.google.com/group/django-developers/browse_thread/thread...
>
> It may not be as easy, and it may not be possible for the user to get
> it to look quite exactly like it did in the old scheme, but the basic
> capability exists. So perhaps all that is needed is to remove the
> old radio_admin Field attribute?
>
> (Before I discovered this I did get it working by adding support for
> "radio_admin_fields" in a manner very similar to how "raw_id_fields"
> is done, and it's not a lot of code or anything too hairy. But
> coming to newforms-admin without the legacy of the old way, I think
> I'd wonder why there's this "radio_admin_fields" special case when
> the design supports a more general and flexible solution.)
>
> Thoughts?
>
I haven't dug to deeply into this, but from the sound of it, the
ModelAdmin class will need the radio_admin_fields because the look and
feel of the widget in the admin will differ from the generalized one
provided by newforms. This has been done with a few widgets and are
found in django.contrib.admin.widgets. In terms of what Joseph meant
by the formfield_callback is to hook the fields defined in
radio_admin_fields through the ModelAdmin formfield_callback method to
hook it into an admin specific widget that subclasses the newforms
provided one to get the same look and feel the oldforms admin gives.
> Karen