GSoC 2018

[Manasvi Saxena]

Hello,

My name is Manasvi Saxena and I wish to spend my summer coding for Django.

NOTE: This is not a formal proposal. I only intend to introduce my idea to the Django-developer community for your valuable feedback and guidance.

My proposal-

Create libraries in python and integrate them with Django to generate HTML code for front-end development and thus contributing to make Django a full-stack framework.

About my proposal-

A Short story...

"I started writing codes in python four years back and ever since I have been passionate about the language. 

A few months ago when I was given a task of making a blog for my friend, I learned the basics of HTML, CSS, and Bootstrap and made a static website for her. But it was not enough as the content needed to be added dynamically and it is when I was introduced to Django, a framework written in the language I love.

And ever since I have been using it."

Why this idea?

For Python developers, it is an extra work to learn HTML and CSS to create a Front-end for a website. I intend to simplify their life by creating libraries that will convert Python code into HTML code to generate an HTML page. This feature, if implemented in Django will make it a one-stop solution for any python developer looking forward to making a website requiring only the knowledge of his or her programming skills in Python.

Conclusion...

Details of how I intend to implement my idea along with the detailed description of what I intend to do will be mentioned in my GSoC proposal.
Please let me know what do you think of the idea and help me refine it.

About me-

I am a penultimate year Electronics and Communication student.
Having done multiple projects in past, I have also recently completed a two-month internship at the position of Back-end web developer at a startup. And hence I'm experienced enough to build things from scratch and work under pressure with short deadlines.

Github username- minusv23

[Joe Tennies]

While I'm not a deciding member by any means, I have seen enough proposals to get a feel for what may be chosen. You left a very open idea of what you plan to do. You are going to need to be specific as to what you plan to do to accomplish your end goals and probably provide at least some sample that shows off that you can do what you plan to do. Think launching a Kickstarter campaign.

Do you intend to use one of the existing libraries like Brython or pyjs for the Javascript side? I can think of some interesting things that could be brought over from the Drupal world that could later be leveraged into something like Wagtail.

--
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+unsubscribe@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/CADwzVRvSLYGOAyxsRWm%2BRN4hKwK3S3ig3dQNQzhNj2PRSebP2A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--

Joe Tennies
ten...@gmail.com

[uri...@gmail.com]

> existing libraries like Brython or pyjs for the Javascript side

Also http://www.skulpt.org/ , used by https://anvil.works/ 

To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@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/CADwzVRvSLYGOAyxsRWm%2BRN4hKwK3S3ig3dQNQzhNj2PRSebP2A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--

Joe Tennies
ten...@gmail.com

[Aymeric Augustin]

Hello Manasvi,

On 14 Mar 2018, at 09:09, Manasvi Saxena <msma...@gmail.com> wrote:

Create libraries in python and integrate them with Django to generate HTML code for front-end development and thus contributing to make Django a full-stack framework.

For Python developers, it is an extra work to learn HTML and CSS to create a Front-end for a website. I intend to simplify their life by creating libraries that will convert Python code into HTML code to generate an HTML page.

Please let me know what do you think of the idea and help me refine it.

I'm skeptical of the concept of building web pages in code without learning and understanding some HTML.

To me it looks like your proposal will require users to learn HTML and your system instead of just HTML.

Any language or system needs to be debuggable. Debugging in a web browser requires reading HTML.

People who spent years building websites came up with template languages such as Django's template language and Jinja2 to solve this problem.

The mainstream system that most resembles what you're describing is "React without JSX" (not really mainstream to be honest). It isn't very popular; virtually everyone uses JSX, a template language.

I'm afraid you'll have a hard time finding a committer who's willing to shepherd that GSoC project.

Best regards,

-- 

Aymeric.

[Manasvi Saxena]

Hello sir,

To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@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/CADwzVRvSLYGOAyxsRWm%2BRN4hKwK3S3ig3dQNQzhNj2PRSebP2A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--

Joe Tennies
ten...@gmail.com

I have made a prototype of how I'm going to implement my idea.

I have made a module named 'pyhtml.py' and using that module I have written a sample program named 'sample.py', generated HTML page using the module is hosted using GitHub pages.

Link to the repository- https://github.com/minusv23/pyhtml

Link to the created page- https://minusv23.github.io/pyhtml/

This is just to give a gist of how I intend to move further and is at a very early stage.

Have a look at it and advise me on how to move forward with the proposal and more importantly what do you think of it?

Also, thank you so much for your suggestion regarding the javascript libraries. I am currently working on that part only.

Regards,

Manasvi Saxena

[Manasvi Saxena]

Hello Sir,

Thank you so much for your suggestion.

I have made a prototype of how I'm going to implement my idea.

Link to the repository- https://github.com/minusv23/pyhtml

Link to the created page- https://minusv23.github.io/pyhtml/

This is just to give a gist of how I intend to move further and is at a very early stage.

Have a look at it and advise me on how to move forward with the proposal and more importantly what do you think of it?

Regards,

Manasvi Saxena 

[Manasvi Saxena]

Hello Sir,

I have made a prototype of how I'm going to implement my idea.

This is just to give a gist of how I intend to move further and is at a very early stage.

Link to the repository- https://github.com/minusv23/pyhtml

Link to the created page- https://minusv23.github.io/pyhtml/

I agree with the concerns you have raised that the user will have to learn the concept of HTML as well as that of my system, but I will be writing complete documentation of my 

library including which function corresponds to which result with examples.

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.

The HTML page generated was completely programmed in Python using the library I created.

Regards,

Manasvi Saxena 

[Aymeric Augustin]

Hello,

2018-03-15 14:24 GMT+01:00 Manasvi Saxena <msma...@gmail.com>:

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.

[Manasvi Saxena]

Hello,

I think you are assuming a lot of things which I've planned to implement in a way much different than the code example you've posted above. As far as Django is concerned this will be much more efficient and easier to use with it. It will make a lot of things very easy to do if someone has an aptitude in Python. I will come up with more details and try to eliminate your concern with a well written proposal covering all aspects of my idea.

Regards,

Manasvi Saxena

[Manasvi Saxena]

Hello Sir, 

Another potential application of the 'pyhtml' library for the developers aware of HTML concepts is that it can be used to implement logic in a webpage.

Right now Django templating language and jinja are very well solving this purpose but this will be an extension of them.

If a developer needs to add data that is very big but can be generated using programming and building logic, then in that aspect, this library as of now only require the user to pass a list inside the generate_html function. That list can be generated using any logic a developer wants in python. 

Instead of putting Jinja or Django templating language directly in the web page you can generate a pure HTML page which can be easily understood by any front-end developer if he wants to debug it. This reduces the effort of both front end and back end developer.

And as I said earlier this was just a prototype. The real library will cover every HTML and CSS tag in the most optimized way possible.
And under the guidance of experienced mentors, Django community has, I believe I'll be able to build something that will add another feather to Django's hat.

Please let me know what do you think of this new perspective.

Regards, 
Manasvi Saxena

[Manasvi Saxena]

Hello Sir,

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

[Josh Smeaton]

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,

[Manasvi Saxena]

Hello Sir,

I'm sorry I wasn't able to explain my points clearly.

First of all, I'm not at all suggesting to discard the current Django templating language and replace it with a new one.
The library I intend to build will only be used to generate HTML content before rendering the page.
No other libraries or modules of Django will be affected. 
Think of it as an extension.

Let me make this more clear to you via a pseudo code,

import pyhtml

a=p("hello world")
a.style("color":"red")

OUTPUT:

<p style="color:red">hello world</p>

You see, the output is pure HTML code and can be easily read and debugged by any front-end developer.
It's not something like 

<p style="color:red">{{message}}</p>

This was just a simple example. Things get more complicated once we use typical Django templating language concepts like "for loop".

Once the back-end developer has generated the dynamically created page, front-end person can make whatever changes he want to, can debug it, can extend it.

Another point that I believe can be considered here is that time taking by ORM to run queries and fetch data plus time taken by the templating language to populate the template can be reduced if we send the HTML code directly.

This library does not intend to replace Django templating language. It just intends to make the work of both, a back-end developer and a front-end developer easy and flexible.

Please let me know what do you think of it now. Share your concerns with me and I'll try my best to explain my idea.

Regards,
Manasvi Saxena

[Joe Tennies]

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

--

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-develop...@googlegroups.com.
To post to this group, send email to django-d...@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/c4a290e2-ca6a-476e-8339-57c967db6a53%40googlegroups.com.

[Josh Smeaton]

This isn't going to work.

1. If you're going to "pre-render" your python files into html files **before** they're filled with data, then you will still need to run django/jinja templating over this pre-rendered template.

2. If you're **not** going to pre-render your python files into html files, then all dynamic data will need to be used in your python file, which will generate the HTML at run time. Then this is exactly no different to what we currently have, except you'd be using a mimic of html as python objects.

3. In either case, this is useless to frontend devs. In the first case, you'd end up overwriting any changes a frontend dev made to the HTML pre-rendered output each time you compiled your python files. In the second case, the frontend dev never gets to see what the rendered html output is.

Again, thank you for your proposal, but this isn't something the django project wants, and is not something we'd sponsor as part of GSoC.

[Journeyman]

Am 16/03/2018 um 21:48 schrieb Manasvi Saxena:

> import pyhtml
>
> a = p("hello world")

> a.style("color":"red")
>
> OUTPUT:
> <p style="color:red;">hello world</p>

I'm not the best expert around here, but trying to build HTML from *any*
pseudo-language sounds like a nightmare to keep the engine updated. HTML
is a fast moving target ...

just my .2 cents

[Manasvi Saxena]

Hello Sir,

I very well understand your concern. And thanks a lot for providing me with this new insight.
My experience with Django is nothing compared to the amount of time you, Aymeric Augustin Sir and Josh Smeaton Sir has put in to bring Django to what it is now.
And whatever you suggest comes out of that experience.

My idea purely came out of what problems I faced while working with Django. I did not have any problem working with any other part of the framework except for the interface between front-end and back-end.
 

Thank you for your time and your valuable feedbacks.
I will try to come up with a different proposal.

Regards,
Manasvi Saxena

[Joe Tennies]

Okay, so the idea is to render HTML by generally defining it in Python. I could've sworn that I'd seen something like this years ago, but I'm failing to find it. That stated, I think this is basically a generating version of BeautifulSoup (https://www.crummy.com/software/BeautifulSoup/bs4/doc/) as opposed to a parsing version.

It's roughly like the Storm ORM (https://storm.canonical.com/) but for HTML instead of database queries.

It's interesting, but I'll ask if one can get 90% of the functionality from xml.etree, which is in the standard Python Library.

import xml.etree.ElementTree as ET

a = ET.Element('p', style='{color: red;}')

a.text = "hello world"

ET.dump(a) # will match yours

Note that this gets even weirder with something like "<p>hello <i>ignore this</i> world</p>".

b = ET.Element('p')

b.text = "hello "

c = ET.Element('i')

c.text = "ignore this"

c.tail = " world"

b.append(c)

ET.dump(b) # will match above

--

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-develop...@googlegroups.com.
To post to this group, send email to django-d...@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/4427f2cd-d843-43db-b807-5f3468635b2e%40googlegroups.com.

[Manasvi Saxena]

Hello Sir,

1. I am suggesting that as soon as the data is fetched from the database create its HTML then and their only.
For example-
If I make an app to fetch data from the database of students of a particular class and intend to make Report card out of it.
Then as soon as I have fetched the data I declare a different function which just generating its HTML code using the library and passing it to the generate HTML function in the end. It'll create a new HTML file out of the content of the list.
The resultant HTML file need not be rendered but simply return as HTTP Response.
The resultant HTML file at least makes it debuggable by front-end developer. 

2. Also a major point you are overlooking here is that this can be used to break the old cycle of-
QRM->make changes in data and return it in the exact way the Django templating language needs it to be->Render->django templating language generating the data.
and can introduce a new cycle of-
QRM->manipulating fetched data with full freedom to use any Python programming logic->make its HTML->modify the page.(not fully generate create it from scratch or over write it. Hence reducing the time to display data from scratch every time a page is refreshed.)

3. Point no.3 can be easily taken care of coming up with efficient file handling functions in the library itself.

See I get it that this idea might not be fit for Django but I'm just trying to come up with explanations to your concerns and trying to bring more confidence in my idea.
We can discuss further the loopholes in the idea and if it didn't work out I'll understand.

Regards,
Manasvi Saxena

[Manasvi Saxena]

Hello Sir,

Okay, so the idea is to render HTML by generally defining it in Python. I could've sworn that I'd seen something like this years ago, but I'm failing to find it. That stated, I think this is basically a generating version of BeautifulSoup (https://www.crummy.com/software/BeautifulSoup/bs4/doc/) as opposed to a parsing version.

It's roughly like the Storm ORM (https://storm.canonical.com/) but for HTML instead of database queries.

It's interesting, but I'll ask if one can get 90% of the functionality from xml.etree, which is in the standard Python Library.

import xml.etree.ElementTree as ET

a = ET.Element('p', style='{color: red;}')

a.text = "hello world"

ET.dump(a) # will match yours

Note that this gets even weirder with something like "<p>hello <i>ignore this</i> world</p>".

b = ET.Element('p')

b.text = "hello "

c = ET.Element('i')

c.text = "ignore this"

c.tail = " world"

b.append(c)

ET.dump(b) # will match above

I'm sure xml.etree has its drawbacks which I will improve in my library.
The whole idea here is to bring python closer in the picture of generating HTML content.
Its applications are vast and not only limited to this. If time permits I intend to write a complete framework like Bootstrap for python where things like cards, navbars etc will be inbuilt and purely written on the basis of my library.
And that is the new feather I intend to add to Django's hat.
Just like we have some inbuilt  'forms' in Django we'll have a lot of other front-end related objects written in python and easily manipulative.
And thus I intend to extend Django's reign in the front-end domain as well. And make it a full-stack framework.
Surely designing is something that changes very frequently in today's world but if this is successfully implemented we can bring developers from front-end world to contribute to it too. 
Logic + Design.

Regards,
Manasvi Saxena

[Tom Forbes]

Hey Manasvi,

I don't have any say in the choice of a GSOC student, but I'd like to add my two cents nonetheless.

I can see the logic behind your proposal, but I'm skeptical about the usefulness of such a project. Libraries that implemented something similar to this have come and gone, and got good reason, they where not very practical and other solutions where much easier to use.

In the time since frontend frameworks have proliferated and JavaScript has become much more mature. Anything we do in this space seems like it will be dead on arrival compared to something like React or Ember, which already do this but with huge huge advantages over your approach.

In my humble opinion anything in this space will have to treat JavaScript as a first class citizen - i.e something that makes the interoperability between a JavaScript frontend and a Django backed easier would have some benefits, but generating HTML in pure python on the backend by writing components in Python does not have a bright future IMO.

Tom

--

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+unsubscribe@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/2cf482cc-0f2e-4182-ae34-951a74b43731%40googlegroups.com.

[Manasvi Saxena]

Hello Sir,

To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@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/2cf482cc-0f2e-4182-ae34-951a74b43731%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

I haven't fully submitted my GSoC proposal yet hence I understand your concern regarding javascript.
For including javascript I intend to use libraries such as Brython and Pyjs in my project.
The framework I'll be building in the end for aiding in front-end will comprise of this feature.
Please let me know what you think of the proposal now.

Regards,
Manasvi Saxena

[Manasvi Saxena]

Hello Sir,

On Saturday, March 17, 2018 at 5:39:34 AM UTC+5:30, Tom Forbes wrote:

To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@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/2cf482cc-0f2e-4182-ae34-951a74b43731%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

I understand your point now. That was a really helpful advice. I'll definitely try to move forward in that direction too.
Supposedly I am able to do that, what do you think of the proposal then? Is it worth giving a chance?

Regards,
Manasvi Saxena 

[Tom Forbes]

Hey Manasvi,

I'm perhaps a bit biased but I would be very interested in anything that can make JavaScript a real first class citizen in Django. There are a number of third party packages out there that attempt something like this (i.e django-webpack-loader). Django is classically quite conservative, and up until relatively recently the JavaScript ecosystem has been in flux with a relatively high amount of churn when it comes to build tools and best practices. 

Things have somewhat stabalized recently with webpack achieving widespread adoption so perhaps it's time to evaluate the landscape and see if we can improve in this area. I'd love to see some kind of pluggable JavaScript build system that would make modern JavaScript a first class citizen alongside templates and other static assets, separate or as an extension to the classic static assets functionality in Django.

All in all I am quite jealous of how Rails handles JavaScript integrations[1]. Again, this is just my personal opinion and I cannot say if pursuing this will in any way effect your chances of being accepted but this seems likes really interesting direction to investigate and more practically useful than yet another way of generating static server side HTML.

Tom

×

1. https://medium.com/@hpux/rails-5-1-loves-javascript-a1d84d5318b

To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscribe@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/d7c3d5a2-a205-4aea-adf9-2758df190d09%40googlegroups.com.

[Manasvi Saxena]

Hello Sir,

Hey Manasvi,

I'm perhaps a bit biased but I would be very interested in anything that can make JavaScript a real first class citizen in Django. There are a number of third party packages out there that attempt something like this (i.e django-webpack-loader). Django is classically quite conservative, and up until relatively recently the JavaScript ecosystem has been in flux with a relatively high amount of churn when it comes to build tools and best practices. 

Things have somewhat stabalized recently with webpack achieving widespread adoption so perhaps it's time to evaluate the landscape and see if we can improve in this area. I'd love to see some kind of pluggable JavaScript build system that would make modern JavaScript a first class citizen alongside templates and other static assets, separate or as an extension to the classic static assets functionality in Django. 

All in all I am quite jealous of how Rails handles JavaScript integrations[1]. Again, this is just my personal opinion and I cannot say if pursuing this will in any way effect your chances of being accepted but this seems likes really interesting direction to investigate and more practically useful than yet another way of generating static server side HTML.

Tom

Thank you for this new approach that you have shared. I would love to work on it since I have the required skills in both HTML and JavaScript to do this.
I'll make a new proposal keeping in mind what you have suggested and will get back to you as soon as I have it ready.
Would really love to know your views on that too.
Thank you so much for the advice.

Regards,
Manasvi Saxena

 

[Jani Tiainen]

Hi.

As pointed out I believe this is not getting accepted as GSoC project for Django.

But if you really believe that your approach is beneficial to larger audience and you feel that it is right thing to do just do it. It is only way to prove that you're right. Of course you could be wrong as well but hey at least you did tried.

Having JavaScript builder pipeline might provide more fruitful though getting such as GSoC project is really long shot.

--

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-develop...@googlegroups.com.
To post to this group, send email to django-d...@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/00e13803-b9af-4c76-9f0d-9d1f226c0acf%40googlegroups.com.

[Manasvi Saxena]

Hello,

On Saturday, March 17, 2018 at 12:42:50 PM UTC+5:30, Jani Tiainen wrote:

Hi.

As pointed out I believe this is not getting accepted as GSoC project for Django.

But if you really believe that your approach is beneficial to larger audience and you feel that it is right thing to do just do it. It is only way to prove that you're right. Of course you could be wrong as well but hey at least you did tried.

Having JavaScript builder pipeline might provide more fruitful though getting such as GSoC project is really long shot.

Did you go through what my initial idea was? what do you think of that? the pyhtml library and assisting Django templating language. Do you have any suggestions on how I can improve that too?
Also, can you through some light on what you said about JavaScrip builder pipeline?
I could really use your valuable feedback.

Regards,
Manasvi Saxena  

[Jani Tiainen]

Hi. 

Yes I read your initial proposal and in my experience putting any frontend stuff to python code is disaster. Hard to maintain hard to understand when  pages do get more complex.

In my understanding it is also general consencus and for that reason Django itself moved form widget rendering from python code to template based widgets.

--

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-develop...@googlegroups.com.
To post to this group, send email to django-d...@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/c7d3227d-10e9-4775-92af-9acb36554759%40googlegroups.com.

[Manasvi Saxena]

Hello Sir,

On Saturday, March 17, 2018 at 1:16:15 PM UTC+5:30, Jani Tiainen wrote:

Hi. 

Yes I read your initial proposal and in my experience putting any frontend stuff to python code is disaster. Hard to maintain hard to understand when  pages do get more complex.

In my understanding it is also general consencus and for that reason Django itself moved form widget rendering from python code to template based widgets.

la 17. maaliskuuta 2018 klo 9.26 Manasvi Saxena <msma...@gmail.com> kirjoitti:

Hello,

On Saturday, March 17, 2018 at 12:42:50 PM UTC+5:30, Jani Tiainen wrote:

Hi.

As pointed out I believe this is not getting accepted as GSoC project for Django.

But if you really believe that your approach is beneficial to larger audience and you feel that it is right thing to do just do it. It is only way to prove that you're right. Of course you could be wrong as well but hey at least you did tried.

Having JavaScript builder pipeline might provide more fruitful though getting such as GSoC project is really long shot.

Did you go through what my initial idea was? what do you think of that? the pyhtml library and assisting Django templating language. Do you have any suggestions on how I can improve that too?
Also, can you through some light on what you said about JavaScrip builder pipeline?
I could really use your valuable feedback.

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-develop...@googlegroups.com.
To post to this group, send email to django-d...@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/c7d3227d-10e9-4775-92af-9acb36554759%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Also, can you through some light on what you said about JavaScrip builder pipeline?

Regards,
Manasvi Saxena 

[Dmitriy Sintsov]

Hi!

Template languages are my favorite topic in programming.

If you implement html library yourself, it is much better to define tags not as functions but as classes with base Tag class which has properties for tag name, attributes and the nested list of tags. Such way you will re-implement DOM, although it is already available in lxml library.

So maybe it's a better idea to figure out whether lxml can be used as template engine for Django, because it can load source html into nested structures via binary optimized code. It should be cleaner and faster than manual composition of html in Python code.

In such case bindings could be performed via data-bind attribute like in Knockout,js or via Vue-like v-bind attribute:

http://knockoutjs.com/documentation/observables.html

https://vuejs.org/v2/guide/syntax.html#Attributes

Binding server-side data via html5 data attributes is the most non-obtrusive approach, and it does not create syntax clashes with server-side templates like DTL or Jinja which use double braces, semantically alien to XML / HTML (however Jinja is much more than html templating, it's an arbitrary text templating engine and an almost complete language itself).

But the most interesting thing in such approach are custom tags, including nested custom tags - so-called "components".

It was implemented ages ago in XSLT, where one may define small template with xml tags which then are transformed into larger, more verbose html:

https://www.w3schools.com/xml/xsl_transformation.asp

It is also supported in lxml:

http://lxml.de/xpathxslt.html

But XSL / XSLT did not gain wide adaption because the language syntax is made via XML tags and attributes thus became very verbose and difficult to read.

Maybe you could create template language like XSLT but with Python syntax? How's about such idea?

For example, Python XSLT-like well-readable transformation code could be dynamically converted to XSL style sheet then the XSL style sheet applied to source template to produce the final html.

https://www.w3schools.com/xml/xsl_transformation.asp

    <xsl:for-each select="catalog/cd">
    <tr>
      <td><xsl:value-of select="title"/></td>
      <td><xsl:value-of select="artist"/></td>
    </tr>

Instead xsl:for-each there will be Python's for, shorter and cleaner version, translated to xsl:for-each via AST parser.

Dmitriy

[Curtis Maloney]

On 03/17/2018 07:37 PM, Dmitriy Sintsov wrote:
> Hi!
>
> Template languages are my favorite topic in programming.

Having written a few template engines myself... I guess it's high on my
list too :)

> If you implement html library yourself, it is much better to define tags
> not as functions but as classes with base Tag class which has properties
> for tag name, attributes and the nested list of tags. Such way you will
> re-implement DOM, although it is already available in lxml library.
>
> So maybe it's a better idea to figure out whether lxml can be used as
> template engine for Django, because it can load source html into nested
> structures via binary optimized code. It should be cleaner and faster
> than manual composition of html in Python code.

Now, I like this idea as a line of inquiry.

Despite the Django Template Language being explicitly designed to _not_
use HTML syntax [like so many before it did] so as (a) not create
torturous syntaxs, and (b) not restrict it to just HTML...

I think for the case of knowingly generating HTML, using lxml opens the
door to:
1. ensuring valid markup
2. faster processing [maybe?]
3. minifying on the fly -- readable templates, minimal output.

--
Curtis

[Manasvi Saxena]

Hello sir,

I can't tell you how happy I'm to read your mail. This was the type of feedback I was craving for.
The prototype I have created uses functions, for now, that's because I just thought of giving a basic idea of what my library will contain.
Yes, I'll use concepts of class to write tags and not functions as a whole.
And that's why I feel an obvious need of a good mentor who can provide his or her insight on things I'll do during my GSoC project.

I intend to create a templating language with python syntax. Can you suggest me how should I move forward with my application and increase my chances of getting selected?

Best regards,
Manasvi Saxena 

[Manasvi Saxena]

Hello Sir,

I was trying to explain the exact pros you have stated above and those were the main reason behind how I come up with this idea.
Can you guide me how I should move forward with my idea in order to increase my chances of getting selected in spite of that fact that it's rejected by the members of Django core team?

Best regards,
Manasvi Saxena

[Dmitriy Sintsov]

Hi!

I think you should read the links about Knockout.js templates, Vue.js templates and about XSLT templates and their support via lxml library.

Read about custom tags in XSLT and maybe in JSX.

Also read more about lxml library and how to use it.

Hope that will help you to improve your proposal.

Dmitriy

--
You received this message because you are subscribed to a topic in the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/django-developers/ldhY8sAQc-0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to django-developers+unsubscribe@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/4e742fb4-84ab-4ae1-9aca-f6c2c79b4f24%40googlegroups.com.

[Manasvi Saxena]

Hello Sir,

On Saturday, March 17, 2018 at 2:49:41 PM UTC+5:30, Dmitriy Sintsov wrote:

Hi!

I think you should read the links about Knockout.js templates, Vue.js templates and about XSLT templates and their support via lxml library.

Read about custom tags in XSLT and maybe in JSX.

Also read more about lxml library and how to use it.

Hope that will help you to improve your proposal.

Dmitriy

Thank you so much for your guidance. I'll definitely look into it and try to come up with a more detailed proposal as soon as possible so that it can be refined before submitting it finally.

Best regards,
Manasvi Saxena

[Curtis Maloney]

Well, you should probably look at past examples of such things, like TAL
for the server side, and ... just about every JS framework of today
(svelte, Vue, Knockout, etc :)

lxml should make it easy to parse, iterate, walk, mutate the DOM tree...
now you need to determine a syntax.

--
Curtis

[Manasvi Saxena]

Hello Sir,

Well, you should probably look at past examples of such things, like TAL
for the server side, and ... just about every JS framework of today
(svelte, Vue, Knockout, etc :)

lxml should make it easy to parse, iterate, walk, mutate the DOM tree...
now you need to determine a syntax.

--
Curtis

--
You received this message because you are subscribed to a topic in the Google Groups "Django developers  (Contributions to Django itself)" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/django-developers/ldhY8sAQc-0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to django-develop...@googlegroups.com.

To post to this group, send email to django-d...@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/b708db98-2fe9-fcdf-cb1b-3978e5ee4eb2%40tinbrain.net.

For more options, visit https://groups.google.com/d/optout.

Thank you so much for your advice sir. I'll move forward with my proposal and present to you a detailed version of how I will execute my idea for your valuable feedback.

Best regards,

Manasvi Saxena

[Manasvi Saxena]

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. 

[ludovic coues]

--

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-develop...@googlegroups.com.
To post to this group, send email to django-d...@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.

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

[Manasvi Saxena]

Hello Sir,

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

I simply intend to create an option for the developer to use python for templating rather than DTL or jinja.

Is Python fast compared to any other templating language? Yes.
Why do we need to process the data using any other language when we are building our app in python.
Sure DTL or Jinja are python-like, but they are not python.
I intend to develop every functionality offered by jinja or DTL in my python library and to make it more flexible to use.
Plus the advantage over the current templating system would be speed.
Returning an HTML page with large data is faster than rendering it using DTL.

And templating in python would give an upper hand over templating in DTL.
Yes, the Django templating language has been developed over years but making another option for the developer to choose from does not have any harm.

On the Google Summer of Codes submit application page, Django is asking to choose from two option.
1. Optimization

2. Add new feature

This is the new feature I wish to add.
It has advantages over the previous one.

For now, I'm not asking Django to replace DTL, I'm simply asking to consider my idea and provide me with an opportunity of developing it under the guidance and experience of a mentor.
There will be three evaluations of the project, reject the idea in any of the evaluation if doesn't seem to be promising. But at least provide with an opportunity to prove it at least.

Regards,
Manasvi Saxena

[Aymeric Augustin]

Hello,

> On 18 Mar 2018, at 09:45, Manasvi Saxena <msma...@gmail.com> wrote:
>
> I simply intend to create an option for the developer to use python for templating rather than DTL or jinja.
> Is Python fast compared to any other templating language? Yes.

No.

Jinja2 compiles to Python bytecode so it's as fast as Python — and probably faster than what you'd write in three months because a lot of effort went into optimizing its performance over the years.

Here's an analogy: "is assembly fast compared to any other programming language?" The answer to that is "No" as well.

> Why do we need to process the data using any other language when we are building our app in python.

20 years of industry show that backend developers prefer template languages for writing templates. Even PHP, which is originally a template language, saw the development of Smarty.

And frontend developers want something that isn't too remote from HTML.

> Sure DTL or Jinja are python-like, but they are not python.
> I intend to develop every functionality offered by jinja or DTL in my python library and to make it more flexible to use.

I'd like an examples of something useful that Jinja2 can't do and where more flexibility is needed. Jinja2 provides logic constructs and arbitrary function calls. (So does DTL but with less convenient APIs.)

> Plus the advantage over the current templating system would be speed.
> Returning an HTML page with large data is faster than rendering it using DTL.
> And templating in python would give an upper hand over templating in DTL.
> Yes, the Django templating language has been developed over years but making another option for the developer to choose from does not have any harm.

A library that meets all these requirements exists already: Jinja2. I added first class support for Jinja2 in Django. (Even though additional integration work could be envisioned, I haven't heard demand for that.)

> On the Google Summer of Codes submit application page, Django is asking to choose from two option.
> 1. Optimization
> 2. Add new feature
>
> This is the new feature I wish to add.
> It has advantages over the previous one.

I haven't seen those advantages and I think that's because you don't know the previous one well enough.

> For now, I'm not asking Django to replace DTL, I'm simply asking to consider my idea and provide me with an opportunity of developing it under the guidance and experience of a mentor.
> There will be three evaluations of the project, reject the idea in any of the evaluation if doesn't seem to be promising. But at least provide with an opportunity to prove it at least.

Sorry if I'm being blunt here but there've been a dozen messages already indicating that you're going into a dead end. I'm afraid we're wasting time.

Your prejudice against DTL and Jinja2 is incorrect. I'm not taking issue with the solutions you propose but with the problem you'd like to address.

To discuss solutions, we'd have to agree there's a problem worth solving. Even after you proposed multiple angles, I'm still not seeing it.

Best regards,

--
Aymeric.

[Elnard Utiushev]

Hello!

My name is Elnard. I study Computer Science at Purdue University in the US. I do not have a lot of experience with Django, but I have some experience with Python and a lot of experience with JS. My GitHub.

My general idea is to create a new template for Django's startapp that will have a folder with webpack config. Webpack is a bundler that is widely used by web developers. Webpack will preconfigured to minify and transpile javascript files and preprocess CSS, LESS, and SASS. All files generated by webpack will be moved to static folder, so people could use them in templates. Syntax similar to Django's Media class syntax can be used to provide entry points for webpack, so users will not have to edit webpack config themselves. As I understand, it is possible to use ready method to do all necessary actions before actual server start. Since all needed files will be moved to static folder, the app can be moved and used even if user do not have node and npm installed. 

[Jani Tiainen]

Hi.

About javascript pipeline.

Basically having (pluggable) toolchain and practices to manage JavaScript assests or stylesheets for example.

Tom Forbes described it quite well in his latter message.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/ef819f36-9ace-4613-8c38-423a36677638%40googlegroups.com.