Re: Having the app list available on every admin view
Il 12/03/2015 21:41, Aymeric Augustin ha scritto: 2015-03-12 18:47 GMT+01:00 Riccardo Magliocchetti mailto:riccardo.magliocche...@gmail.com>>: Finally it looks to me that everything in the app_dict but the permissions could be cached somehow. Would it make sense to cache the app_dict so it would be cheaper to add the app_list in the other views? Yes, it looks like there's room for optimization. PR please? ;-) I've taken at stab at it, but test_overriding_has_module_permission test fail. Looks like the deepcopy of the dict does not work but haven't debugged much. https://github.com/django/django/compare/master...xrmx:admin_applist?expand=1 I don't like how the code ended up after the second patch though. Need to measure it is a gain or not. -- Riccardo Magliocchetti @rmistaken http://menodizero.it -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/55036067.5070300%40gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Interested in GSoC idea "Replace Form Media Class"
Hi Tim,
Sorry for such a late response, I was caught up in the midterms.
The project idea is like this:
Right now we have a Media class which is used to fetch the form assets but
is not very popular. In order to replace it with a new preprocessor, I see
two viable solutions:
1. Creating a new app 'static' in django.contrib with glean best practices
from django-pipeline and django-compressor.
In this option, all the assets need to be declared in STATIC_CSS and
STATIC_JS dicts in the settings for the different apps/scenarios just like
they have it in django-pipeline and these assets can be loaded in templates
as per requirements.
We can provide support for all the major js and css compressors/compilers
like CoffeeScript, LiveScript, Closure, JsMin, Slimit, UglifyJS and YUI
compressor for Javascript and CssMIN and CSSTidy minifier for CSS by
installing these compilers in advance.
All the files that need to be minified can be mentioned in source_filenames
and the minified version will be generated as STATIC_JS['output_filename']
after compilation during collectstatic.
For eg:
STATIC_JS = {
'main': {
'source_filenames': (
'coffee/app.coffee',
'js/*'
),
'output_filename': 'min.js',
},
}
STATIC_CSS = {
'main': {
'source_filenames': (
'stylus/main.styl',
'css/*',
),
'output_filename': 'main.css',
}
}
2. Creating a new 'Static' class in django.contrib.staticfiles and
integrating it with the current implementation to add preprocessing.
Another option is that, we can have a permanent solution without any future
need of any ad-hoc based solution for the problem of static resource
optimisation. But it will require a lot of changes in the entire structure
of staticfiles, mostly in staticfile handlers and storage. Placement of
compiler support files in contib.staticfiles might also be a concern in
this case.
I am still discovering and learning new things about django and
preprocessing. I'd really appreciate if I'll be able to get feedback on
this from django community, so that I can draft a better proposal for this
project.
Thanks
Varun
On Tue, Feb 24, 2015 at 5:00 PM, Tim Graham wrote:
> Hi Varun,
>
> Thanks for your interest. If you want feedback, you'll need to describe
> your ideas in more detail.
>
> Tim
>
>
> On Monday, February 23, 2015 at 10:31:34 PM UTC-5, Varun Sharma wrote:
>>
>> Hi everyone,
>>
>> I've been pondering over the django codebase and GSoC ideas for some time
>> now. I find the idea of replacing Media class really interesting. As
>> mentioned in the ticket #22298
>> discussion, it will be
>> really usefull to replace the Media class with some sort of combination of
>> django-pipeline and django-compressor as a new Static class. I would love
>> to add this feature to django in this summer and I would like to discuss
>> this idea further to help me get the best implementation for this idea.
>>
>> Thanks
>> Varun
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/512d302f-bcb5-446c-afb6-a72dce93e7e6%40googlegroups.com
>
> .
> For more options, visit https://groups.google.com/d/optout.
>
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/CAJ7sbhF%2BsOQNCTV4W7i6Mydsx%2B8zETKjtyvga%3DC5%3D9xtabMWwQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Re: GSoC 2015: Template engine optimisation
Even with the cached template loader? Before realising it was unnecessary
one of the first things I did was hack something together that took the
nodelist from the include and stuck it straight into the for loop's
nodelist at compile time and it didn't make much difference.
Sam
On Fri, 13 Mar 2015 at 21:40 Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:
> 2015-03-13 12:21 GMT+01:00 Sam Cooke :
>
>> The test template we were using to test the performance was a simple:
>> {% for item in item_list %}{% include "item.html" %}{% endfor %}
>>
>
> Bad luck -- including a template in a loop is one of the known pathological
> performance cases of the DTL :-(
>
> --
> Aymeric.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CANE-7mXhB%2BgUNt_vZpvmMwBFfu1wYDBHaMWh1kx-HKg1%3DFcUGA%40mail.gmail.com
>
> .
> For more options, visit https://groups.google.com/d/optout.
>
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/CAMyx3A21SKQYCCr2Zbs_e9MwkyShGtN2TCOpiARKUcjS4Q%3DijQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Re: GSoC 2015: Template engine optimisation
2015-03-13 12:21 GMT+01:00 Sam Cooke :
> The test template we were using to test the performance was a simple:
> {% for item in item_list %}{% include "item.html" %}{% endfor %}
>
Bad luck -- including a template in a loop is one of the known pathological
performance cases of the DTL :-(
--
Aymeric.
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/CANE-7mXhB%2BgUNt_vZpvmMwBFfu1wYDBHaMWh1kx-HKg1%3DFcUGA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Re: csrf middleware token from request body
On Friday, March 13, 2015 at 4:14:55 PM UTC+1, Florian Apolloner wrote:
>
> I am pretty sure you can configure angular to send the token in the
> header. Either way, we are not going to try and load json, just we can't
> find a token otherwise…
>
> Cheers,
> Florian
>
Pretty much, you have to tell Angular to use cookie for token and send CSRF
header:
$http.defaults.xsrfHeaderName = 'X-CSRFToken';
$http.defaults.xsrfCookieName = 'csrftoken';
However I would argue that option to always send CSRF cookie would be
useful in situations when your app templates contain no {% csrf_token %},
yet you need that cookie for API calls from frontend to sign their POST's
to backend.
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/8518a3dd-8481-41d6-8c01-ca55eddfb785%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: GSOC-2015, Newbie, Want to contribute to Django development and also try my hand in GSOC
You are not too late for GSOC 2015. Here is some more information with potential projects. https://code.djangoproject.com/wiki/SummerOfCode2015 On Thursday, 12 March 2015 07:23:42 UTC-4, Saurabh Jain wrote: > > Hello, > My name is Saurabh Jain, currently pursuing bachelors degree in > Computer Science. I want to contribute to the development of Django. I have > worked upon Django as user but have no experience related to its > development. Can anyone please help me to get started with it ? I know that > its too late to start now for GSOC 2015, but still I would like to > contribute to the organisation no matter whether I get selected or not. > > Thanks > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/bfb10e00-5983-4167-844c-3c5bd09b67a6%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: csrf middleware token from request body
I am pretty sure you can configure angular to send the token in the header. Either way, we are not going to try and load json, just we can't find a token otherwise… Cheers, Florian -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/61c98746-736c-4bd6-b9c0-62934835efc3%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Django Admin New Look
> > Did you test RTL? > > I did. I tested Arabic and Hebrew - no issues detected for me. BUT. As far > as I understand Django admin has poor RTL support by itself. > Sorry guys, I was wrong about it. Django has very good RTL support! Just didn't notice right setting to test it. But anyway I did few tweaks in my theme. -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/6aed38cb-1959-49a2-a307-99451af4df75%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: GSoC 2015: Template engine optimisation
Preston - I'll send the template to you directly, I'm not sure how useful
it will be so I don't want to spend time checking if it's fine for public
consumption unnecessarily.
The test template we were using to test the performance was a simple:
{% for item in item_list %}{% include "item.html" %}{% endfor %}
Where "item.html" is the complex one (for a real world example, it's the
"cards" you can see in the chart on https://www.mixcloud.com/tag/house/)
and item_list is a list of 200 items (with all of the database queries done
in the view). Averaging runs after the first run (which would include the
compile) it was taking close to 1s per render. With the non-breaking
changes (i.e. not commenting out necessary engine or template code) I
managed to get it down to just under 0.9s. In both cases there was an
overhead of around 0.2s (render time if I ran with the entire template
commented out). Running the test with pypy (after warming it up) the render
time was 0.5s. Sorry I don't have more exact numbers - this is just the
headline notes I took away from the task.
As I removed chunks of template or engine I just found that anything I
removed made a couple of percent of difference. The first thing I tried to
optimise was the include tag and it only made a small difference - I even
tried merging the "for", "include" and "with" tags into a new tag to avoid
the 2 unnecessary contexts created by the two inner tags - my rough memory
was that made a 3-4% difference in this particular case and we decided not
to use it due to the added complexity of our code.
Most of our page render times on www.mixcloud.com are proportional to the
number of cards we have on the page.
Sam
On Thu, 12 Mar 2015 at 18:07 Preston Timmons
wrote:
> I've done a couple of days of investigation into template performance
>> recently trying to speed up our site and my main takeaway was that there
>> was no silver bullet - no particular node taking up all of the time. I was
>> mostly trying to optimise a particularly complicated template we render a
>> lot in a loop so I was modifying the template, Django code and making
>> custom tags to see what would make a difference rather than trying to
>> decipher profiles. We use the cached template loader so compile time wasn't
>> really considered.
>>
>
> Thanks, Sam. That's helpful information.
>
> I'd be interested to know the template you used, or at least one
> representative of the template you used. Templates that highlight
> real-world pain points would help to benchmark the things that matter.
>
> Did you apply all the internal Django changes you mentioned cumulatively?
> If so, what was your overall rendering time improvement? How did the
> speedups from changing nodes compare to the speedups from modifying the
> engine? It sounds like the engine changes were a factor because of multiple
> calls to the include tag.
>
> While the changes you mentioned don't sound like ones that could go into
> Django, they do shed light on what can potentially be done or not for
> optimization.
>
> Preston
>
>
>
>
>> We tried the following things and none of them made more than a couple of
>> percent of difference each:
>>
>> - we made a cut down {% url %} tag that just does what we need - the
>> built in tag can handle a lot more at a performance cost
>> - I grouped {% with %} statements together - ideally grouping into {%
>> include ... a=b c=d %} - to avoid extra layers of context
>> - I ditched TextNodes that just contained whitespace (both by removing
>> the whitespace and by automatically removing the Nodes on compile) - it's
>> easy for these to build up when you have code like the following and every
>> extra node slows things down a bit (whitespace is sometimes meaningful so
>> we would have only implemented this for particular bits of code)
>>
>> {% if whatever %}
>>{{ my_var }}
>> {% endif %}
>>
>> - I also tried commenting out (or replacing with "return '' ") chunks of
>> the template engine code and our template and it just seemed that the more
>> I commented out, the faster it ran - no particular jumps in speed, just a
>> gradual change as more was removed. Escaping was one of the first things I
>> commented out and it made a surprisingly small amount of difference.
>>
>> I'd be very happy to be proven wrong but thought it was worth sharing my
>> findings since - particularly in the context of Preston's suggestion that
>> we might find a bottleneck - I don't think there is one particular
>> bottleneck.
>>
>> Our "solution" for now has been to speed up the processors in our servers
>> and investigate switching to pypy - we'll probably be looking at Jinja2
>> once we upgrade to 1.8 as well.
>>
>> Sam
>>
>> On Thu, 12 Mar 2015 at 15:57 Preston Timmons
>> wrote:
>>
> After a while I believe layers and layers of caution have accrued, and
nobody is sure any more where these have overlapped excessively.
>>>
>>> Do you have examples of which layers these are?
>>>
>>> Escaping seem
Re: Django Admin New Look
> > In line with that, how does it perform for mobile devices? > Same as default django admin. I don't plan to make admin responsive yet (to make it perfectly accessible on mobile) - just because we can't control third-party apps. Ideally django should have its own css framework for that but not in near future I think. -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/1b771d79-d018-450f-8752-c8a258e3ea73%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
csrf middleware token from request body
Hi,
Not sure if this breaks any RFC’s or there’s another valid reason why this
doesn’t exist already but I’ve noticed that certain client frameworks
(looking at you angular) have a tendency to put POST data in the request
body.
For example, the following angular code
$http( {
method: 'POST’,
url: theurl
headers : {
'Content-Type': 'application/json; charset=utf-8'
},
data: { 'csrfmiddlewaretoken': thetoken),
‘foo’ : bar}
};).
The csrfmiddlewaretoken then ends up in the request.body as a json string
(regardless of the content-type) and not request.POST and the csrf
middleware rejects the request. I’m not an angular expert but as far as I
can tell if the data is not a simple string then it gets JSON’fied and ends
up in the request body.
I was proposing adding the following to csry.py as a last chance saloon
attempt to find the token
*# Last chance, check the body for a JSON payload*
*if *request_csrf_token == *""*:
*try*:
bodydict = json.loads(request.body)
request_csrf_token = bodydict.get(*'csrfmiddlewaretoken'*, *''*)
*except*:
*pass*
I’ve created a fork and branch with this modification
https://github.com/rjjeffries/django.git - branch csrf_jsonbody
Thanks
Richard
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/fa3cd61f-4370-432f-a2c9-0e8a065b652d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
