Hi Jannis, although much work, I would find that brilliant.
On Thursday, 2 October 2014 08:47:13 UTC+2, Jannis Leidel wrote:
>
>
> "If something like that were be tried I would also recommend to fix the
> ambiguity with regard to “media” and “static” by renaming the first to
> “uploads”."
>
> J
On 2 oct. 2014, at 09:36, Curtis Maloney wrote:
> I tend to characterise them as :
>
> static -- What is an integral part of your site. What you keep in source
> control, and is required for the site to function.
>
> media -- what happens as a result of your site functioning.
I have two shor
Hi,
Am Thu, 2 Oct 2014 08:46:26 +0200
schrieb Jannis Leidel :
> If something like that were be tried I would also recommend to fix
> the ambiguity with regard to “media” and “static” by renaming the
> first to “uploads”.
>
> What do others think about that idea? Too much effort for little
> gain?
On 2 October 2014 16:46, Jannis Leidel wrote:
>
> On 01 Oct 2014, at 14:33, Collin Anderson wrote:
>
> > In hindsight I regret not having pushed harder for integration of
> staticfiles into core instead, lots of confusion could have been prevented,
> IMO.
> >
> > Is it too late to move to core?
On 01 Oct 2014, at 14:33, Collin Anderson wrote:
> In hindsight I regret not having pushed harder for integration of staticfiles
> into core instead, lots of confusion could have been prevented, IMO.
>
> Is it too late to move to core?
Good question, if we’d left the public API in django.con
>
> In hindsight I regret not having pushed harder for integration of
> staticfiles into core instead, lots of confusion could have been prevented,
> IMO.
>
Is it too late to move to core?
--
You received this message because you are subscribed to the Google Groups
"Django developers (Cont
On 29 Sep 2014, at 22:46, Jeremy Dunck wrote:
> Right now, I think that static/media handling is fairly confused in the
> documentation, and a bit confused in the code itself.
Please make sure to open tickets about this, I've long lost the ability to see
at this code from the beginners perspe
Aymeric,
That's an interesting idea I hadn't considered -- perhaps storages could
also then be marked trusted and untrusted, and processing/display of those
files could take it into consideration. I agree the security requirements
are different.
Florian,
I agree that changing APIs would cause
Hi Jeremy,
That could be useful for any website that gets some of its assets from the code
(JS, CSS), others from a CDN (eg. product photos), others from another CDN (eg.
tutorial illustrations), etc. However we'd have to make sure it beats the
common solution of having a model instance for eac
Hi Jeremy,
To be honest I don't really see the gains (yet). How are those FILE_STORES
supposed to handle the *_URL bits of those settings? Instances in settings
are imo not going to fly, we should stay with strings to classes/instances
there for now. So how would the 'static' or 'dynamic' insta
Right now, I think that static/media handling is fairly confused in the
documentation, and a bit confused in the code itself.
We have a few special-cases floating around:
default_storage (needed for legacy before storage backends)
staticfiles_storage (needed for collectstatic/handling)
{
11 matches
Mail list logo
