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.
On Saturday, 17 March 2018 07:48:46 UTC+11, Manasvi Saxena wrote:
>
> Hello Sir,
>
> On Saturday, March 17, 2018 at 1:57:00 AM UTC+5:30, Josh Smeaton 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 <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.
>>>>
>>>
>>>
>>> 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
>>>
>>
>
> 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 pyhtmla=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
>
--
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/b513a188-4c70-40de-8991-a90fd385b272%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
