MEDIA_URL template tag/context processor/etc again

[Simon G.]

Evening all,

There's been a long history of people asking for some way of easily
using the MEDIA_URL setting in templates. At a quick glance, I get
#1278, #3818, #2532, and #4105.

These have all been marked wontfix, and I closed this last one to
match. The reasoning for the wontfix is that this leads to a slippery
slope of adding everything to the context and it's also quite easy to
implement this on your own.

However, given the frequency of this request (I've seen it raised a
few times in django-users too), I figured I'd ask if core's still
against this, or whether we want to accept one of these.

--Simon

[Amr Mostafa]

If I understand correctly and context bloat is the problem, I'd like
to point that my patch at #4105 doesn't have this problem as it gives
a tag instead, to be used like this:

{% media "path/to/media/file.xyz" %}

Cheers,
- Amr

[SmileyChris]

I'm still convinced this is a very common use-case.

I like Amr's take on it:
We don't introduce any context bloating
We don't require templates to use RequestContext

[lgespee]

I am new to Django, just using it 10 days.
I wanted to use images the end user can upload for a certain model,
and then list those images with some information on a page, much like
a gallery.
However the URL I get from the field points to a subdir of the
MEDIA_ROOT, to convert them to usable URLs in my templates I need to
know the MEDIA_URL.
Cause hardcoding them into the templates is against all logic.

I vote for some way by default to easily access the MEDIA_URL
constant, others from the settings file are not needed, but this one
is.
It's needed for CSS files, ImageFields, FileFields, etc, etc.

[sime]

Yes it really does need to be there! Out of the box.

It's omission contradicts the whole concept of serving media
separately; not to mention being an unnecessary 'what the ?' hurdle
for newcomers.

[Adrian Holovaty]

Given the frequency of this request, I'm OK with adding a context
processor in django/core/context_processors.py that sets a "MEDIA_URL"
variable in the context. I'm also OK with having that be in the
default TEMPLATE_CONTEXT_PROCESSORS. What do other folks think?

Adrian

--
Adrian Holovaty
holovaty.com | djangoproject.com

[Malcolm Tredinnick]

I'm fine with it.

Malcolm

[Marc Fargas]

El vie, 25-05-2007 a las 03:20 -0500, Adrian Holovaty escribió:
> Given the frequency of this request, I'm OK with adding a context
> processor in django/core/context_processors.py that sets a "MEDIA_URL"
> variable in the context. I'm also OK with having that be in the
> default TEMPLATE_CONTEXT_PROCESSORS. What do other folks think?

I thought you'd prefer the templatetag approach from #4105 .
For most of the world, me included, we don't care on which approach is
taken as long as there's some way to get MEDIA_URL on the templates ;))

Cheers,
Marc

[lgespee]

Adrian,

Thanks!

I think having it in the TEMPLATE_CONTEXT_PROCESSORS would be great.

[James Bennett]

On 5/25/07, Adrian Holovaty <holo...@gmail.com> wrote:
> Given the frequency of this request, I'm OK with adding a context
> processor in django/core/context_processors.py that sets a "MEDIA_URL"
> variable in the context. I'm also OK with having that be in the
> default TEMPLATE_CONTEXT_PROCESSORS. What do other folks think?

Fine with me. There's even a patch on #1278 which does this and documents it :)

--
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."

[SmileyChris]

I'm more convinced that #4105 is a better way (primarily because it
doesn't introduce the requirement of using RequestContext and add
another variable to the context namespace). But hey, like Marc says -
anything's better than what we have now! :)

On May 26, 3:15 am, "James Bennett" <ubernost...@gmail.com> wrote:

[Russell Keith-Magee]

On 5/25/07, Adrian Holovaty <holo...@gmail.com> wrote:
>

> Given the frequency of this request, I'm OK with adding a context
> processor in django/core/context_processors.py that sets a "MEDIA_URL"
> variable in the context. I'm also OK with having that be in the
> default TEMPLATE_CONTEXT_PROCESSORS. What do other folks think?

Fine by me.

Russ %-)

[Marc Fargas]

My count at the end of the thread is:
#1278: 4 votes
#4105: 4 votes

So I thow a coin to the air... oh, it felt off the window!

As the main issue with having media_url in templates what the context
bloat we could go for the #4105 approach, but as recently Adrian told
he's fine on having the context bloat on this specific issue we could go
for #1278, but as the thread was about #4105 we could go for it, but as
#1278 is older we could go for it...

Anyway, one anying thing for newcomers is that they have no way to
easily have MEDIA_URL on their templates so their templates can have
lots of bad urls (imagine you have all media prefixed with / :)) so we
could try to get either 1278 or 4105 checked in.

The other issue with 1278 is that you'll have to use RequestContext
around, so I'd go for 4105 and it's which I'm using now on my projects.

Could somebody with a bright mind and far much more expirience than me
throw the coin? ;))

Cheers,
Marc

[SmileyChris]

It would be great to hear from some of the previous "voters" in this
thread on their view of #4105 (as opposed to #1278)

On May 29, 4:48 am, Marc Fargas <teleni...@telenieko.com> wrote:
> My count at the end of the thread is:
> #1278: 4 votes
> #4105: 4 votes
>
> So I thow a coin to the air... oh, it felt off the window!
>
> As the main issue with having media_url in templates what the context
> bloat we could go for the #4105 approach, but as recently Adrian told
> he's fine on having the context bloat on this specific issue we could go
> for #1278, but as the thread was about #4105 we could go for it, but as
> #1278 is older we could go for it...
>
> Anyway, one anying thing for newcomers is that they have no way to
> easily have MEDIA_URL on their templates so their templates can have
> lots of bad urls (imagine you have all media prefixed with / :)) so we
> could try to get either 1278 or 4105 checked in.
>
> The other issue with 1278 is that you'll have to use RequestContext
> around, so I'd go for 4105 and it's which I'm using now on my projects.
>
> Could somebody with a bright mind and far much more expirience than me
> throw the coin? ;))
>
> Cheers,
> Marc
>

> El mi?, 25-04-2007 a las 04:33 -0700, Simon G. escribi?:

[Russell Keith-Magee]

On 5/29/07, Marc Fargas <tele...@telenieko.com> wrote:
>
> My count at the end of the thread is:
> #1278: 4 votes
> #4105: 4 votes
>
> So I thow a coin to the air... oh, it felt off the window!

That's not the count I'm reading from this thread:

For #1278:
- Adrian
- Malcolm
- James Bennett
- myself
- Igespee

For #4105:
- Amr Mostafa
- SmileyChris
- Mark Fargas

Unclear opinion
- simon@slicmedia

I make that 5:3 - and not wanting to put a jackboot down on the throat
of democracy, but #1278 has the support of 4 core developers,
including the BDFL.

Yours,
Russ Magee %-)

[Russell Keith-Magee]

On 5/29/07, SmileyChris <smile...@gmail.com> wrote:
>
> It would be great to hear from some of the previous "voters" in this
> thread on their view of #4105 (as opposed to #1278)

Here's a few:

- It's one context variable. Hardly bloat - we just need to avoid the
temptation of trying to include settings.* into the context.

- Proliferation of single purpose default template tags is just as big
a problem as context bloat

- If you don't want MEDIA_URL messing up your context, you can always
take out the context processor. Taking the tag out of the node parsing
set isn't as easy.

- RequestContext is the 95% case, and putting MEDIA_URL in
RequestContext doesn't prohibit you from putting the variable into
your manually constructed Context. Plus, if you're using a raw
Context, you're already taking responsibility for manually
constructing your Context to suit your specific needs.

- {% %} tags are for the most part 'dynamic' operations - loops,
dynamic string construction, comparisons, complex logic based on
inputs, etc. {% media %} is essentially nothing more than a string
concatenation, which is exactly what {{ MEDIA_URL }} substitution
does.

- I don't have any performance data to back me up, but my gut reaction
is that {% %} template tags will take (marginally) longer to parse and
process than a simple {{}} inclusion, especially on repeated use.

Yours,
Russ Magee %-)

[Malcolm Tredinnick]

To be accurate (not that it really matters), I wasn't voting for any
particular ticket, but I was in favour of Adrian's much more limited
concept: exposing MEDIA_URL in the context (which seems to be less than
#1278). But I'm in agreement with Russell that a single context variable
is better than a template tag.

The discussion is about a feature, not a particular ticket.

Regards,
Malcolm

[SmileyChris]

On May 29, 12:32 pm, "Russell Keith-Magee" <freakboy3...@gmail.com>
wrote:

> On 5/29/07, SmileyChris <smileych...@gmail.com> wrote:
> > It would be great to hear from some of the previous "voters" in this
> > thread on their view of #4105 (as opposed to #1278)
>
> Here's a few:

Thanks Russ, that's what I was after. I just thought it was important
that there was some discussion about the specific differences between
potential implementations, since the general concept has been
accepted.

I'm happy with either ticket.

[sime]

> Unclear opinion
> - simon@slicmedia

I'm a definite +1 on this, whether it's {{ MEDIA_URL }} or {%
MEDIA_URL %} I don't mind.

Lets not forget though, it's a VERY common case to have more than just
MEDIA_URL being needed from settings.py. Obviously not all of it
though. I seem to recall SmileyChris had some good ideas that covered
this side of things too?

[Ville Säävuori]

> Given the frequency of this request, I'm OK with adding a context
> processor in django/core/context_processors.py that sets a "MEDIA_URL"
> variable in the context. I'm also OK with having that be in the
> default TEMPLATE_CONTEXT_PROCESSORS. What do other folks think?

I'm very much +1 on this.

As some have already noted, many projects depend on more than one
MEDIA_URL, but I don't see that as a major problem. Experienced
developers can very easily put anything they want to default context
processors -- and take off the default MEDIA_URL, if needed.

I think adding MEDIA_URL to context as a default would be important as
a sign of best practices. I have seen _many_ Django projects out in
the wild that are hardlinking their media files in the templates. In
addition of being very poor practise in general, that also pretty much
kills the chance of doing local off-line development (which is a GREAT
aspect of Django -- at least for me).

After all, Django is a web framework for perfecionists, so I think
that encouraging best practices would definitely be a good thing :)

[Collin Grady]

+1 on #1278 :)

I think RequestContext is the better way of doing it - I think
MEDIA_URL is every bit as common to use as the user info provided by
the auth context processor, and that wasn't done with a tag either :)

[Marc Fargas]

El mar, 29-05-2007 a las 08:15 +0800, Russell Keith-Magee escribió:
> I make that 5:3 - and not wanting to put a jackboot down on the throat
> of democracy, but #1278 has the support of 4 core developers,
> including the BDFL.

I never was good at maths :) And I didn't perform a really well measured
calculation :)

Anyway, now it's clear that we should go for {{ MEDIA_URL }} which means
that in a near future we'll have MEDIA_URL in templates, hurray! :)

Cheers,
Marc

[Steven Armstrong]

Simon G. wrote on 04/25/07 13:33:

+1 for #3818

I've been using a similar context processor for a while.

I prefer such an approach over something like #1278 as the
developer/administrator chooses which settings to expose instead of the
template designer.

Also it's more generic and can be reused for your own apps/settings.

Just my 0.02

cheers
Steven

[Russell Keith-Magee]

On 5/29/07, Marc Fargas <tele...@telenieko.com> wrote:
>

> Anyway, now it's clear that we should go for {{ MEDIA_URL }} which means
> that in a near future we'll have MEDIA_URL in templates, hurray! :)

Committed in [5379].

Yours,
Russ Magee %-)