I have a template that is a header snippet that is used on every page of the platform.
What I would like to know is what performance implications/issues checking permission with {% if perms.foo.add_bar %} can have on the platform. And if there is a better way to do this.
I checked the load/request time of the page on Django Toolbar and didn't seem to change at all. Although I tested just at my local environment, not the production (don't have access).
Related
I am very new to web development and the following is my use-case :
I have a large number of Bokeh charts, each in a separate HTML file.
In simple terms, I would like to have a home page, where I can provide
links to each one of these charts. However, During runtime, I would
like to edit these separate HTML files, so as to provide a link to go
back to the home page or to other pages. I would not like to modify
the HTML files permanently, so I can make use of them outside of the
web page as well for simple visualization on my system.
What is the best way to do this ? Are there technologies outside Django, I should be looking at to do something like this ?
If most of the content is static, maybe have a look at Jekyll.
The include functionality would let you create one file with the 'link back to the homepage' or in fact further content which you want to avoid repeating (such as navbars, headers, footers).
Bootstrap 4 is your freind for making the site look shiney.
As you're building the site you can run the development server with jekyll serve which allows you to connect to a development server from your browser, and preview changes as you're making them. This would be accessible somewhere like http://localhost:4000/
When you're ready to publish, you can use the jekyll build command, which outputs all of the static HTML files to the _site directory. Notice that at this point, the step of 'putting the homepage link in every page' is handled automatically by Jekyll and you end up with a directory you can upload directly to any hosting platform. The original HTML files/Boken Charts can therefor remain in their original form for use elsewhere.
This method is probably much more effiient than using Django for your use-case, which seems to require serving lots of static content whch already exists. With Django in production you'd need an application server, as well as a webserver and possibly a database which means more things to go wrong.
For bonus points, once you've got the hosting setup, stick the whole thing behind CloudFlare to reduce your hosting costs, and improve access speeds for visitors around the world!
Good luck.
EDIT: response to comment:*
Do you mean that I should abandon django altogether ?
If the purpose is just to serve your exising HTML files to the public, without any requirement for authentication, editing of content by users through the frontend, or more advanced back-end functions, then yes Django is probably overkill for this task.
How is Jekyll different from Django ?
Django is a Python Web Framework, which allows you to build an interactive site on which users or staff can login, post articles, comment, etc. One of its key features is the ability to define database relationships trough 'Models' and then have all the admin-side forms generated automatically in the background. This means, with minimal work, you can instantly have the 'admin portal' side of the site live, which works great for use-cases like large blogs or news sites. You would then build the frontend, which can also be interactive. To launch this into production is a separate task which involves configuring multiple server components.
Jeykll on the other hand is much simpler, and basically gives you a way to create some template HTML files (avoiding the need to repeat code for stuff like navigation bars) and then with the jekyll build command outputs a _site directory which can be uploaded straight to a basic webserver. This is the crucial part, as you then only need a webserver which can serve static content, rather than requiring python, a database, application server like UWSGI, etc
Let's look at this example from the Jeyll Docs with your usecase in mind.
You could define a YML file with a list of all your charts:
docs_list_title: All Charts here.
docs:
- title: A Lovely Bokeh Chart.
url: bokeh_chart_1.html
- title: This Bokeh Chart is even Better
url: bokeh_chart_2.html
You mentioned previously that you already have the HTML files, so really what you've done here is made a list of those, which can be interpreted by the frontend.
The HTML template portion would look something like this:
<h2>{{ site.data.samplelist.docs_list_title }}</h2>
<ul>
{% for item in site.data.samplelist.docs %}
<li>{{ item.title }}</li>
{% endfor %}
</ul>
This would result in a list of links to all of your Charts, with the link text as the title.
Obviously you could then go further and add further info to the YML file, like beneath each url put publisher: someone which could then be accessed in the template's for loop as {{item.publisher}}
Can such tools like Jekyll, Django and Bootstrap be used together ?
Bootstrap can be used with Django or Jekyll, as it is a CSS library which controls how HTML is rendered in the user's browser. Check the documentation for more examples of its capability.
A good starting point may be to download a theme from somewhere like Start Bootstrap. Once you have that as a ZIP file, you can put it in your Jeykll project and attempt to have it render through the dev server with jekyll serve. You can then remove nav bar or header code to separate include files (see my earlier link to the Jeykll docs) and before you know it you'll be seeing progress.
The best way to learn is to just go ahead and try this!
I am deploying social networking site with django on VPS, my current stack is nginx, postgresql, gunicorn. I am going to add memcached, I will be forced to use {% cache %} tag in my templates or low level api in views though, as each site will be dynamic for authenticated users. I have 1 question regarding {% cache %} tag, lets say i will input a variable within cache tag like so:
{% cache 500 x %}
{{ variable }}
{% endcache %}
Lets assume that {{ variable }} is in fact very consuming database query written in related view. What would be the best way to prevent database hit from view (lets assume query will be evaluated in view) , should i cache it as well with low level api? If so isnt it a bit redundant as I would cache it in both places? Please give me your thoughs what would be the most convenient method. Btw, I know that this example is trivial, if I only wanted to cache variable I could do this in view, but I will surely need to use cache tag to cache some loops, multiple html lines generated by python etc. Thanks
First, the usage of authentication in your site doesn't involve the usage of low level cache in both sides views and templates, note for instance you can do something like {% cache 500 user %} and that will save different chunk of code of each user of your site.
Answering your second question: in general, you can prevent database hits just caching into the templates. Evaluate the query there instead of doing into the view, and make a dynamic clean up of the keys when the content changes instead of using fixed expiration times, that way let you get better performance result. Also, take in mind cache tag saves just chunk of HTML code.
I have the website where I need to limit users access to the website's parts. To keep it simple let's say while website is in beta - I want only registered users can see the website and all the parts. But later I will want to remove those limits.
What I can do - do this login in the template level. Like in all the templates I can have {% if user.is_authenticated %} and then just show some message if not.
Second thing which is in my minds - I can define middleware which will check if the user is logged in and if not - redirect him to the login page.
I see bad thing about the template solution, because after I will release the website out of beta, I will need to modify a lot of templates...
What else I can choose here?
Thanks!
You must tag all methods or classes involved with the login_required decorator. If you're using generic views, set login_required=True when defining them in urls.py.
I want to add an templatetag to the django admin, how can I go around extending the existing tags without needing to fudge in django.contrib.admin.templatetags?
Update:
Using {% load mytemplatetags %} in the admin templates breaks my server for some reason (im using nginx and throws me a bad gateway for that page). But the file mytemplatetags.py does exist in the templatetags module of my app.
Interestingly enough when I just misspell or apply a non-existing name for it, forinstance say {% load footemplatetags %} it just gives me an ordinary django error:
'footemplatetags' is not a valid tag library
So it probably knows mytemplatetags.py's existance, but doens't know how to handle it.
I am using django 1.3 alpha (just checked out the svn), perhaps its a good idea to get with something stable?
Nevermind, my template tag was broken.
I am running Django (1.0.2) on Google App Engine, and would like to know which (if any) of the following Django caching modules ought to inherently work with Google's memcache implementation:
Middlewear
django.middleware.cache.UpdateCacheMiddleware
django.middleware.common.CommonMiddleware
django.middleware.cache.FetchFromCacheMiddleware
Decorators
django.views.decorators.cache.cache_page
Template fragment caching
In a template:
{{ load cache }}{% cache 500 cache_name %}...cached...{% endcache %}
Low level API
django.core.cache
If some or all of these modules ought to work, are there any changes necessary to make them work properly, and are there any concerns or pitfalls ought one be aware of when using them?
I've perused the documentation and spent some time searching Google, but I haven't seen the answer to this. I suspect it may be a "turn-key" solution, but am wary of using the Django classes without at least one reference that someone else has done it without issue.
Thank you kindly.
No, app engine provides a custom memcached API. What you'll need to do (and there may already be an open source implementation of this, I don't know), is write a Django cache backend for this API, they're pretty simple, you can use the existing memcached backend as the basis for your new one: http://code.djangoproject.com/browser/django/trunk/django/core/cache/backends/memcached.py . http://code.google.com/appengine/docs/python/memcache/usingmemcache.html shows what the App Engine memcached API looks like.
Running Django on Google App Engine says "it is possible to use nearly the entire Django stack on Google App Engine, including middleware." Also, that page has an example which includes one of the classes you asked about, so at least that one ought to work:
MIDDLEWARE_CLASSES = (
'django.middleware.common.CommonMiddleware',
...
Various sites such as this one have code for using AppEngine and the Django caching code, such as django.middleware.cache.UpdateCacheMiddleware. See this Google search for other references, of varying quality. ;)
I haven't actually used this stuff, so I can only take others' word for it, but it does seem as though multiple people have done it.
Edit: Django tickets 7398 and 7399 are relevant to this.
You should check this http://code.google.com/p/google-app-engine-django/
You want this
https://github.com/django-nonrel/djangoappengine