newforms-admin "plugins"
Marty Alchin
newforms-admin, since it's going to be merged someday, and it looks
like it would give me some better options. However, one thing I was
hoping for doesn't seem to be there.
For my policy work, I'd like to be able to add in a separate URL
handler within each model's registration, so that something like
/admin/app/policy/ and /admin/app/model/policy/ would give editors
customized for that location. However, I'm not seeing a way to do
anything like that, as the URL components are all hard-coded in an
if/elif block.
Has there been any talk of making some kind of plugin system for these
URLs, so that contrib apps can add their own functionality to existing
admin structures? Obviously, this would be a fairly considerable
change, and would also include a way to provide links to these new
interfaces from within existing admin templates. But I think it would
be useful, at least for my project.
Thoughts?
-Gul
Malcolm Tredinnick
Aren't you asking the wrong question here? The real issue seems to be
"how is admin going to handle arbitrary Field classes that it doesn't
otherwise know about?"
For particular models, you can easily do whatever you like as far as
admin presentation goes with the existing code. You override methods
like fieldsets(), fieldsets_add(), fieldsets_change() and the *_view()
(add_view, change_view, etc) methods to do whatever you wish. They are
all in the ModelAdmin class and look pretty easy to replace with
whatever behaviour you would like. So the framework for the ultimate
presentation of the information is already there.
Isn't the difficulty something like django-values faces is how is the
initial link to the admin page for an options class going to work in the
first place?
Regards,
Malcolm
Marty Alchin
> Aren't you asking the wrong question here? The real issue seems to be
> "how is admin going to handle arbitrary Field classes that it doesn't
> otherwise know about?"
Well, I'm not worried about Field classes. DurationField, for
instance, works just fine in newforms-admin without any modifications.
> For particular models, you can easily do whatever you like as far as
> admin presentation goes with the existing code. You override methods
> like fieldsets(), fieldsets_add(), fieldsets_change() and the *_view()
> (add_view, change_view, etc) methods to do whatever you wish. They are
> all in the ModelAdmin class and look pretty easy to replace with
> whatever behaviour you would like. So the framework for the ultimate
> presentation of the information is already there.
That's true when you have control over the model being represented,
yes. For django-values, however, it can be placed on any model in any
project, without django-values having any control over where or how it
gets used.
> Isn't the difficulty something like django-values faces is how is the
> initial link to the admin page for an options class going to work in the
> first place?
I'm not sure exactly what you're asking here, but I think the answer
is "yes". If you're talking about the HTML link to the value editor,
or the more symbolic "link" of attaching the editor to the ModelAdmin
class, both are what I'm wondering about. If, however, you're
referring to something else entirely, I guess I don't follow.
-Gul
Malcolm Tredinnick
> On 5/28/07, Malcolm Tredinnick <mal...@pointy-stick.com> wrote:
> > Aren't you asking the wrong question here? The real issue seems to be
> > "how is admin going to handle arbitrary Field classes that it doesn't
> > otherwise know about?"
>
> Well, I'm not worried about Field classes. DurationField, for
> instance, works just fine in newforms-admin without any modifications.
Bad terminology on my part. I also meant extra things like Options().
>
> > For particular models, you can easily do whatever you like as far as
> > admin presentation goes with the existing code. You override methods
> > like fieldsets(), fieldsets_add(), fieldsets_change() and the *_view()
> > (add_view, change_view, etc) methods to do whatever you wish. They are
> > all in the ModelAdmin class and look pretty easy to replace with
> > whatever behaviour you would like. So the framework for the ultimate
> > presentation of the information is already there.
>
> That's true when you have control over the model being represented,
> yes. For django-values, however, it can be placed on any model in any
> project, without django-values having any control over where or how it
> gets used.
I probably was not very clear in my explanation. Sorry; let's try again.
The Options() instance that is attached to a model by django-values
should be viewed as a relation to another model, just like ForeignKey or
ManyToMany key. Editing those requires either something like edit-inline
behaviour or moving to a different page. So this is exactly the same
logic for django-values.
The Options class needs it's own ModelAdmin like class that understands
how to present those values for admin editing. And then the default
admin needs a way to be able to shell out to arbitrary extra stuff like
this in a similar way to how it works for relations.
Regards,
Malcolm
Malcolm Tredinnick
I just made an assertion there and omitted the reasoning:
It seems that "extra" things on a model in whatever form they may take
are either instance-specific, in which case they are Field sub-classes
-- for database-backed data -- or methods, or they are model-specific
(e.g. django-values's Option() class), in which case, editing them via
the per-instance page is illogical, because the results apply to all
instances.
Regards,
Malcolm
Marty Alchin
I see what you're saying now. Admittedly, I hadn't done a lot of
research into newforms-admin yet, but you're right that it seems most
appropriate to make use of ModelAdmin (or a subclass or a replacement
thereof) as much as possible, I just didn't know how it would be tied
in to the existing system. Right now, it seems that newforms-admin is
very model-centric (and with good reason), which does make it a bit of
a challenge to add in functionality that's not tied to a particular
model.
As it stands right now, I can make a ModelAdmin subclass that would
allow editing of these values on a per-model basis, but as far as I
can tell, it would require users to go into django-values, then pick
out a model whose values need editing. I'd just rather be able to tie
into the per-model perspective somehow. Something like adding a
"values" link next to "add" and "change".
All in all, this isn't really an urgent need, since django-values
won't really need it until newforms-admin is ready to be merged into
trunk. I'm just trying to get the ball rolling so that once I get to
that point, it's a bit more finalized. I'm probably not the best
person to ask for ideas on how to get it to work though,
unfortunately.
-Gul
Adrian Holovaty
> For my policy work, I'd like to be able to add in a separate URL
> handler within each model's registration, so that something like
> /admin/app/policy/ and /admin/app/model/policy/ would give editors
> customized for that location. However, I'm not seeing a way to do
> anything like that, as the URL components are all hard-coded in an
> if/elif block.
I'm running into this problem/limitation in trying to fix
http://code.djangoproject.com/ticket/4450 -- the previous (trunk)
admin overrides the admin URLconf value for "/auth/user/" as a special
case, and newforms-admin doesn't do that yet. So there needs to be a
hook in ModelAdmin for overriding the URL parsing behavior.
It's currently implemented in ModelAdmin.__call__(), but that method
does some other things that you shouldn't have to duplicate. So, maybe
this could be fixed by adding a small hook in there -- handle_url(),
or something. Any thoughts?
Adrian
--
Adrian Holovaty
holovaty.com | djangoproject.com
Marty Alchin
> I'm running into this problem/limitation in trying to fix
> http://code.djangoproject.com/ticket/4450 -- the previous (trunk)
> admin overrides the admin URLconf value for "/auth/user/" as a special
> case, and newforms-admin doesn't do that yet. So there needs to be a
> hook in ModelAdmin for overriding the URL parsing behavior.
This probably sounds bad, but I'm glad I'm not the only one who's
missing something.
> It's currently implemented in ModelAdmin.__call__(), but that method
> does some other things that you shouldn't have to duplicate. So, maybe
> this could be fixed by adding a small hook in there -- handle_url(),
> or something. Any thoughts?
I admit I haven't done much work or testing with newforms-admin yet,
so I'm not sure how would be best. Looking at ModelAdmin.__call__(), I
wonder if those that if/elif section could reuse something from
urlpatterns. After all, it's just checking URLs and delegating to
views, something we already have a solid system for.
I doubt all of URLconf is needed, but maybe a list of 2-tuples
containing a regular expressions and a callable. Given that
ModelAdmin.__call__ currently passes parts of the URL to each view, it
would include the same kind of group captures that URLconf currently
uses.
I guess I don't know if all of that is necessary. Maybe just moving
that if/elif section to a handle_url() method would be simple enough.
Then subclasses can just override it and use super() to tie into the
stock views.
I guess I'm not sure exactly how would be best, but it's essentially
just a URLconf, so there ought to be something there that can be
reused.
-Gul
Malcolm Tredinnick
That would work.
Alternatively (and I suspect this is a variation on what Marty is
suggesting), move all the url processing bit out of __call__() and into
a function that __call__ calls. Then that function can be overridden in
the subclass. Notice that you don't have a similar problem in AdminSite
because the root() method there is only doing URL processing, so it can
be overridden and called via super().
I don't have any really strong preference for one method or the other,
although I probably have a slight preference for the sub-classing
approach if possible. We use both methods (super() calls and hooks)
elsewhere in the code, so neither approach is going to be surprising,
although I'm not sure if we use hooks in the public API as much.
Regards,
Malcolm
Marty Alchin
> Alternatively (and I suspect this is a variation on what Marty is
> suggesting), move all the url processing bit out of __call__() and into
> a function that __call__ calls. Then that function can be overridden in
> the subclass. Notice that you don't have a similar problem in AdminSite
> because the root() method there is only doing URL processing, so it can
> be overridden and called via super().
That's exactly what I was suggesting, actually. Well, for one of my
ramblings anyway. I'm glad to see I wasn't spouting completely random
nonsense. I'd prefer this method, I think, so that subclasses have the
choice to check against their URLs before the base class's, after it,
or ignore the base class handling altogether.
It somehow seems a bit less clean than using regular expressions and
such, but since this is such a specialized case, I do have to admit
that adding in the full flexibility of urlpatterns in here would just
complicate things unnecessarily.
I just created ticket #4516 for this, with a patch that moves the URL
handling into a handle_url() method, which is then responsible for
returning an HttpResponse.
-Gul