On Sat, 17 Mar 2018, 21:55 Manasvi Saxena, <msmana...@gmail.com> wrote:
> Hello Sir,
>
> 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.
>>
>
>
> I have decided to drop my earlier idea to create a python to HTML library.
>
> But I still believe that Django templating language(DTL) or Jinja has some
> limitations and drawback. First of all, as I said earlier for large data
> set it takes more time. Secondly, it has limited scope for flexibility
> while implementing logic.
> The solution I was offering earlier for it was deeply flawed as mentioned
> above by you.
> I have decided to create an approach that (a) can cross
> communicate between jinja and DTL. (b) is easy to maintain and use.
>
> What I'm planning to do is to provide a library that can inject data into
> the template before rendering the template.
>
> For now, assume that there will be a function, only a single function, let
> us call it
>
> *populate(replace_with, new_content)*
>
> Now inside the template just like DTL ask us to write {{variable_name}} we
> now have to write let say
>
> *<!-->replace_with<-->*
>
> The above function when called will look into the file for the
> *"replace_with" *variable and will replace it will with *"new_content".*
> This was just a simple example, simplest example I would say. The real
> functionality will be different from it.
>
> *"populate"* function can replace HTML content, plain text, or even a
> list of *new_content*. Anything that is within our custom tag will be
> replaced with the *new_content.*
>
> Benefits of this approach include:
> 1. Generation of HTML page with dynamically populated data and simply
> serving it through *HttpResponse() *[Fast maybe].
> 2. Flexibility in implementing any logic. As soon as you have the data
> call *populate() *and place it inside the template.
> 3. DTL can still be used for providing any other functionality if the need
> persists. However, I intend to cover every functionality offered by DTL in
> it.
> 4. While for some cases DTL works in a really optimized manner, it will be
> in the hands of the developer to chose which approach to follow.
> 5. It does not require the developer to learn anything extra other than
> DTL (or if successfully implemented, not even DTL).
>
> Things I'll work on is to
> 1. Find an efficient way to implement *populate() *function. While we do
> have a naive approach to finding next and replacing. I intend to find an
> optimized way to implement this function.
> 2. Making the library compatible with the existing Django features. No
> changes will be made to any existing features. It'll act as an API and will
> work independently of any other Django library.
>
> Please let me know what do you think of this new approach so that I can
> refine my idea.
>
> 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 django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> 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/3033808a-ccf9-4cb1-ad8b-6d2e19cca64b%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/3033808a-ccf9-4cb1-ad8b-6d2e19cca64b%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>
I like theses idea less and less evertime.
What is your usecase for a smarter rendering engine ? You can already
compute complex things in the view, store it in the rendering context and
simply display it in the template.
The first idea was only slightly in the wrong direction, but could produce
some valuable work. Producing HTML using python is awkward. But producing
interface is another matter. If your library provide ban interface like "on
the left there is a listView widget, connected to this queryset. When an
item is selected, it will use that function to generate a rich widget for
editing the model and display the widget on the right".
That kind of library would be a lot more like writing gtk or Qt
application. There are other webframework doing that, I'm thinking of
nitrogen, an Erlang framework. Maybe toga-django already try to produce
such library
>
--
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 django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
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/CAEuG%2BTZqXMenXAR%2BtT4p06yH5Si5XU2F6tav3MWNuPxBQwvoCQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
