django allauth with jinja2 templates - django-templates

I would like to know if it is possible to use the django-allauth app with jinja2 templates instead of DTL templates.
There does not appear to be any clear information about this, or usable examples available. I am unsure if this is because its easy and therefore doesn't warrant its own explanation, or because its impossible.
I am aware of this feature request, but it is 3 years old.

Yes, it is. You'll need to use crispy forms in jinja templates though.

Related

How to organise importing mixins, filters and directives in a large VUE project

) I am coding a really big vue app and now I have a question, how to organise importing mixins, filters and directives. I am in trouble because I see that I don't understant how to do it((( I hope somebody coud help me.
How to organise...
it depends...
are you working with a team or alone?
Do you want to move fast or keep your app maintainable?
Does your app have a user base (critical) or is it a side project?
The first question I would ask is what code is duplicated and can be simplified or generalized.
The goal is to shrink the code as much as possible while staying clean. Remember that in six months you will want to read your changes and immediately know what is going on.
If you are using Vue 2, I would ask the question, why are you using filters?
It is one of the breaking changes when it comes to migrating to Vue 3. Think of another solution, like methods or computed properties (easily implemented).
This question cannot be answered here. It is too opinion based. There are many cases to consider and everyone has their own preference. Some like code splitting, some like to collect a lot in one file. Some a mixture, depending on how important or often functions are used.
Sorry.

Is it possible to use Aurelia in a non-spa application?

Recently I've been playing around with different frameworks and libraries, looking for something that really suits my needs.
You see, my job mainly involves creating asp.net mvc applications and for most of them using Razor and a little bit of jQuery is enough. But in certain cases and only for a few pages,which are rarely more than one or two per app, I really need something extra that helps me avoid getting entangled in a bunch of jQuery code.
As I mentioned, I tried a couple of alternatives and from them, the one I liked the most is Aurelia, because of its simplicity and the fact that it embraces standards, BUT the more I dive into the framework, the more I think that it might not be what I'm looking for,as it seems more suitable for full spa applications and what I need is:
Something that helps me reduce the amount of DOM manipulation
A efficient templating engine
I know that Aurelia provides that and much more, but I don't want/need a SPA, I need those functionalities ONLY in some specific pages and not the whole application.
Can Aurelia help me achieve this? If so, how?
Sure, Aurelia can help you achieve that. You just won't use certain features like routing in on the pages you create with Aurelia.
That being said, it isn't a drop in replacement for jQuery, but none of the "modern" JS frameworks really are. And you're going to end up spending time learning whichever one you end up choosing.
Check out the aurelia.enhance functionality, it might be just what you're looking for!
I have used Aurelia in a non-SPA context, and it worked out well. I think this is exactly what you describe. For example:
http://legumeinfo.org/chado_phylotree/phytozome_10_2.59028020
https://github.com/legumeinfo/tripal_phylotree/tree/lis_master/theme/js/aurelia
I'm using aurelia for dynamic elements on some sites. Like comments for example. Page loads fast w/o comments.Then Aurelia kicks in and loads the comments below. Also with some signalR magic the discussion is updated in real time. It is awesome and insanely easy.

ROAR: What are the benefits over jbuilder or rabl?

I've read through https://github.com/apotonick/roar and it seems like a lot of thought has been put into ROAR. But in the context of a fairly standard Rails-powered JSON API that uses jbuilder, I'm still not able to immediately see what benefits ROAR provides.
What am I missing?
Within a Rails project, you should do as much as possible to stick with the built-in solution, but outside a choice is mandatory. Personally one aspect that I love about ROAR is the versioning for the API.
There is one good post I like that might help you:
http://devblog.reverb.com/post/47197560134/hal-siren-rabl-roar-garner-building-hypermedia
It might not be an straight answer, but it explains the problems you should be aware of when choosing a JSON API generator.

what are the benefits of using a template engine

I do not understand why a developer would use Phalcon's Volt template engine.
In the end, after the compilation, the same PHP files are produced, that I would have to write manually in the first place. To me, it looks only to be detrimental to the performance.
Is the answer "so you could pass .volt files to a front-end guy"?
The answer lies in the development of your application. Why do you use a framework instead of pure PHP? Why bother with object oriented programming when procedural/straight PHP is faster?
There are many reasons of course and it is a long discussion. The summary is ease of use and maintainability.
The same goes with Volt. You can use the volt templates to do what it will take you a lot longer if creating plain phtml files (HTML with PHP tags in there). Examples I can give you are template inheritance, partials, calculations within the template (for/each loops) etc.
As far as performance is concerned, there is always a performance hit when using a template engine. Volt luckily is part of Phalcon so the performance hit is minimal since Phalcon does all the hard work in memory instead of using included files here and there to offer its functionality.
The decision is up to you. Volt, Smarty, Twig and others are there to help with development of your application. Your decision is what makes you use the template engine or not.
This is an old question, but I want add some insights.
You asked why you should use Volt, the Phalcon template engine, but in your explanation you want know, more generically, why you should use a template engine. The short answer to your question is: you must use a template engine to avoid mixing PHP with HTML.
But I want answer to the main question also. Why Volt? Volt overload is minimum compared to every other template engines out there and it's not because is written in C, but because it generates a unique PHP file for your view.
Twig is probably the most complete template engine out there. Twig has many more features compared to Volt, it's more stable and older. Twig, anyway, doesn't generate a unique PHP file, but a bunch of PHP classes with methods that call each others. Doesn't matter if you are using the Twig C Extension, Twig is gonna be slow anyway.
Twig is really really slow when compared to Volt and even to the good old Smarty. So, if you are using Phalcon is probably because you want achieve the best performances, serving a lot of page requests; in this case Volt is your friend.
When history of PHP starts, it was standard, that HTML was generated directly inside PHP scripts. But it happen to generate some problems when it grown to one of most popular ever web programming languages.
To keep people working in huge projects comfortable with their tasks ie. when developing web services, where was an MVC architectural pattern invented. M for Model is used to store data and handle them in a maintainable and repeatable manner. V for View as an part, that is responsible to generate proper output. C for Controller that are responsible for sending commands to models etc., being a core logic of application.
When user send a command to service, Controller is handling it and understanding. Triggering changes on proper Models and maybe forwarding actions to other Controllers as long as View Controller is reached. View controller takes a proper view, injects into it generated data and executes it to create output that is send back to user. If template for view is not yet generates, it triggers template engine to do it.
Proper implementation of full MVC greatly helps both programmers, system architects, front-end devs etc. But when on one side it happen difficult to maintain databases (so ORM were developed), on other side of system it was difficult to maintain views.
One of principles of MVC is that Logic (with huge "L") is only in controllers. So there is no logic in views. Using template engine enforces easiness of achieving that because of poor support of logic by them self. It is not a secret, that programmers are "lazy" - so if they have an occasion to put some more advanced logic into view, they would do it.
I guess that all frontend devs have programming skills. Problem is to make them stay with you. Working on huge project with lots of views (and so hudge templates) with PHP mixed into them will drive them crazy. It is much easier to read code written for template engine.
Idea of template engines is to add one more part to system, that offers possibly simple language allowing to use basic logic like loops and if statements. On one side template engine receives kind of a textual file to transform it into PHP file with mixed into it hyper dose of all important HTML.
If you are alone developer, it is important to nobody that you are using files that mixes PHP with HTML. It looks probably close to this:
<html>
<head>
<title><?=$title?></title>
<? foreach($metas as $meta) { ?>
<meta name="<?=$meta['name']?>" content="<?=$meta['content']?>"/>
<? } ?>
But any frontend developer would rather like to work on file looking this way:
<html>
<head>
<title>{{ title }}</title>
{% for meta in metas %}
<meta name="{{ meta.name }}" content="{{ meta.content }}" />
{% endfor %}
for it higher readability. It happens extremely handy when template includes some kind of javascript inlined. After all, you end up with same file you can create by hand, but this file is generated for you and stored, so it is no more generated as long, as core file is not changed. We are generating our templates during deploy what has 0 hit on performance, especially now, when Volt engine is written in C.
Another handy thing about template engines is that (with some your effort) it is possible to generate templates minified on the fly. You wont ever minify your hand-crafted template, except when planning to commit suicide.
So globally, it is a case of:
so you could pass .volt files to a front-end guy
but it is an effect of working in MVC pattern. And Phalcon is made to fulfill MVC principles. I'm not even trying to guess, how you managed to work with this piece of software for ~2.5 years not using template engine. Maybe you are working alone.
Every person has different taste, but i tell you my vision.
I think volt is useful because:
As all phalcon framework, Volt has excelent performance.
Benefits from template engines (i dont wanna repeat that already other answers says)
Hierarchical rendering: More info -> https://docs.phalconphp.com/en/3.0.2/reference/views.html#hierarchical-rendering
I love the phalcon hierarchical rendering, because is clean, easy, and any person can understand where can find the view of something, ideal for a designer, or other non technical person
And to add value, i modify some phalcon parts to apply that hierarchical rendering using app modules, thats all i need.

best practice for extending dynamic templates?

I need to render nested templates and as obvious these templates have many to many relation (eg. forum calls news, menus, videos etc.. and vice versa).
Im new to DJango and the only solution I can think abt is repetitive calls between them.
Any idea?
Thanks
this may prove to be helpful. It has got some documentation on extending django templates. Also see here for some info on the template inheritance mechanism. If you want to extend the template engine, then see here.