Re: Continuing problems running Django when not site Root.

2009-08-09 Thread Streamweaver 

Okay I am finnally getting my brain around this.

Thanks so much. I tried the code out and it works great, even on the
login.

I appreciate everyone's help and patience.

On Aug 8, 9:49 pm, Malcolm Tredinnick 
wrote:
> On Sat, 2009-08-08 at 13:41 -0700, Streamweaver wrote:
> > Let me clarify. This method handles the RequestContext obviously since
> > it's a login but what I mean is the SCRIPT_NAME variable isn't set for
> > the template and can't be read as far as I can tell.
>
> Nothing is automatically set for a template. If you want access to a
> particular quantity in a template, pass it in. You could even create a
> context processor if you want it every time. Typically, SCRIPT_NAME is
> *not* required in templates, since things like the url template tag
> already handle it automatically and constructing the correct URL for
> many things is more complex than just crashing together a few strings,
> so it tends to be done via template tags or in views. Thus, SCRIPT_NAME
> isn't a likely candidate for something that would be passed in all the
> time.
>
> Regards,
> Malcolm
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@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
-~--~~~~--~~--~--~---

Re: Continuing problems running Django when not site Root.

2009-08-08 Thread Malcolm Tredinnick 

On Sat, 2009-08-08 at 13:41 -0700, Streamweaver wrote:
> Let me clarify. This method handles the RequestContext obviously since
> it's a login but what I mean is the SCRIPT_NAME variable isn't set for
> the template and can't be read as far as I can tell.

Nothing is automatically set for a template. If you want access to a
particular quantity in a template, pass it in. You could even create a
context processor if you want it every time. Typically, SCRIPT_NAME is
*not* required in templates, since things like the url template tag
already handle it automatically and constructing the correct URL for
many things is more complex than just crashing together a few strings,
so it tends to be done via template tags or in views. Thus, SCRIPT_NAME
isn't a likely candidate for something that would be passed in all the
time.

Regards,
Malcolm



--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@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
-~--~~~~--~~--~--~---

Re: Continuing problems running Django when not site Root.

2009-08-08 Thread Streamweaver 

Let me clarify. This method handles the RequestContext obviously since
it's a login but what I mean is the SCRIPT_NAME variable isn't set for
the template and can't be read as far as I can tell.

On Aug 8, 4:15 pm, Streamweaver  wrote:
> I appreciate all the comment here and I definitly could be missing
> something.
>
> I tried backing out to a fresh install as requested above.
>
> The issue as best I can understand it lies in the default login
> scripts provided which are called as follows in my urls.py file
>
>     (r'^accounts/login/$', 'django.contrib.auth.views.login',
> {'template_name': 'accounts/login.xhtml'}),
>     (r'^accounts/logout/$', 'django.contrib.auth.views.logout',
> {'template_name': 'accounts/logout.xhtml'})
>
> The templates that normally handle rendering the SCRIPT_NAME property
> don't do so here I think because this script isn't being passed the
> RequestContext like other scripts.  I'll take a look at the source
> code for these items and it's likely I can pass a property to it but
> I'm a bit unsure how since the request object isn't passed to urls.py
> as far as I know.
>
> If you have more insight it would be helpful but so far my
> investigation seems to be turning up that I can't use these magic
> methods.
>
> Thanks again and I'll keep looking this weekend and post if I find
> what I'm doing wrong.
>
> On Aug 7, 10:49 pm, Malcolm Tredinnick 
> wrote:
>
> > On Fri, 2009-08-07 at 14:44 -0700, Streamweaver wrote:
>
> > [...]
>
> > > Is there anyway around this?  Anyone know if fixing this on the Django
> > > roadmap?
>
> > It was fixed over a year ago (before Django 1.0 came out). If you are
> > using anything later than that, you don't have to do *anything* to worry
> > about SCRIPT_NAME, although the variable is set in the request.META
> > dictionary so you can use it to construct URLs if you want to do that
> > manually.
>
> > Regards,
> > Malcolm
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@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
-~--~~~~--~~--~--~---

Re: Continuing problems running Django when not site Root.

2009-08-08 Thread Streamweaver 

I appreciate all the comment here and I definitly could be missing
something.

I tried backing out to a fresh install as requested above.

The issue as best I can understand it lies in the default login
scripts provided which are called as follows in my urls.py file

(r'^accounts/login/$', 'django.contrib.auth.views.login',
{'template_name': 'accounts/login.xhtml'}),
(r'^accounts/logout/$', 'django.contrib.auth.views.logout',
{'template_name': 'accounts/logout.xhtml'})

The templates that normally handle rendering the SCRIPT_NAME property
don't do so here I think because this script isn't being passed the
RequestContext like other scripts.  I'll take a look at the source
code for these items and it's likely I can pass a property to it but
I'm a bit unsure how since the request object isn't passed to urls.py
as far as I know.

If you have more insight it would be helpful but so far my
investigation seems to be turning up that I can't use these magic
methods.

Thanks again and I'll keep looking this weekend and post if I find
what I'm doing wrong.

On Aug 7, 10:49 pm, Malcolm Tredinnick 
wrote:
> On Fri, 2009-08-07 at 14:44 -0700, Streamweaver wrote:
>
> [...]
>
> > Is there anyway around this?  Anyone know if fixing this on the Django
> > roadmap?
>
> It was fixed over a year ago (before Django 1.0 came out). If you are
> using anything later than that, you don't have to do *anything* to worry
> about SCRIPT_NAME, although the variable is set in the request.META
> dictionary so you can use it to construct URLs if you want to do that
> manually.
>
> Regards,
> Malcolm
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@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
-~--~~~~--~~--~--~---

Re: Continuing problems running Django when not site Root.

2009-08-07 Thread Malcolm Tredinnick 

On Fri, 2009-08-07 at 14:44 -0700, Streamweaver wrote:
[...]
> Is there anyway around this?  Anyone know if fixing this on the Django
> roadmap?

It was fixed over a year ago (before Django 1.0 came out). If you are
using anything later than that, you don't have to do *anything* to worry
about SCRIPT_NAME, although the variable is set in the request.META
dictionary so you can use it to construct URLs if you want to do that
manually.

Regards,
Malcolm


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@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
-~--~~~~--~~--~--~---

Re: Continuing problems running Django when not site Root.

2009-08-07 Thread Graham Dumpleton 

Django since 1.0 onwards is usually fine with SCRIPT_NAME. Quite
possibly you have tweaked something in settings or setup urls.py wrong
to cause the issue. I would suggest you start over with a fresh Django
installation and create the most minimal working example of what you
are trying to do and which demonstrates the problem. Then come back
and post what your Apache/mod_wsgi configuration is, what you changed
in settings, what you have in urls.py and the details of what and what
the template contains.

In short, it is impossible to help when others don't have a problem
and we have no idea of what you have set your configuration to or how
you are trying to do what you are doing.

Graham

On Aug 8, 7:44 am, Streamweaver  wrote:
> There's been some discussion here about what to do when you're trying
> to run a Django site not under the root domain.
>
> So for a site likehttp://mysite.com/django/
>
> Django (or WSGI?) doesn't seem to be able to be able to handle the
> SCRIPT_NAME ('/django' in this example) portion of the url well.  You
> have to add the request context to the application and views as well
> as account for it in the templates.
>
> Fair enough I guess and I refactored my application to handle this so
> far.
>
> I'm running into pretty big problems with using Django's login
> framework in this context.
>
> First there are the various login settings of 'LOGIN_URL' and such,
> and these can't be passed a context.  I got around this by adding
> another variable to the settings file I can see in addition to having
> to read the SCRIPT_NAME in the views and templates.
>
> I continue to have a problem though in that the generic login
> functions seem to have no way to handle SCRIPT_NAME and I suspect this
> problem extends to generic views in general.
>
> Is there anyway around this?  Anyone know if fixing this on the Django
> roadmap?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@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
-~--~~~~--~~--~--~---

Continuing problems running Django when not site Root.

2009-08-07 Thread Streamweaver 

There's been some discussion here about what to do when you're trying
to run a Django site not under the root domain.

So for a site like http://mysite.com/django/

Django (or WSGI?) doesn't seem to be able to be able to handle the
SCRIPT_NAME ('/django' in this example) portion of the url well.  You
have to add the request context to the application and views as well
as account for it in the templates.

Fair enough I guess and I refactored my application to handle this so
far.

I'm running into pretty big problems with using Django's login
framework in this context.

First there are the various login settings of 'LOGIN_URL' and such,
and these can't be passed a context.  I got around this by adding
another variable to the settings file I can see in addition to having
to read the SCRIPT_NAME in the views and templates.

I continue to have a problem though in that the generic login
functions seem to have no way to handle SCRIPT_NAME and I suspect this
problem extends to generic views in general.

Is there anyway around this?  Anyone know if fixing this on the Django
roadmap?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@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
-~--~~~~--~~--~--~---