On Mon, May 17, 2010 at 5:55 PM, Dennis Decker Jensen <dennisdjen...@gmail.com> wrote: > Hello! > > I've been using django for a while now, and been around in the > documentation and a bit in the source code as well. I have a site > setup along the lines of the tutorial, nothing fancy, a flat urls.py > and no fancy use of namespaces or anything like that. > > I use django straight from subversion trunk (with no significant > trouble), and finally got around to change admin.site.root to > include(admin.site.urls) in urls.py, because site.root is going to > disappear real soon now -- but it doesn't work.
Well, I'm sorry, but it does work, and we've got plenty of evidence to back up our claim, including a test suite and a tutorial that works fine. Now, you may have found an edge case with a problem. That doesn't mean "it doesn't work" -- it means there's a specific set of circumstances when it doesn't work. That's a very important difference. > It mangles the URL in such a way in the admin application that a link > becomes longer and longer, e.g. admin/cm/device when clicked reloads > the same page and the link becomes admin/cm/device/cm/device and when > clicked again, admin/cm/device/cm/device/cm/device, and so forth > recursively. This is vaguely reminiscent of some problems that existed in the final stages of 1.1 development, but the bugs that caused those problems were resolved before 1.1 was released. I can't say I've seen this in recent versions of Django. > I have searched the web and mailing lists in vain. I suspect root_path > aren't set correctly somewhere in AdminSite or that url references in > the admin application are somehow not handled correctly, but I haven't > been able to find any suspect things in the code. > > Maybe somebody here knows what it is going on? It seems it cannot be > replicated. Django developers are more busy than I am, and it seems > they have no time for this sort of thing (which cannot be replicated). Well, if you're seeing the problem, then it can be replicated. It's just a matter of how. So, if you have a project that demonstrates the problem, start deleting code until the problem doesn't exist any more. Alternatively, start with a minimal project and add bits until it breaks. The change that causes the problem to appear/disappear is the problem. As for django-developers having "no time for this sort of thing" -- we are *always* interested in bug reports. What we don't have a lot of time for is trying to use a crystal ball to diagnose the problems of others. Take it as given that the tutorial works for us. We wouldn't release a version of Django where core functionality was fundamentally broken in the way you describe. If you're seeing a problem and you don't think it's user error, you need to meet us half way. In this case, the only detail you have given is "a project set up along the same lines as the tutorial". That leaves a *lot* of wiggle room for ambiguous details, and details that you may not think are significant, but are nonetheless the underlying source of the problem. If you can't work out a specific change or configuration that causes problem, providing a *complete* sample project that demonstrates the problem is the very least that is required. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
