I realise the confusion I'm about to cause here is predominantly my
fault for not working faster, but I thought I'd have a bit more time
than I did. So a massive mea culpa there.
Anyway, I have some questions and concerns about r9739 that Jacob
committed overnight (my time) that maybe can be cleared up with some
explanation or maybe are the flaws I suspect they might be.
The first problem is that I can't work out the answers to these
questions by reading the documentation and test changes that went in
with the patch, since there aren't any! That makes me sad. That was
actually predominantly why I thought the patch wasn't about to be
committed very quickly, since they're both pretty important components
of anything we're calling a feature addition.
More importantly, though, I'm not really sure what problem this is
trying to solve. At least, it looks like it's only addressing a very
restricted case. This is something that has been bugging me a bit
lately: proposed solutions to things that don't actually explain the
problem they're solving, so it's hard to evaluate if they solve the
intended problem or miss or if we're talking at cross-purposes about the
problem that needs to be solved.
I've been sketching out a solution on my own (and I agree, my fault for
not sharing) and it seems to come down to three main use-cases (there's
a fourth that I'm thinking is out of scope). Bear in mind, as you're
reading this, that this is intended to be not just admin specific, but
rather for any app that can be called as multiple instances.
(1) A template needs to refer to the admin instance that is
rendering that template (for templates inside the app itself).
They won't know the name under which the particular rendering
admin is called in the URLConf, since that is installer stuff.
So we need a generic, app-specific name that means "self".
(2) Some other template needs to be able to call a particular
admin instance. This can use the name (however that is specified
in any solution) that the admin is installed under in URLConf.
Mostly AppA will require that an admin (and, again, "admin" is a
proxy word for "multiply-instanced application") exists under
nameB. For example, an "edit this" link on a page that points to
the editor-specific version of the admin, as opposed to say the
content-publisher-specific version.
(3) A template needs to call *any* instance (call it the
"default" instance) of the admin. A reasonable example here are
bookmarklets. Again, this can use the default name of the admin
application to determine.
The use-case I kind of mentally decided was out of scope was some kind
of name overloading so that appA's templates say they want to call an
admin of nameB and somehow the person installing that app overloads an
existing admin version with nameB. That maybe could come later, but
initially, it would be a case of "just put in an entry with a name of
nameB".
As best I can work out, the current patch kind of does situation (1),
but only for a single admin? Every template will always call the primary
admin instance when you use the url tag? Actually, it looks like it's
all about reverse() and not much consideration given to the url tag,
but, again, I don't really understand how to use it at the moment.
For the record, the way I was thinking we could make all these
situations work is as follows (and I'll phrase it using templates and
the url tag, since the reverse() call is easy once that case is
handled). We can write namespace-aware (or rendering-context aware) urls
using a prefix to indicate that a portion has to be resolved using some
variable in the context. Specifically,
{% url admin:edit-bookmarklet %}
for example. The context will contain a variable called, say,
_resolvers, that is a dictionary containing key names mapped to
instances. So the _resolvers["admin"] key will either be missing (in
which case we use the object from the URLConf with the name of "admin"
-- use-case #2), or it maps to a particular admin site object that has a
"reverse" callable that can be used to do the specific reversal
(use-case #1). Use-case #3 is handled by having a default name for the
class that doesn't need to be expressed explicitly in the URLConf and is
the name anybody can use to mean "any admin, just point me at one of
them" or possibly "the first admin specified", although the latter
situation is harder to implement, I've found.
That all seems to extend quite nicely to other classes beyond admin (and
if we include a "resolve" callable on classes to specify what should be
used to resolve things, we probably don't need to overload include(),
but that's a relatively minor thing that can wait for the future.
Right now, the short thing I'd like to find out is what problem the
current patch is meant to be solving. Does it extend to url tags? If so,
how can it work for something like use-case #2, in particular (if I have
two-instances installed, how can I say "resolve with respect to the
current one")? Maybe the url tag changes still work on top of this --
the code I'd been trying to pull together used portions of the patch
from #6470 to get most of the admin-specific stuff done -- but I'm
really a bit confused.
I am *not* trying to denigrate the work in #6470 and Alex and Jacobs'
efforts to get something to completion (but .. no documentation?! no
tests?!). I'm completely to blame for not bringing this up earlier. But
now that it's landed, we need to fix any major problems fast or live
with it forever.
Regards,
Malcolm
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
