1

Just a simple question really. In django when using classy based views, is there a way to lighten each view?

Some of my views are loaded with context variables linking to many query sets. I feel like this is the wrong way to go about it.

However, I require the data, just maybe not immediately upon loading the view.

Do you guys have any suggestions?

user3566532
  • 13
  • 2
  • The normal way is to load the page layout on first load and then let the page fetch expensive sub-sections through ajax/iframes.. – thebjorn Aug 10 '14 at 13:35
  • I would have thought so. Is there any good articles on how to properly do it? :/ – user3566532 Aug 10 '14 at 13:42
  • The easiest way to start is probably by using iframes or jQuery's `$(...).load(url)`, since that requires very little change in your backend. I'm not aware of any great articles on it, but you'll find bits and pieces everywhere (eg. http://stackoverflow.com/questions/20306981/how-do-i-integrate-ajax-with-django-applications). – thebjorn Aug 10 '14 at 13:54
  • Great, thanks. Do you know if the query sets are called onload or only after you use the variable? – user3566532 Aug 10 '14 at 14:01
  • 1
    People still use iframes? –  Aug 10 '14 at 14:13
  • Querysets are called before leaving the server (where the template is expanded), i.e. long before onload. – thebjorn Aug 10 '14 at 14:29
  • Yes, people still use iframes :-) – thebjorn Aug 10 '14 at 14:30

1 Answers1

0

There are many ways to deal with it, some suggestions:

  • Refactor your views, are you using repeating context data? use a context processor
  • Do you need all data available on initial rendering? then again a combination of context processors with caching will reduce the load times, cache expensive objects, you can then flush and regenerate them with DB related signals (eg, post_save, expire the cache and re generate it).
  • As mentioned, if your data is not required in the initial rendering, then assign ajax requests, break down the views, create a separate ajax_views.py and stuff the ajax based data inside that, create the appropriate urls so that your views are separated by logic.
  • Fragment cache parts of the page, if your views require the data, as stated above you can directly cache the objects, another way is to cache templates or fragments of it, again you can either cache by time or with signals (invalidate cache and re-generate).
  • Cache the whole page, if your data is consistent and does not change frequently deal with whole page caching, again you can invalidate the cache by signals.
petkostas
  • 7,250
  • 3
  • 26
  • 29
  • Isn't post_save executed right after the save (and before anything goes to the browser)? ..or have Django signals become asynchronous? – thebjorn Aug 10 '14 at 14:33
  • Do you understand cache invalidation of a complex object? post_save can be used to invalidate a complex object after the object has been modified (updated, saved, deleted etc), there is no reason to cache complex objects for time duration if you know that the only thing affecting them is data modification. I am talking about cache, not the save operation. – petkostas Aug 10 '14 at 14:37
  • ok (it sounded like you were suggesting to not only do cache invalidation, but also regeneration in post_save..). – thebjorn Aug 10 '14 at 16:30