Thank you for the responses so far. But I still haven't identified
the solution to this seemingly simple issue.
The behavior also happens when I use the URL tag in a template like
this "{% url case_url case.id %}" the result I get is "/support/case/
1/ ".
So the inconsistency is that when I make a request for "http://
www.example.com/helpdesk/support/1/" django is correctly mapping to
the "case" view. But while processing the "case" view and explicitly
naming the "case_url" that points to it, any reverse lookups are not
returning the correct URL.
To me it looks like a bug since I would think it would work both ways
or neither.
I think it may have to do with my switch to django 1.1.1 and mod_wsgi
from an older 1.x version with mod_python.
When using mod_python, this was handled like so:
<Location "/mysite/">
SetHandler python-program
PythonHandler django.core.handlers.modpython
SetEnv DJANGO_SETTINGS_MODULE mysite.settings
PythonOption django.root /mysite
PythonDebug On
</Location>
But according to this:
http://code.google.com/p/modwsgi/wiki/IntegrationWithDjango
"Note that the django.root option introduced in Django 1.0 alpha
versions does not apply to mod_wsgi and is only necessary with
mod_python, due to mod_python not setting SCRIPT_NAME correctly. "
So where does that leave us? does mod_wsgi need some other
configuration?
On Jan 2, 10:25 pm, davathar <davat...@gmail.com> wrote:
> Bill: Tried that, but it made no difference. case is resolving ok.
> The problem is with the first part "/helpdesk/" dropping off when
> doing a reverse. The same behavior happens when I use the URL tag in
> a template. "{% url case_url case.id %}" I get /support/case/1/
> without the /helpdesk in front of it.
>
> I'm pretty sure this is because I installed Django to be served not
> from the root, but rather from /helpdesk/. I use WebFaction as a
> host, and their control panel is where this is setup. I think it uses
> SymLinks to direct the shared Apache to the private one that only
> serves my Django app. But I'm not sure and can't find a way to tell
> for sure. There's nothing currently in the any of the Django files
> that refers to /helpdesk/ as part of the url. Yet the webserver
> resolves it properly with /helpdesk/ there and not without it.
>
> So I think that the first Apache server is resolving the /helpdesk/
> portion of the url and then forwarding everything after that to be
> handled by Django. So maybe django doesn't know about /helpdesk/
> internally.
>
> Surely I'm not the only person who setup django to serve from a sub
> url. And WebFaction is a popular Django host. There must be some
> simple setting I'm missing somewhere. Does anyone know what it is?
>
> Thank you in advance.
>
> On Dec 30 2009, 11:37 am, Bill Freeman <ke1g...@gmail.com> wrote:
>
> > Since your urlconf is passing "case" as a named (keyword) argument, you
> > (may) have to pass it that way to reverse:
>
> > ...reverse('case_url', kwargs={'case':case.id})...
>
> > Bill
>
> > On Mon, Dec 28, 2009 at 8:22 PM, davathar <davat...@gmail.com> wrote:
> > > I'm stuck on a "reverse" problem. The 'case' view is supposed to
> > > record posted info, then reload the same page. But it's dropping the
> > > first part of the URL on the redirect and I've not been able to figure
> > > out why.
>
> > > It should be going to .com/helpdesk/support/case/1/ But it's going
> > > to .com/support/case/1/
>
> > > I'm sure it's something simple as I've had the problem in the past and
> > > fumbled my way through it. But I can't find it this time. Hopefully
> > > the below pasted lines show all the necessary detail.
>
> > > Anyone see my error?
>
> > > helpdesk.urls:
> > > urlpatterns = patterns('',
> > > (r'^support/', include('helpdesk.support.urls')),
> > > )
>
> > > helpdesk.support.urls:
> > > urlpatterns = patterns('helpdesk.support.views',
> > > (r'^case/(?P<case>\d+)/$', 'case',{},'case_url' ),
> > > )
>
> > > helpdesk.support.views:
> > > def case(request, case):
> > > return HttpResponseRedirect(reverse('case_url', args=(case.id,)))
> > > # Redirect back here after POST
>
> > > -Shane
>
> > > --
>
> > > 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
> > > athttp://groups.google.com/group/django-users?hl=en.
--
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.
