Hi Mikhail,
On Sat, Oct 30, 2010 at 1:22 PM, Mikhail Korobov wrote:
> Hi Waldemar,
>
> The problem was really hard to understand for me because I was
> assuming you're trying to describe django.contrib.staticfiles flaw
> while you were describing the problem with third-party asset managers.
It s
Hi Waldemar,
The problem was really hard to understand for me because I was
assuming you're trying to describe django.contrib.staticfiles flaw
while you were describing the problem with third-party asset managers.
I think you have described a real problem here but (as you said) this
problem is no
Hi Yuri,
On Sat, Oct 30, 2010 at 1:22 PM, burc...@gmail.com wrote:
> Hi Waldemar,
>
> So, we agreed, it's not a problem with django, it's problem with those
> 3rd-party apps.
Yes, exactly! That's why I wanted an official standard that all
3rd-party apps can follow.
> Perhaps, you can write emai
Hi Waldemar,
So, we agreed, it's not a problem with django, it's problem with those
3rd-party apps.
Perhaps, you can write emails to their authors now explaining your position?
Actually, it's not a problem that 70% of those apps are broken -- in
other areas, the percent of "wrong" solutions can b
On Fri, Oct 29, 2010 at 10:32 PM, Jacob Kaplan-Moss wrote:
> There's no way I'm adding text like that to the staticfiles
> documentation. Not in a million years. It's confusing to me, and
> *I've* been following this discussion. Can you imagine how confusing
> that's going to be to people who *hav
On Fri, Oct 29, 2010 at 11:26 AM, Waldemar Kornewald
wrote:
> (see attachment which "implements" method (2) :).
OK.
For the record, I really don't want to be a dick here, but I think
what follows comes across that way. I'm quite sorry for not being able
to communicate myself in a less jerk-y way
Hi Carl,
On Fri, Oct 29, 2010 at 7:41 PM, Carl Meyer wrote:
> Hi Waldemar,
>
> On Oct 29, 3:05 am, Waldemar Kornewald wrote:
>> Just to clarify: We are in fact talking about two questions here:
>> 1. Do we need a standard for URL handling?
>>
>> This is the most important question and my answer
Hi Waldemar,
On Oct 29, 3:05 am, Waldemar Kornewald wrote:
> Just to clarify: We are in fact talking about two questions here:
> 1. Do we need a standard for URL handling?
>
> This is the most important question and my answer is "yes" (I'll
> explain this in the rest of this mail).
I don't think
Hi Jacob,
On Fri, Oct 29, 2010 at 4:58 PM, Jacob Kaplan-Moss wrote:
> Hi Waldemar --
>
> Like a few in this thread, I'm really having trouble understanding
> exactly what you're proposing. I think the best thing, then, would be
> if you could write some code to do whatever it is you'd like.
>
> J
Hi Waldemar --
Like a few in this thread, I'm really having trouble understanding
exactly what you're proposing. I think the best thing, then, would be
if you could write some code to do whatever it is you'd like.
Just a proof-of-concept is totally fine -- I don't mean to ask you to
invest a lot
I agree, if you want to compress/combine css javascript whatever it's
up to the app/tool that does this to fix relative paths and other
issues that arrise when compressing/combining files.
It has nothing to do with the serving of the files.
On Oct 29, 12:04 pm, "burc...@gmail.com" wrote:
> Hi Wal
Hi Waldemar,
> A standard for a problem related to Django: How can we have reusable
> apps that come with media files? How is that possible if everyone uses
> a different asset manager?
Ok, this is a problem related to Django, but it shouldn't be solved
with scope of Django because nothing in Djan
Hi Yuri,
On Fri, Oct 29, 2010 at 12:04 PM, burc...@gmail.com wrote:
> Hi Waldemar,
>
> On Fri, Oct 29, 2010 at 4:19 PM, Waldemar Kornewald
> wrote:
>> Hi Yuri,
>>
>> On Fri, Oct 29, 2010 at 10:37 AM, burc...@gmail.com
>> wrote:
>>> Hi Waldemar,
>>>
>>> On Fri, Oct 29, 2010 at 2:05 PM, Waldemar
Hi Waldemar,
On Fri, Oct 29, 2010 at 4:19 PM, Waldemar Kornewald
wrote:
> Hi Yuri,
>
> On Fri, Oct 29, 2010 at 10:37 AM, burc...@gmail.com wrote:
>> Hi Waldemar,
>>
>> On Fri, Oct 29, 2010 at 2:05 PM, Waldemar Kornewald
>> wrote:
>>> Hi Carl,
>>>
As I read it, your option 4 means putting U
Hi Yuri,
On Fri, Oct 29, 2010 at 10:37 AM, burc...@gmail.com wrote:
> Hi Waldemar,
>
> On Fri, Oct 29, 2010 at 2:05 PM, Waldemar Kornewald
> wrote:
>> Hi Carl,
>>
>>> As I read it, your option 4 means putting URLs into CSS files that
>>> will not resolve correctly if static files are served dire
Hi Waldemar,
On Fri, Oct 29, 2010 at 2:05 PM, Waldemar Kornewald
wrote:
> Hi Carl,
>
>> As I read it, your option 4 means putting URLs into CSS files that
>> will not resolve correctly if static files are served directly,
>> unmodified, from their source locations (after being collected from
>> a
Hi Carl,
On Fri, Oct 29, 2010 at 5:18 AM, Carl Meyer wrote:
> Hi Waldemar,
>
> Thanks for putting so much thought into this issue, and outlining
> these options in detail. However, I am not convinced that this
> something Django core should be concerned with. I think we need to
> maintain a clear
Hi Waldemar,
Thanks for putting so much thought into this issue, and outlining
these options in detail. However, I am not convinced that this
something Django core should be concerned with. I think we need to
maintain a clearer conceptual separation between the various layers of
functionality here
On Thu, Oct 28, 2010 at 4:41 PM, Waldemar Kornewald
wrote:
> What's the problem with all of this? Code written for (1) is
> incompatible with code written for (2) which is incompatible with code
> written for (4). The asset managers listed on djangopackages use any
> of those three methods. There
Hi Yuri,
On Thu, Oct 28, 2010 at 3:18 PM, burc...@gmail.com wrote:
> Hi Waldemar,
>
> it seems I just don't get what does "relative to" mean in your (1)-(4).
> Could you please explain better, what do you mean by that?
> Starting with what path does your "css/main.css" have?
> I think you've miss
Hi Waldemar,
it seems I just don't get what does "relative to" mean in your (1)-(4).
Could you please explain better, what do you mean by that?
Starting with what path does your "css/main.css" have?
I think you've missed some important bits in your explanations, or
just not covering every possible
Hi Yuri,
On Thu, Oct 28, 2010 at 6:19 AM, burc...@gmail.com wrote:
> Hi Waldemar,
>
> On Wed, Oct 27, 2010 at 9:05 PM, Waldemar Kornewald
> wrote:
>> 2010/10/27 Mikhail Korobov :
>>> Why isn't it fine to have different URL rewriting schemes for
>>> different assets bundlers?
>>
>> OK, sorry for
Hi Waldemar,
On Wed, Oct 27, 2010 at 9:05 PM, Waldemar Kornewald
wrote:
> 2010/10/27 Mikhail Korobov :
>> Why isn't it fine to have different URL rewriting schemes for
>> different assets bundlers?
>
> OK, sorry for not having explained it well. What I mean is this:
> Imagine this code snippet in
2010/10/27 Mikhail Korobov :
> Why isn't it fine to have different URL rewriting schemes for
> different assets bundlers?
OK, sorry for not having explained it well. What I mean is this:
Imagine this code snippet in a reusable app's CSS file:
/* myapp/style.css */
div.icon {
background-image: u
Why isn't it fine to have different URL rewriting schemes for
different assets bundlers?
E.g. if one uses django-compress he should list all files he wants to
combine in settings.py and then output them into template as {%
compressed_css 'my_css' %}. If one is using django-compressor then he
list
Hi Mikhail,
On Wed, Oct 27, 2010 at 1:14 PM, Mikhail Korobov wrote:
> Hi Waldemar,
>
> Could you explain why is this should belong to django staticfiles app?
> This app has nothing to do with combining css files. It has one view
> (django.contrib.staticfiles.views.serve) in order to serve files i
Hi Waldemar,
Could you explain why is this should belong to django staticfiles app?
This app has nothing to do with combining css files. It has one view
(django.contrib.staticfiles.views.serve) in order to serve files in
development. This is only a helper view used in development and I
don't see w
On Thu, Oct 21, 2010 at 10:10 PM, Waldemar Kornewald
wrote:
> OK, I just went through django-mediagenerator to check if there's
> anything else needed by staticfiles and I noticed that we need to have
> a standard for URLs in CSS files (e.g., url(image.png)).
>
> Since we don't know the STATICFILE
On Thu, Oct 21, 2010 at 9:04 PM, Jacob Kaplan-Moss wrote:
> On Thu, Oct 21, 2010 at 1:25 PM, Waldemar Kornewald
> wrote:
>> Thanks a lot for the clarification. So, then the "bad batteries" part
>> in Eric's talk "Why Django sucks and how we can fix it" doesn't
>> receive much agreement within the
On Thu, Oct 21, 2010 at 10:48 PM, Luke Plant wrote:
> On Thu, 2010-10-21 at 20:25 +0200, Waldemar Kornewald wrote:
>
> To fully support one of the other assets managers you mention, we would
> need the admin and all contrib apps to get on board and use the template
> tags etc. This would be a much
On Thu, Oct 21, 2010 at 11:43 PM, Jannis Leidel wrote:
>> Is staticfiles supposed to put "app/static/style.css" into
>> "/style.css" or "/app/style.css"? Currently it behaves
>> like the latter, but if it should behave like Django's templates we
>> need to fix the code.
>
> The latter is correct.
On Thu, Oct 21, 2010 at 10:04 PM, Jacob Kaplan-Moss wrote:
> On Thu, Oct 21, 2010 at 1:25 PM, Waldemar Kornewald
> wrote:
>> My proposal would've been to not add staticfiles in the first place,
>> but it seems to be too late, now.
>
> If you think reverting the commit's a good idea, please feel f
> Is staticfiles supposed to put "app/static/style.css" into
> "/style.css" or "/app/style.css"? Currently it behaves
> like the latter, but if it should behave like Django's templates we
> need to fix the code.
The latter is correct. E.g. files from apps (/static/*) will be collected
at the same
On Thu, 2010-10-21 at 20:25 +0200, Waldemar Kornewald wrote:
> My proposal would've been to not add staticfiles in the first place,
> but it seems to be too late, now. From what I can see, only the
> finder/storage API looks fully reusable. More advanced asset managers
> will use custom templateta
On Thu, Oct 21, 2010 at 10:09 PM, Jacob Kaplan-Moss wrote:
> On Thu, Oct 21, 2010 at 2:33 PM, Tobias McNulty
> wrote:
>> Ah, so realistically we should put all our media in 'static/', like
>> for templates, if we want to avoid conflicts with other apps. Would that be
>> worth mentioning as a co
On Thu, Oct 21, 2010 at 7:20 PM, flo...@gmail.com wrote:
> I think staticfiles is an *excellent* contribution, and if there is
> some advanced use case that it doesn't do, then let's do our best to
> make it extensible enough to make that use case possible. Easy things
> (like bundling media with
On Thu, Oct 21, 2010 at 2:33 PM, Tobias McNulty wrote:
> What's the argument against serving the original files directly?
It means that when you add new apps you have to update your
Apache/Nginx/whatever config. Back in the day (pre-open-source), every
time you added an app you had to edit your A
On Thu, Oct 21, 2010 at 1:25 PM, Waldemar Kornewald
wrote:
> Thanks a lot for the clarification. So, then the "bad batteries" part
> in Eric's talk "Why Django sucks and how we can fix it" doesn't
> receive much agreement within the Django core team?
I think that's kind of irrelevant: people comp
On Thu, Oct 21, 2010 at 11:58 AM, Jacob Kaplan-Moss wrote:
> On Thu, Oct 21, 2010 at 10:44 AM, Tobias McNulty
> wrote:
> > I think the issue is that the commit has already been made, and that
> doesn't
> > feel like the right time to anyone to submit an alternate proposal.
>
> Well, that's why we
Hi Jakob,
On Thu, Oct 21, 2010 at 5:10 PM, Jacob Kaplan-Moss wrote:
> On Thu, Oct 21, 2010 at 3:50 AM, Waldemar Kornewald
> wrote:
>> With this reasoning we could as well add django-debug-toolbar, South,
>> django-registration and many other popular apps. What makes
>> staticfiles different? Ser
It seems like everyone's talking about two different things here:
1) Should Django add more apps to contrib?
2) Does staticfiles solve a real need that users of Django have
today? Is it the de-facto implementation of a common pattern?
Let's just drop the discussion of the first point for the pur
On Thu, Oct 21, 2010 at 10:44 AM, Tobias McNulty wrote:
> I think the issue is that the commit has already been made, and that doesn't
> feel like the right time to anyone to submit an alternate proposal.
Well, that's why we use revision control: if there's a rough consensus
that a commit was a m
On Thu, Oct 21, 2010 at 11:01 AM, Jacob Kaplan-Moss wrote:
> On Thu, Oct 21, 2010 at 8:19 AM, Tobias McNulty
> wrote:
> > That thread's pretty old and doesn't really end on anything conclusive
> other
> > than "work has started". I do see that the patch was updated numerous
> times
> > on the ti
On 10/21/10 11:10 AM, "Jacob Kaplan-Moss" wrote:
> On Thu, Oct 21, 2010 at 3:50 AM, Waldemar Kornewald
> wrote:
>> With this reasoning we could as well add django-debug-toolbar, South,
>> django-registration and many other popular apps. What makes
>> staticfiles different? Seriously, I don't see
On Thu, Oct 21, 2010 at 3:50 AM, Waldemar Kornewald
wrote:
> With this reasoning we could as well add django-debug-toolbar, South,
> django-registration and many other popular apps. What makes
> staticfiles different? Seriously, I don't see it.
Jannis proposed that we add static files in. Brian c
On Thu, Oct 21, 2010 at 8:19 AM, Tobias McNulty wrote:
> That thread's pretty old and doesn't really end on anything conclusive other
> than "work has started". I do see that the patch was updated numerous times
> on the ticket [1] this month, but was there an associated review on the
> mailing l
On Thu, Oct 21, 2010 at 8:54 AM, Dougal Matthews wrote:
> On 21 October 2010 13:41, Tobias McNulty wrote:
>
>> is there another mailing list thread or wiki page somewhere that follows
>> or summarizes the decisions that went into django.contrib.staticfiles? I
>> think pointing to the fact that
On 21 October 2010 13:41, Tobias McNulty wrote:
> is there another mailing list thread or wiki page somewhere that follows
> or summarizes the decisions that went into django.contrib.staticfiles? I
> think pointing to the fact that such a process has already happened would
> also resolve a lot
On Thu, Oct 21, 2010 at 5:27 AM, James Bennett wrote:
> In the future, it may well turn out that people will commonly need
> much more than what the current iteration of staticfiles provides. But
> we can't cross that bridge until we come to it; for now, staticfiles
> solves the common version of
On Thu, Oct 21, 2010 at 3:50 AM, Waldemar Kornewald
wrote:
> It's not even future-proof. We're heading towards larger client-side
> web apps which means there will be HTML5 offline manifests and apps
> consisting of more than 50 files. Even the combination of
> django_compressor with staticfiles c
On Thu, Oct 21, 2010 at 5:25 AM, Jannis Leidel wrote:
>> The core 'django.views.static.serve' and
>> 'django.core.context_processors.media' are deprecated in favor of the
>> staticfiles equivalents in contrib. Is the idea that the contrib app is a
>> stepping stone to providing core functionali
I think that staticfiles in contrib is a good idea because with it
authors of reusable apps have an answer for the "How should user
install app's static files?" question. They already know how to make
python code and django templates available, but static files was a bit
of pain before. Now the puz
On Thu, Oct 21, 2010 at 12:25 PM, Jannis Leidel wrote:
> Ian,
>
> > I thought about this too and had a long thread on Twitter with jezdez
> about staticfiles. It occurred to me that adding more apps to contrib was
> kind of a bad idea. I know "everyone" uses admin etc. but I was of the
> understa
Ian,
> I thought about this too and had a long thread on Twitter with jezdez about
> staticfiles. It occurred to me that adding more apps to contrib was kind of a
> bad idea. I know "everyone" uses admin etc. but I was of the understanding
> that contrib apps are optional apps for django but st
On Thu, Oct 21, 2010 at 2:40 AM, Waldemar Kornewald wrote:
> Today the staticfiles contrib app was committed to trunk. This got me
> wondering: Wasn't there recently a discussion about how "contrib" is a
> bad idea and all apps should either be in core or live as separate
> projects? Is staticfile
On Wed, Oct 20, 2010 at 10:13 PM, Jacob Kaplan-Moss wrote:
> On Wed, Oct 20, 2010 at 3:04 PM, Waldemar Kornewald
> wrote:
>> I wish that were the case. The staticfiles documentation says:
>>
>> """
>> Remember to run :djadmin:`collectstatic` when your media changes;
>> the view only serves static
Hi Carl,
On Wed, Oct 20, 2010 at 10:53 PM, Carl Meyer wrote:
> Hi Waldemar,
>
> On Oct 20, 4:04 pm, Waldemar Kornewald wrote:
>> That's a funny combination of tools. :)
>> You don't really need django-staticfiles because in your case
>> django_compressor takes care of collecting assets (i.e. it
Hi Waldemar,
On Oct 20, 4:04 pm, Waldemar Kornewald wrote:
> In what way does staticfiles make writing reusable apps easier? It
> merely collects apps' "static" folders. The same thing could be
> achieved by defining a simple standard:
> "Put media files in the 'media' folder."
> and then making
On Wed, Oct 20, 2010 at 3:04 PM, Waldemar Kornewald
wrote:
> I wish that were the case. The staticfiles documentation says:
>
> """
> Remember to run :djadmin:`collectstatic` when your media changes;
> the view only serves static files that have been collected.
> """
I actually wrote that without
Hi Carl,
On Wed, Oct 20, 2010 at 8:55 PM, Carl Meyer wrote:
> Hi Waldemar,
>
> On Oct 20, 1:40 pm, Waldemar Kornewald wrote:
> [snip]
>> However, what staticfiles does has almost nothing to do with "bigger
>> project" asset management. Just look at the features grid on
>> djangopackages (disclai
I agree with Carl,
> Staticfiles has a very specific, well-defined purpose (collecting media
> files from apps), which fills a major hole in the Django "story" for
> reusable apps.
IMHO contrib apps should have the following characteristics (and probably
more):
* Solves a problem that can be des
Hi Waldemar,
On Oct 20, 1:40 pm, Waldemar Kornewald wrote:
[snip]
> However, what staticfiles does has almost nothing to do with "bigger
> project" asset management. Just look at the features grid on
> djangopackages (disclaimer: I'm the author of django-mediagenerator
> and I maintain that grid)
62 matches
Mail list logo
