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
On 2 oct. 2014, at 14:35, Josh Smeaton wrote:
> - The pluggable solution works well when you have a common interface, but a
> different implementation in the backend. Have you thought about how to
> support differences in syntax (interface) between various templating
> libraries?
Yes, I have.
Nice! I've thought about trying to tackle this myself, but never got past
the thinking stage. Thanks for taking this on Aymeric. I've got a couple of
technical/design questions.
> I’ve been thinking about providing built-in support for Jinja2 in Django.
I found that supporting pluggable templat
I think it's an awesome idea to have a pluggable template engine
architecture in Django. I hope you can stretch the goal to have the second
step (djando templates as a library) done too!
On Oct 2, 2014 8:48 AM, "Gwildor Sok" wrote:
> It's good to see something happening after the lengthy discussi
It's good to see something happening after the lengthy discussion of last
February on this mailing list. Thank you for taking initiative in this. I
believe this will be a great addition to make Django even better.
On Thursday, October 2, 2014 1:28:01 AM UTC+2, Russell Keith-Magee wrote:
>
>
> On
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?
Hi Pkl,
Sorry for slow reply, but I thought this was worth it:
On 03/09/14 20:45, Pkl wrote:
> Concerning the "rules of open source", I've yet to find a satisfying way
> to apply them regarding these "micro breaks". Imagine that project
> "myvideoplugin" is unmaintained (not handling PR) : unabl
On 03/09/14 14:21, Anssi Kääriäinen wrote:
> For example, lets consider the get_query_set() -> get_queryset() naming
> change done in 1.6. If 3rd party library writers change the method name
> to get_queryset() for 1.6, then their code won't work in 1.5. If they
> don't do the change, then all use
Hi Aymeric,
I agree there is no security vulnerability, because the middleware
defaults to safe. That comment should be fixed.
The hard-coding was put there basically to make it easier to use, first
for the case of simple migration instructions when this CSRF protection
was introduced/changed, an
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?
10 matches
Mail list logo