Root URI in templates
plungerman
in an attempt to better understand, django from a systems perspective,
i have been attempting to install various blog type applications that i
have found out there in the wild. i ran into a problem with Jeff
Croft's lost-theories application. basically, i set up my apache
mod_python to send all requests for /lost/ to the django interpreter:
<Location "/lost/">
SetHandler python-program
PythonHandler django.core.handlers.modpython
PythonPath "['/d2'] + sys.path"
SetEnv DJANGO_SETTINGS_MODULE lost.settings
PythonDebug On
</Location>
i modified the urls.py file to accomodate this structure, adding "lost"
to the reg ex for each pattern, for example:
# For homepage:
(r'^lost/$', 'django.views.generic.simple.direct_to_template',
{'template': 'homepage.html'})
the problem is that all of the templates use a fully qualified path
from the "document root". for example:
<a href="/theories/create/">
it would be nice to be able to include a ROOT_URL or ROOT_URI value in
the settings.py file, just like for MEDIA_URL. the end result would be
that you could put ROOT_URI at the beginning your HREF, allowing you to
install the application in any place you want. for example:
<a href="{% root_uri %}theories/create/">
is there another way to accomplish this that i have missed in the
documentation? any thoughts on this practice? i am in essence looking
for a way to make things more portable.
thanks in advance.
yours,
steve
ChrisW
I also noticed that the djangoproject webistes templates are full of
absolute hrefs to stylesheets and other *media*. Does anyone else think
this is a bad idea?
ChrisW.
ToddG
topic:
There are other threads pre-dating that one as well...
James Bennett
> I also noticed that the djangoproject webistes templates are full of
> absolute hrefs to stylesheets and other *media*. Does anyone else think
> this is a bad idea?
Why is it a bad idea to have a site's templates reference that site's
stylesheets and media?
If anything, this should be a fairly common case on Django-powered
sites, because the preferred setup is to use Apache/mod_python for
parts of the site powered by Django and a different web server for
media files like images and stylesheets, possibly even on a different
domain (e.g., main site is example.com, media is media.example.com);
in that case, absolute URLs are a plain necessity -- there's no way to
create a relative URL that leads to a resource on a different domain.
--
"May the forces of evil become confused on the way to your house."
-- George Carlin
ChrisW
there should be someway of abstracting them further than is currently
available.
Lets say that your media server's address changes, doesnt it seem silly
to have to go through ALL of your templates to change those absolute
URL's?
I agree with the idea that media should be served served separately to
structure, but I disagree with the implication that stylesheets are
media (at least for now, as I love being proved wrong by intelligent
people).
Lets say I have a django app that I want to make publicly available for
others to install and play with. Currently, the stylesheets and
templates would have to be separately packaged from the app it self.
This doesnt bother me so much with regards to the templates as there is
a way to tell your django installation with one line where it should
look for templates, but its another matter for stylesheets (and I dare
say certain images that IMHO should not be considered *media*).
I predict that by reading this post you will have guessed correctly
that I'm utterly confused about what is the right thing to do. (the
best practice)
Sincerely,
ChrisW
James Bennett
> to have to go through ALL of your templates to change those absolute
> URL's?
settings.MEDIA_URL contains info on this; if you're worried about that
use it to build up the links (e.g., write a templatetag that pulls it
in, or a context processor that puts it in the template context.
> I agree with the idea that media should be served served separately to
> structure, but I disagree with the implication that stylesheets are
> media (at least for now, as I love being proved wrong by intelligent
> people).
It's not that "media" and "structure" are separated, it's that with
Apache/mod_python it's better for performance reasons to use a
separate web server for media files, stylesheets and JavaScript unless
those files are being constructed by Django; why incur the overhead of
a process with Django and your app in memory just to read a file off
disk and send it down the pipe?
Of course, with other server arrangements this is less of a problem;
my personal blog, for example, runs under lighttpd/FastCGI, so the
same lighttpd instance serves all requests and has rewrites in place
to ensure that the FastCGI listeners get any requests which require
Django.
ChrisW
Thank you for your replies.
> settings.MEDIA_URL contains info on this; if you're worried about that
> use it to build up the links (e.g., write a templatetag that pulls it
> in, or a context processor that puts it in the template context.
I had thought of doing this, but after not seeing it in anyone elses
code, I wasnt sure if:
a) it was the "right thing to do". b) how to do it properly.
> It's not that "media" and "structure" are separated, it's that with
> Apache/mod_python it's better for performance reasons to use a
> separate web server for media files, stylesheets and JavaScript unless
> those files are being constructed by Django; why incur the overhead of
> a process with Django and your app in memory just to read a file off
> disk and send it down the pipe?
> ......
> Of course, with other server arrangements this is less of a problem;
> my personal blog, for example, runs under lighttpd/FastCGI, so the
> same lighttpd instance serves all requests and has rewrites in place
> to ensure that the FastCGI listeners get any requests which require
> Django.
I definitely agree with you here. Is the same thing possible with
mod_python and "SetHandler None" in the httpd.conf?
I also forgot to mention that lately I have been thinking, and would
appreciate your and other's opinions/thoughts/flames, so here goes:
* There are 2 kinds of media; content media and presentation media.
E.g.
stylesheets, icons, backgrounds, etc. == presentation media.
photos, videos, mp3's, pdfs, etc. == content media
* Certainly it is no problem to have the content media served
separately as it is not at all coupled to the application.
* But presentation media on the other hand, I see it as an integral
part of an application (templates also) and whilst I agree with it not
being served by django / mod_python / whatever, I dont see the sense in
it being anywhere else but inside the applications folder.
I.e.
./MyDjangoProject/
./MyDjangoApp/
./templates/
./css/
./js/
./img/
(remember: im not saying to put content in here, just elements that are
required for the app to function the way it was designed)
What do you guys think?
Cheers,
ChrisW
limodou
One method:
set a "base" tag in template, so this tag will point the root uri of
this page, and other uris can be related with this uri.
Two method:
Define some template variables used for root uri, and using them in
urls. So you can define them in settings.py or somewhere, and if the
situation changed, you may only change the settings.py.
--
I like python!
My Blog: http://www.donews.net/limodou
My Django Site: http://www.djangocn.org
NewEdit Maillist: http://groups.google.com/group/NewEdit
Scott Anderson
> On 6/13/06, ChrisW <chris...@gmail.com> wrote:
> It's not that "media" and "structure" are separated, it's that with
> Apache/mod_python it's better for performance reasons to use a
> separate web server for media files, stylesheets and JavaScript unless
> those files are being constructed by Django; why incur the overhead of
> a process with Django and your app in memory just to read a file off
> disk and send it down the pipe?
Why is this?
I currently have Apache serving static content directly from my Django
directory while other URIs are shunted to the development server via a
rewrite proxy. Why is the equivalent not possible with FastCGI and
mod_python in Apache as well?
Regards,
-scott
plungerman
that is precisely what i would like to do. how you access a
variable defined in settings.py from a template tho? i have
not been able to track this bit down.
roger sun
from django.conf.settings import
the full url:
http://www.djangoproject.com/documentation/settings/
limodou
> >
> > set a "base" tag in template, so this tag will point the root uri of
> > this page, and other uris can be related with this uri.
> >
> > Two method:
> >
> > Define some template variables used for root uri, and using them in
> > urls. So you can define them in settings.py or somewhere, and if the
> > situation changed, you may only change the settings.py.
>
> that is precisely what i would like to do. how you access a
> variable defined in settings.py from a template tho? i have
> not been able to track this bit down.
>
>
2. write your own template processor and config it in settings.py
Steven Armstrong
>> > One method:
>> >
>> > set a "base" tag in template, so this tag will point the root uri of
>> > this page, and other uris can be related with this uri.
>> >
>> > Two method:
>> >
>> > Define some template variables used for root uri, and using them in
>> > urls. So you can define them in settings.py or somewhere, and if the
>> > situation changed, you may only change the settings.py.
>>
>> that is precisely what i would like to do. how you access a
>> variable defined in settings.py from a template tho? i have
>> not been able to track this bit down.
>>
>>
> 1. in the view code, pass settings.py variables into template.
>
> 2. write your own template processor and config it in settings.py
>
3. write your own templatetags. see django/contrib/admin/templatetags/
for examples
Ivan Sagalaev
> I had thought of doing this, but after not seeing it in anyone elses
> code, I wasnt sure if:
> a) it was the "right thing to do". b) how to do it properly.
>
style_url }} and {{ js_url }} in templates. This is convenient.
This is not such a big deal to have an "officially" recommended way to
do it. Use whatever and however you feel is right for you.
Derek Hoy
> variable defined in settings.py from a template tho? i have
> not been able to track this bit down.
Here's what I have.
in settings.py:
APP_BASE = "http://www.mysite.org/"
in templatetags directory, somewhere on django's path, is a file sitevars.py
----
from django import template
from django.conf import settings
register = template.Library()
@register.simple_tag
def site_base():
return settings.APP_BASE
some other utility stuff...
----
in any template, I can use:
{% load sitevars %}
...
<a href="{% site_base %}....">
----
Custom tags are ridiculously easy with simple_tag and inclusion_tag.
See http://www.djangoproject.com/documentation/templates_python/#shortcut-for-simple-tags
One other thing I picked up in this group, is to use a
local_settings.py for stuff like this that will be different for
development, test, production servers.
You just import it into your settings.py, then you can have different
base URIs for each environment.
--
Derek
Waylan Limberg
> variable defined in settings.py from a template tho? i have
> not been able to track this bit down.
>
James Bennett recently posted an excellent article on this very
subject which offers a much slicker way that template tags. Find it
here: http://www.b-list.org/weblog/2006/06/14/django-tips-template-context-processors
--
----
Waylan Limberg
way...@gmail.com
plungerman
this manoeuvre does not work with 404.html and 500.html type pages. we
have custom templates for those two errors, and the variable is not
available in those templates. anyone have a suggestion how one might
make the variable available in custom error templates?
Ivan Sagalaev
> perfect, just what we needed. one thing i noticed, however, is that
> this manoeuvre does not work with 404.html and 500.html type pages.
This is because they use a simple Context, not RequestContext.
> we
> have custom templates for those two errors, and the variable is not
> available in those templates. anyone have a suggestion how one might
> make the variable available in custom error templates?
You can write your own handlers for those pages which is very easy
(though a bit annoying).
urls.py:
handler404 = 'myproject.myapp.views.handler404'
views.py:
from django.http import HttpResponseNotFound
from django.template import loader, RequestContext
def handler404(request):
template = loader.get_template('404.html')
context = RequestContext(request)
return HttpResponseNotFound(template.render(context))
Derek Hoy
--
Derek