I'll give some background. The Django Templating Language was very specifically designed to NOT allow putting business logic or allow calling arbitrary functions in the template. Jinja2 loosened up that a bit, but it still doesn't let you do whatever you want. There's a couple reasons, but one is performance. Django gains a lot of optimizations because all database queries can happen in a small region. It also means one cannot potentially have 3 functions that each request the same data thus doing 3 DB queries, which is very slow.
It is also generally "bad form" to mix your business logic and your display logic. I get that there's some times where it's much simpler to break that separation. That is part of why Jinja2 gained some traction (though I personally really like the better whitespace control). It also creates a much better chance for a security flaw and maintenance issues. Obviously, there is nothing stopping you from creating such a templating language. It may get really popular. Finally, I'll mention that there's nothing in Django that stops you from just changing the template language used. It's as simple as not using the render shortcut function. The joy of Python is that you just need to generally match the interface. Not to be mean, but I wanted to point out what's being proposed. Your proposal is that Django pays you to create yet another templating language that they have to support. This leads to three separate paths that the code can take. There then needs to be some ability to cross communicate between all three languages. Then there's the "sales" end of explaining why there's 3 templating languages and why one needs to choose another. One of the real selling points of Django over other frameworks is that they're opinionated and chose a specific set of tools. I started back in Pylons/TurboGears, and I would spend a long time looking over which DB layer to chose and which templating language to chose. In the end, I'll say that it was refreshing to go to Django and have some of that chosen for you and to just start working. I really do wish you the best of luck if you attempt to make this. I'm sure there is a need, but I personally do not see it being a direct fit into Django. Best of luck, Joe On Fri, Mar 16, 2018 at 3:27 PM Josh Smeaton <[email protected]> wrote: > I'm confused by your proposal. You state one of the drawbacks with current > templating is the readability issues for frontend developers that have > templating logic defined within the template. But isn't your proposal to > replace html templates with one defined in python? How does this make it > any better for a frontend developer? It sounds like it'd be strictly worse. > > Further, sites will still need to query the ORM and inject that data into > the template. I don't see how your point number 3 is addressed at all - and > don't even think it can be. > > A new templating engine will also be incompatible with the thousands of > django and python libraries already available in the wild. > > It sounds like you're attached to your project, which is a good thing, but > I'd encourage you to work on this separately from GSoC as a learning > experience, as Aymeric mentioned before. This is definitely not a project > that would be accepted for GSoC, without actual proof that the project was > **already used by people** and provably better than the options we already > have. > > Regards, > > > On Saturday, 17 March 2018 04:09:41 UTC+11, Manasvi Saxena wrote: >> >> Hello Sir, >> >> On Thursday, March 15, 2018 at 11:29:46 PM UTC+5:30, Aymeric Augustin >> wrote: >>> >>> Hello, >>> >>> 2018-03-15 14:24 GMT+01:00 Manasvi Saxena <[email protected]>: >>> >>>> Think of this library as a bridge between Python and HTML, you don't >>>> need to know the syntax of HTML, just need to know which function of the >>>> library creates what output. After you have created the content of your >>>> page just pass it to a function in a list and you have your HTML page. >>>> Have a look at the prototype and let me know what you think of it. >>>> >>> >>> Thanks for the example. >>> >>> To be honest the sample.py file doesn't strike me as a convenient way to >>> write HTML. >>> >>> I think someone who's confortable writing Python code should be able to >>> learn the HTML syntax very quickly. >>> >>> <tag attr1="value1" attr2="value2">content</tag> isn't more complicated >>> than pyhtml.tag("content", attr1="value1", attr2="value2"), is it? >>> >>> This idea is not a good fit for Django. Perhaps it can be a learning >>> experiment for you, though? >>> >>> Best regards, >>> >>> -- >>> Aymeric. >>> >> >> >> After keeping in mind your valuable feedback I have decided to change my >> project proposal. >> >> I'm halfway through my formal proposal which contains the details >> required as per the guidelines provided on Django GSoC page. >> But would like to discuss with you the idea first for your valuable >> feedback. >> >> Django templating engine and jinja2 while being very efficient in their >> way still have some drawbacks. >> 1)Not enough freedom to implement logic in a template. Python functions >> can't be called inside the template. >> 2)Once the templating language syntax is applied to the template it >> creates readability issues for the front-end developer. This leads to two >> different development branches. >> If a front-end developer changes some of the parts in his template then >> the back-end developer has to make amendments manually each time. >> His job is not finished even after he has generated the content of the >> page dynamically. >> 3)The time required by the engines to generate the HTML content is more >> for large data. First, the QRM fetches the data from the database, then >> templating engine populates it on the template. >> >> I intend to first generate the HTML content according to the requirements >> of the developer using his programming skills in an exact way required and >> then place it inside the template. >> >> The library will have functions exactly similar to the HTML tags so that >> a python developer can reproduce the HTML code made by the front-end >> developer. >> Or a person with some knowledge of HTML or following the documentation of >> the library can design the page according to his requirement. >> >> The main benefit of doing this is that freedom in generating any HTML >> content can be given to the developer. >> >> I'm not experienced enough to comment on any of the drawbacks of >> templating engine but I listed these points based on my own personal >> experience I got from some of my past projects. >> And hence I need to know your views on this and would really appreciate >> if you could suggest me anything from your side. >> >> Regards, >> Manasvi Saxena >> > -- > 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 [email protected]. > To post to this group, send email to [email protected]. > Visit this group at https://groups.google.com/group/django-developers. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/c4a290e2-ca6a-476e-8339-57c967db6a53%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/c4a290e2-ca6a-476e-8339-57c967db6a53%40googlegroups.com?utm_medium=email&utm_source=footer> > . > 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CACiOJ6uwyScAH%2B4bww3CivCZhq2q25oHyBKWUUK%2BPjHKMaW88Q%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
