On Sep 16, 11:05 pm, Brian Beck <[EMAIL PROTECTED]> wrote:
> On Sep 16, 10:49 pm, "Rajeev J Sebastian" <[EMAIL PROTECTED]>
> wrote:
>
> > A problem would be referencing images, and media in css/js files.
> > Currently, in all our projects we use /site_media/ as the MEDIA_URL,
> > so this not a problem. But for a true solution, there should be a
> > preprocessor for css/js to use the MEDIA_URL within it.
>
> CSS can refer to images by their path relative to the CSS file, so if
> your media tree looks like:
>
> media/css/base.css
> media/images/icon.png
>
> Then base.css can do: background-image('../images/icon.png')
>
> ...so no preprocessing needed there.  But referring to *another app's*
> images is another story.  And JavaScript... well, don't reference
> images in JavaScript.

We use the convention that there should be a Javascript variable
called MEDIA_URL defined somewhere in a base template that lets
Javascript access it; seems like this might be a useful convention to
adopt.

> > Another problem which we havent solved, is overrides. E.g., when we
> > use a "plugabble"/reusable app with its own media, and we want to
> > override this in our project, how should the collect media command
> > work ?
>
> I imagined this working just like templates.  By *convention* apps can
> lay out their media directories like media/appname.  So there's
> nothing stopping your app from including, say, media/anotherapp/css/
> base.css, and we can say that whichever app is in INSTALLED_APPS first
> wins, just like with templates.

For CSS, there's a couple ways that this might possible. Let's say
myapp wants to distribute some default CSS; then it could actually
provide two separate files:

myapp/media/myapp/css/style_base.css:

#myapp div.something {
    /* custom styles for the app */
}

myapp/media/myapp/css/style.css:

@import url(./style_base.css);

This way, the project using the app can customize the CSS or replace/
exclude it completely (by excluding the import line), without having
to change anything inside myapp proper. django-compress might be
useful in this situation; it could automatically parse the @imports in
CSS and generate a compressed version including the right files.

I'm not sure though that all of this is worth it; it seems like we're
trying to optimize for the case where somebody a user simply drops an
app into their project, runs installmedia, and never customizes
anything beyond that. In reality, the templates and CSS are most
likely going to be customized (although JS is another story), so maybe
this sort of "inheritance" isn't really needed.

Which reminds me - I think it would be really nice if there was some
sort of script/style manager in Django (similar to the django.forms
media):

{% extends 'base.html' %}

{% css 'myapp/css/stuff.css' 'myapp/css/morestuff.css' %}
{% js 'myapp/js/stuff.js' %}

{% block content %}
   ...
{% endblock %}

and then in the base template

<html>
<head>
{% css %}
{% js %}
</head>
<body>
{% block content %}{% endblock %}
</body>
</html>

Django could then even check in a list of directories to find the
appropriate files (similar to the way template lookups work now) and
include the first one found.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to