Designing base template - how to include media properly?
1 view
Skip to first unread message
Todd Blanchard
Nov 23, 2009, 3:31:26 PM11/23/09
to Django users
I've read this:
http://docs.djangoproject.com/en/dev/topics/forms/media/
Nifty.
Now, how exactly do I make sure that the media urls get spewed properly into the head section of the page? This is apparently omitted everywhere I've looked. The admin template seems to pull it off properly but I cannot figure out how. Seems like I should be able to do something like
<html>
<head>
{{ media }}
</head>
but I cannot figure out exactly how to properly aggregate all the forms' media's and get them spewed into the templates properly.
-Todd
http://docs.djangoproject.com/en/dev/topics/forms/media/
Nifty.
Now, how exactly do I make sure that the media urls get spewed properly into the head section of the page? This is apparently omitted everywhere I've looked. The admin template seems to pull it off properly but I cannot figure out how. Seems like I should be able to do something like
<html>
<head>
{{ media }}
</head>
but I cannot figure out exactly how to properly aggregate all the forms' media's and get them spewed into the templates properly.
-Todd
Mark (Nosrednakram)
Nov 23, 2009, 5:40:29 PM11/23/09
to Django users
Hello,
I have something like the following in my generic genericform.html. I
think this is what you're looking for if not hope you find a better
answer. The extramedia block is back in my base.html template and my
form template extends it. I'm not sure if it's in the admin base.html
but you can take a look at if for there media blocks I believe are
something like extrastyle etc...
{% block extramedia %}
{% if forms %}
{% for form in forms %}
{{ form.media }}
{% endfor %}
{% else %}
{{ form.media }}
{% endif %}
Mark
Todd Blanchard
Nov 24, 2009, 2:30:24 PM11/24/09
to django...@googlegroups.com
What about de-duping?
If two forms want the same js file, will it get included twice?
It seems like this is the kind of thing that the framework should handle and the current "solution" is kind of half baked.
-Todd
> --
>
> You received this message because you are subscribed to the Google Groups "Django users" group.
> To post to this group, send email to django...@googlegroups.com.
> To unsubscribe from this group, send email to django-users...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/django-users?hl=.
>
>
If two forms want the same js file, will it get included twice?
It seems like this is the kind of thing that the framework should handle and the current "solution" is kind of half baked.
-Todd
>
> You received this message because you are subscribed to the Google Groups "Django users" group.
> To post to this group, send email to django...@googlegroups.com.
> To unsubscribe from this group, send email to django-users...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/django-users?hl=.
>
>
Tim Valenta
Nov 24, 2009, 5:05:11 PM11/24/09
to Django users
The idea is along the lines of what you initially guessed.
The admin accomplishes the non-duplicate effect in django/django/
contrib/admin/options.py, starting at line 770. It loops over the
forms and combines the existing media with the media on each form
object. It ends up using a series of objects to do it, including a
Media class, but it's not doing anything too special. When an item
gets added, it checks to make sure that the path doesn't already exist
in the list.
So, short story: loop over your forms and add the media attributes
together. The underlying Media class ought to be dropping duplicates.
Then just save a context variable with the result, and do the
following in your template:
{% block extrahead %} {# or whatever you call your header block #}
{{ block.super }}
{{ cumulative_media }}
{% endblock %}
Tim
The admin accomplishes the non-duplicate effect in django/django/
contrib/admin/options.py, starting at line 770. It loops over the
forms and combines the existing media with the media on each form
object. It ends up using a series of objects to do it, including a
Media class, but it's not doing anything too special. When an item
gets added, it checks to make sure that the path doesn't already exist
in the list.
So, short story: loop over your forms and add the media attributes
together. The underlying Media class ought to be dropping duplicates.
Then just save a context variable with the result, and do the
following in your template:
{% block extrahead %} {# or whatever you call your header block #}
{{ block.super }}
{{ cumulative_media }}
{% endblock %}
Tim
Todd Blanchard
Nov 24, 2009, 6:13:04 PM11/24/09
to django...@googlegroups.com
You know what, this is absolutely too much BS. Why would one bother to use the media declaration stuff at all if there is no mechanism to properly consume it (a built in template tag for instance).
I think I will just hardcode them in the head in the base template. They seldom change and browser caching being what it is having them never change is just fine.
After three weeks of seriously trying to get traction with django, my conclusion is it has all of the elegance of X-windows. It can do anything but out of the box it does nothing except present a zillion confusing parts to the programmer and it has too many mechanisms but no policies.
I'm beginning to very much pine for rails. At least it does something out of the box.
Very frustrated today - still haven't got a single record/entry form working. Too many little files and indirection to keep it all straight in my head.
-Todd Blanchard
> For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
>
>
I think I will just hardcode them in the head in the base template. They seldom change and browser caching being what it is having them never change is just fine.
After three weeks of seriously trying to get traction with django, my conclusion is it has all of the elegance of X-windows. It can do anything but out of the box it does nothing except present a zillion confusing parts to the programmer and it has too many mechanisms but no policies.
I'm beginning to very much pine for rails. At least it does something out of the box.
Very frustrated today - still haven't got a single record/entry form working. Too many little files and indirection to keep it all straight in my head.
-Todd Blanchard
>
>
Tim Valenta
Nov 24, 2009, 6:28:58 PM11/24/09
to Django users
Sorry it's not working out for you, but I'd disagree about the
comparison to X-Windows :) I'd be defending Django, and not X-
windows, when I say that.
I'm serious. Just add them together. I'm not sure you're
appreciating the slick objects that have been crafted for this very
purpose.
Your view:
cumulative_media = form.media for form in forms
return render_to_response('mytemplate.html', {'media':
cumulative_media})
Your template:
{% block my_media_block %}
{{ block.super }}
{{ media }}
{% endblock %}
I fail to see what is so hard about this.
Tim
comparison to X-Windows :) I'd be defending Django, and not X-
windows, when I say that.
I'm serious. Just add them together. I'm not sure you're
appreciating the slick objects that have been crafted for this very
purpose.
Your view:
cumulative_media = form.media for form in forms
return render_to_response('mytemplate.html', {'media':
cumulative_media})
Your template:
{% block my_media_block %}
{{ block.super }}
{{ media }}
{% endblock %}
I fail to see what is so hard about this.
Tim
Todd Blanchard
Nov 24, 2009, 6:33:50 PM11/24/09
to django...@googlegroups.com
What is annoying is I have to repeat this incantation in every view function ever, yes?. If its got a form, I have to do this every time.
I thought the idea was to write less code? Not the same code over and over again in every view.
Or am I missing something. Seems like I am getting very much NON-DRY here.
> For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
>
>
I thought the idea was to write less code? Not the same code over and over again in every view.
Or am I missing something. Seems like I am getting very much NON-DRY here.
>
>
Tim Valenta
Nov 24, 2009, 6:35:12 PM11/24/09
to Django users
PS -- I hope I don't sound like I'm insulting your intelligence--- I'm
not. I've often felt like there aren't enough policies in Django,
myself. But pick your battles. This is an easy one. I prefer Django
over Rails, when it comes down to it. Feel fortunate that Django has
practically the best documentation on the planet. I hate more open
source docs, because it was written by a guy who don't know how to use
proper english!
I'm just trying to drive home the point that this isn't the worst
thing that you could be stuck on.
Sincerely hoping it helps,
Tim
not. I've often felt like there aren't enough policies in Django,
myself. But pick your battles. This is an easy one. I prefer Django
over Rails, when it comes down to it. Feel fortunate that Django has
practically the best documentation on the planet. I hate more open
source docs, because it was written by a guy who don't know how to use
proper english!
I'm just trying to drive home the point that this isn't the worst
thing that you could be stuck on.
Sincerely hoping it helps,
Tim
Todd Blanchard
Nov 24, 2009, 6:36:40 PM11/24/09
to django...@googlegroups.com
No no no, I really really appreciate the help.
But I'm definitely beginning to feel like my app is 80% boilerplate.
> For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
>
>
But I'm definitely beginning to feel like my app is 80% boilerplate.
>
>
Tim Valenta
Nov 24, 2009, 6:52:30 PM11/24/09
to Django users
Sorry-- I got out of sync with the replies.
> Or am I missing something. Seems like I am getting very much NON-DRY here.
How many pages do you have dozens of forms on? If ever, I find that
I've got a single form on the page. If you're writing an app complex
enough to need such amazingly complicated nested forms.... should you
use the admin, and let it do all that for you?
We're not really working with specifics here, so I'm unsure of what
you're trying to accomplish.
How would you propose we get around this problem? You've got a python
list of form objects. How on earth is Django supposed to know what
variable you've got your forms in? By forcing you to put all your
forms in a single variable, it would make Django dictate too strongly
"the one and only variable which can hold forms". That exactly what
it's trying not to do.
Just set up a template, perhaps "base.html". Make it something like
this:
<html>
<head>
<title>blah</title>
{% block my_media %}
{{ media }}
{% endblock %}
</head>
<body>
{% content %}{% endcontent %}
</body>
</html>
Then, in your views, you'll render the actual template you want to use
(as in, don't render "base.html", render the one that you'd normally
render), but make sure it extends base:
{# mytemplate.html #}
{% extends "base.html" %}
{% block content %}
my content goes here...
<form>
{% endfor %}
</form>
{% endblock %}
The idea is that the 'base.html' template will *always* try to grab
the context variable "media" and render it. That means that all you
ever have to do is make sure that the context variable "media"
contains the cumulative media of what you want to include. Note,
though, that when you want to use this "extends" approach, you become
required to work in those blocks. that's why I put a "content" block
in the base template, and override it in the extended one. Stuff
outside of blocks in mytemplate.html won't get displayed. This is a
very common approach, though, so don't feel like you're getting
cheated.
Then, if you ever want to for whatever reason add more media beyond
the form media, you can either slap it into the 'media' context var in
your view, or you can do that block override I kept using the first
examples:
{# mytemplate.html #}
{% block my_media %}
{{ block.super }}
<script type="text/javascript" src="blahblah/my.js" />
{% endblock %}
{% block content %}
{# continue as usual #}
{% endblock %}
I hope I'm not spouting nonsense that you are already familiar with.
Feel free to ask anything more, if you've got specifics that you're
trying to nail down, design-wise.
Tim
> Or am I missing something. Seems like I am getting very much NON-DRY here.
I've got a single form on the page. If you're writing an app complex
enough to need such amazingly complicated nested forms.... should you
use the admin, and let it do all that for you?
We're not really working with specifics here, so I'm unsure of what
you're trying to accomplish.
How would you propose we get around this problem? You've got a python
list of form objects. How on earth is Django supposed to know what
variable you've got your forms in? By forcing you to put all your
forms in a single variable, it would make Django dictate too strongly
"the one and only variable which can hold forms". That exactly what
it's trying not to do.
Just set up a template, perhaps "base.html". Make it something like
this:
<html>
<head>
<title>blah</title>
{% block my_media %}
{{ media }}
{% endblock %}
</head>
<body>
{% content %}{% endcontent %}
</body>
</html>
Then, in your views, you'll render the actual template you want to use
(as in, don't render "base.html", render the one that you'd normally
render), but make sure it extends base:
{# mytemplate.html #}
{% extends "base.html" %}
{% block content %}
my content goes here...
<form>
{% for form in forms %}
{{ form.as_p }}
{% endfor %}
</form>
{% endblock %}
The idea is that the 'base.html' template will *always* try to grab
the context variable "media" and render it. That means that all you
ever have to do is make sure that the context variable "media"
contains the cumulative media of what you want to include. Note,
though, that when you want to use this "extends" approach, you become
required to work in those blocks. that's why I put a "content" block
in the base template, and override it in the extended one. Stuff
outside of blocks in mytemplate.html won't get displayed. This is a
very common approach, though, so don't feel like you're getting
cheated.
Then, if you ever want to for whatever reason add more media beyond
the form media, you can either slap it into the 'media' context var in
your view, or you can do that block override I kept using the first
examples:
{# mytemplate.html #}
{% block my_media %}
{{ block.super }}
<script type="text/javascript" src="blahblah/my.js" />
{% endblock %}
{% block content %}
{# continue as usual #}
{% endblock %}
I hope I'm not spouting nonsense that you are already familiar with.
Feel free to ask anything more, if you've got specifics that you're
trying to nail down, design-wise.
Tim
Todd Blanchard
Nov 24, 2009, 7:02:52 PM11/24/09
to django...@googlegroups.com
Thanks, I feel like I'm making progress.
Widgets define media too. I'm really fuzzy about how widgets get loaded and how their media declarations get collected into the media object list. (I'm using contrib.gis which has nifty map widgets and it "just works" in the admin but now I'm building my own UI).
In fact, I'm pretty fuzzy in general about how code like widgets gets "found" and loaded.
-Todd Blanchard
> For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
>
>
Widgets define media too. I'm really fuzzy about how widgets get loaded and how their media declarations get collected into the media object list. (I'm using contrib.gis which has nifty map widgets and it "just works" in the admin but now I'm building my own UI).
In fact, I'm pretty fuzzy in general about how code like widgets gets "found" and loaded.
-Todd Blanchard
>
>
Tim Valenta
Nov 24, 2009, 7:04:09 PM11/24/09
to django...@googlegroups.com
The 'media' attribute on forms are actually python proterties
Sent from my iPod; pardon any typos and poor grammar!
>>>>>>> group/django-users?hl=en.
Sent from my iPod; pardon any typos and poor grammar!
>>>
>>>> --
>>>
>>>> You received this message because you are subscribed to the
>>>> Google Groups "Django users" group.
>>>> To post to this group, send email to django...@googlegroups.com.
>>>> To unsubscribe from this group, send email to django-users...@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...@googlegroups.com.
>>>> To unsubscribe from this group, send email to django-users...@googlegroups.com
>>>> .
>>>> For more options, visit this group athttp://groups.google.com/
>>
>> --
>>
>> You received this message because you are subscribed to the Google
>> Groups "Django users" group.
>> To post to this group, send email to django...@googlegroups.com.
>> To unsubscribe from this group, send email to django-users...@googlegroups.com
>> .
>> --
>>
>> You received this message because you are subscribed to the Google
>> Groups "Django users" group.
>> To post to this group, send email to django...@googlegroups.com.
>> To unsubscribe from this group, send email to django-users...@googlegroups.com
>> .
>> For more options, visit this group at http://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...@googlegroups.com.
> To unsubscribe from this group, send email to django-users...@googlegroups.com
> .
>
> You received this message because you are subscribed to the Google
> Groups "Django users" group.
> To post to this group, send email to django...@googlegroups.com.
> To unsubscribe from this group, send email to django-users...@googlegroups.com
> .
Tim Valenta
Nov 24, 2009, 7:06:20 PM11/24/09
to django...@googlegroups.com
Oops damn 'send' button on the iPod.
The media attribute is a python property which aggregates all widget
media. So everything is simplified to just using myform.media.
Widgets are specified on form fields, if you want to change it from
the default widget.
Sent from my iPod; pardon any typos and poor grammar!
On Nov 24, 2009, at 5:02 PM, Todd Blanchard <tblan...@mac.com> wrote:
>>>>>>> group/django-users?hl=en.
The media attribute is a python property which aggregates all widget
media. So everything is simplified to just using myform.media.
Widgets are specified on form fields, if you want to change it from
the default widget.
Sent from my iPod; pardon any typos and poor grammar!
On Nov 24, 2009, at 5:02 PM, Todd Blanchard <tblan...@mac.com> wrote:
>>>
>>>> --
>>>
>>>> You received this message because you are subscribed to the
>>>> Google Groups "Django users" group.
>>>> To post to this group, send email to django...@googlegroups.com.
>>>> To unsubscribe from this group, send email to django-users...@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...@googlegroups.com.
>>>> To unsubscribe from this group, send email to django-users...@googlegroups.com
>>>> .
>>>> For more options, visit this group athttp://groups.google.com/
>>
>> --
>>
>> You received this message because you are subscribed to the Google
>> Groups "Django users" group.
>> To post to this group, send email to django...@googlegroups.com.
>> To unsubscribe from this group, send email to django-users...@googlegroups.com
>> .
>> --
>>
>> You received this message because you are subscribed to the Google
>> Groups "Django users" group.
>> To post to this group, send email to django...@googlegroups.com.
>> To unsubscribe from this group, send email to django-users...@googlegroups.com
>> .
>> For more options, visit this group at http://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...@googlegroups.com.
> To unsubscribe from this group, send email to django-users...@googlegroups.com
> .
>
> You received this message because you are subscribed to the Google
> Groups "Django users" group.
> To post to this group, send email to django...@googlegroups.com.
> To unsubscribe from this group, send email to django-users...@googlegroups.com
> .
Reply all
Reply to author
Forward
0 new messages