I want to move some parts of a main template into partials which shall not need django rendering (i.e. pure html/js) and use them in a ng-view in the main template.
However, the partials have Django formsets (using crispy) in them i.e useless without Django rendering.
Moreover, I do not want to write the complete formset HTML by hand.
How can I do this?
Maybe you have a less or sass file too. This file, like your form, it's unusable without preprocessing.
Review code from https://www.djangopackages.com/grids/g/asset-managers/ for inspiration and look at https://docs.djangoproject.com/en/dev/howto/static-files/ to learn how to do it.
Hard part is not do it because its easy make a static finder. Hard part is do it in development staging in a transparent way.
You can request your partials from the server and put them into the $templateCache yourself using the filename as a key.
This way, when a partial .hmtl file is request, it will get the django rendered HTML.
$http.get('myForm.html', {cache:$templateCache});
You'll want to eagerly load these partial templates, as if the partial template is not in the cache, then it'll request the static html.
Hope this helps
Related
Is Zurb Foundation's Interchange compatible for use with Django templates? I can't see a way to get them to work together, though the issue is just a technical one - Interchange seems to want html file paths, while Django's html templates render inline.
I suppose it would be possible to render the necessary templates each request into temporary files and hand those to Interchange, but that's not a very clean solution and would require a lot of boilerplate. I'm looking for a cleaner solution or for an alternative within Foundation and Django.
No, Foundation's interchange is javascript that runs in the browser within the HTML file produced by Django on your back-end. It's meant to be used for loading static files, mostly media, dependent on the size class of your browser view. E.g. inside and <img> tag:
<img data-interchange="[{% static 'images/my_background_small.png' %}, small], [{% static 'images/my_background.png' %}, medium]>
If you want to serve different HTML to different types of end-devices, you have to add that logic to your Django app's view, so that it uses a different template depending on the client. In general there are a few approaches:
What people do nowadays: Write responsive templates so that the same
HTML is served for mobile and desktop. For the few minor
differences, you can hide/show divs depending on the media class.
Check the device in your middleware and pass it as parameter to your views and templates so you can make decisions on it. Check django-mobile for example
Check the device in your server (apache or nginx) and add an HTTP header to your request that you can parse in your view (e.g. request.META.get('HTTP_MOBILE_SITE','no'). Example here
I have a fairly large django project consisting of several individual apps. I am farming out some of the front-end work (CSS, HTML tweaks) to people who aren't over-familiar with django. To that end I'd like to generate a list of templates for each URL pattern any given engineer is working on. This will save much time that would otherwise be spent manually tracking down the templates used during a view's render phase.
For example, if Bob is working on URLs beginning with /accounts/ then I'd like to generate a list of all the templates used by any view that handles requests to those URLs.
My initial thought is to use something in the test framework since that has access to the templates rendered during a request. However, I can't guarantee that all URLs or views will be exercised (sadly I don't have 100% test coverage), and a missed template is unlikely to be noticed. I don't mind writing a set of tests that simply exercise each view, but don't want to duplicate existing efforts. Also certain views require POSTed data or authentication to function correctly - although I suspect that's an issue I'll have to face no matter what approach is used.
Are there any utilities or snippets that will do what I need?
django-debug-toolbar is a must for developing with Django, It includes a panel detailing all templates used during a request.
I've found the SQL panel is the most helpful for improving page load times as it details slow and duplicate queries.
It can slow down requests when enabled, disabling all panels but those that you use helps.
I'm doing a form application (similar to django-contact-form) and would like to be able to insert the rendered form in a Django template of another application.
What's the best way to do that? Should I create a template for the form (with for example only {{ form.as_p)? If so how can I insert it in another template?
Thanks
Jul
What do you mean when you say a separate 'application'? Do you mean a completely separate Django site, or just a separate app within your current site?
If the latter, there's no issue: just import the form into the view you want to use it in.
If the former, then there isn't really any good way to do it. You could try using an iframe within your template to point to the external site, but it's not a particularly nice architecture.
Couldn't you load the application with the form you need in the settings.py file under INSTALLED_APPS and then call it from your template somehow? I'm a little new to django, but from what I can tell that seems like it would be the "django" way of doing it.
Building a django app with some mostly static pages at the front of the site e.g. about.html faq.html
that kind of thing
I was looking at how urls.py work and I created this.
('(.+\.html)$', direct_to_template),
It seems to do exactly what I needed. Now for any new .html page I add to the root of my templates folder it just works. templates/about.html templates/faq.hml
I can also use things like this in my templates
{% include "_menu.html" %}
Now someone has kindly pointed out Django FlatPages and suggested maybe I use them instead. If I'm not connecting to the db are there any disadvantages to the way I'm doing it.
Seems to me like its a better way to do it than FlatPages because it uses the db and isn't quite as elegant (haven't actually used flatpages in practice though)
If you're ok editing template files directly and manually adding new ones to your urls.py file, then stick with what you've got. Flatpages is useful if you want to be able to edit page content from the admin interface or any web-based editing tool you might care to design, or perhaps more to the point: if you want non-technical users to be able to edit the content.
I would suggest moving one step further. If your static content doesn't change frequently and doesn't make use of Django's templates then don't use Django to serve them. Use a light weight server such as Nginx instead.
If you do make use of Django's template features without requiring any dynamic content from the database then you can stick with direct_to_template.
One advantage to using FlatPages is that you can use the Django templates to for headers, sidebars, footers (to maintain a consistent site appearance) while still using mostly plain HTML for the page content. That is offset by the need to store the page content in a database table.
My advice? If what you're doing is meeting your needs, stick with what works.
I want to include things like twitter status, or delicious tags, in my django templates.
These things are dynamic, yet regular. How would this be done?
There are a number of ways to handle this, so you can choose a method that best matches your own personal style or requirements:
Template context variable: as answered by Alex you can put your content into a context variable that is included in the context of every template created by every view. Django even provides a mechanism for doing this automatically, called a context processor. Pros: very straightforward. Cons: won't dynamically refresh new content on client browsers.
AJAX dynamic loading: as mentioned by Alex and Dave you can dynamically load your content using AJAX methods. As an example using jQuery, you would put a placeholder in your template something like <div id="twitterfeed"></div> and then in a javascript block in your template put $("#twitterfeed").load("{% url twitterfeed %}"); where twitterfeed is a url so named in your urls.py. Pros: will dynamically update browsers. Cons: can be tricky if you don't know Javascript.
Inclusion tag: Django provides a type of template tag called an inclusion tag, which is basically a custom template tag that can render dynamic content. In a way it's similar to a context variable, except your code to generate the content will only be called when you use the custom template tag in your template instead of being called for every view. Another benefit is the content is generated from a template of its own. You could do this with a normal context variable of course, but it's not as clean (IMHO) as using an inclusion tag. Pros: very straightforward, clean. Cons: won't dynamically refresh new content on client browsers.
The simplest approach is to use {{ mycontent }} in your template (where you want the dynamically generated content to appear) and put the correspondence between mycontent and its value in the context you use to render the template -- i.e., the most fundamental part of django's templating.
If what you mean is that you want Ajax support whereby Javascript on the page continuously refreshes such content according to what the server wants it to be at any given time, I suggest looking into dojango, the Dojo/Django integration project -- it's not yet as fully mature as each of Dojo and Django are on their own (not version 0.4 yet), but it is already usable and useful.
A common technique is to leave a placeholder div in the generated content, then fill the div in on the client side via an AJAX call from Javascript that you include in the page.
That gives you the benefit of having a cacheable (fast loading) primary page, with separate dynamic bits. Depending on how live you want the dynamic bits, you can can even cache them for shorter durations.