subject:"GSoC 2018"

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 

**

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

Re: GSoC 2018

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-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/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

>

-- 
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/CADwzVRsY5b78GXFK33eokWUNNopLebDPSXWyTT4HgknjwPD-Dw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: GSoC 2018

2018-03-17 Thread Curtis Maloney

On 03/17/2018 08:18 PM, Manasvi Saxena wrote:

Hello Sir,

On Saturday, March 17, 2018 at 2:23:45 PM UTC+5:30, Curtis Maloney wrote:

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

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?

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 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/b708db98-2fe9-fcdf-cb1b-3978e5ee4eb2%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.

Re: GSoC 2018

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

-- 
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/8720634c-05ea-4a08-812a-d9b7ca4e43e6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: GSoC 2018

2018-03-17 Thread 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


On Sat, Mar 17, 2018 at 12:12 PM, Manasvi Saxena 
wrote:

> Hello sir,
>
>
> On Saturday, March 17, 2018 at 2:07:03 PM UTC+5:30, Dmitriy Sintsov wrote:
>>
>> 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
>>
>> 
>> 
>>   
>>   
>> 
>>
>> Instead xsl:for-each there will be Python's for, shorter and cleaner
>> version, translated to xsl:for-each via AST parser.
>>
>> Dmitriy
>>
>
>
> 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
>
> --
> 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+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/4e742fb4-84ab-4ae1-9aca-
> f6c2c79b4f24%40googlegroups.com
> 
> .
>
> 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 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

Re: GSoC 2018

Hello Sir,

On Saturday, March 17, 2018 at 2:23:45 PM UTC+5:30, Curtis Maloney wrote:
>
> 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 
>
>
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

-- 
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/3b257c11-9c9f-482f-8a97-72914bf8f9e5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: GSoC 2018

Hello sir,

On Saturday, March 17, 2018 at 2:07:03 PM UTC+5:30, Dmitriy Sintsov wrote:
>
> 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
>
> 
> 
>   
>   
> 
>
> Instead xsl:for-each there will be Python's for, shorter and cleaner 
> version, translated to xsl:for-each via AST parser.
>
> Dmitriy
>


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 

-- 
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/4e742fb4-84ab-4ae1-9aca-f6c2c79b4f24%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: GSoC 2018

2018-03-17 Thread 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

--
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/f690efb3-7d6b-042b-68dc-76cfa8afec5c%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.

Re: GSoC 2018

2018-03-17 Thread 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

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

Dmitriy
On Saturday, March 17, 2018 at 1:35:49 AM UTC+3, Manasvi Saxena wrote:
>
> 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 "hello ignore 
>> this world".
>>
>> 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
>

-- 
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/67d7a24c-d508-41cd-ab52-c3415cbb5131%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: GSoC 2018

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  > 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 

-- 
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/ef819f36-9ace-4613-8c38-423a36677638%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: GSoC 2018

2018-03-17 Thread 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.

la 17. maaliskuuta 2018 klo 9.26 Manasvi Saxena 
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-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/c7d3227d-10e9-4775-92af-9acb36554759%40googlegroups.com
> 
> .
> 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 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/CAHn91ofs-e7yHSfLZC0feEbi%2B_aYEa3%2B329Rd%3DGC%2BVyco6HL%2Bg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: GSoC 2018

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-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/c7d3227d-10e9-4775-92af-9acb36554759%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: GSoC 2018

2018-03-17 Thread 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.



la 17. maaliskuuta 2018 klo 6.49 Manasvi Saxena 
kirjoitti:

> 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
>
>
> --
> 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/00e13803-b9af-4c76-9f0d-9d1f226c0acf%40googlegroups.com
> 
> .
> 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 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/CAHn91oeKEmdRAwBqWjeBdt2BbT9aYsrUnBMoUAL0tD4Mg6Jnug%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: GSoC 2018

2018-03-16 Thread 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

On 17 Mar 2018 03:14, "Manasvi Saxena"  wrote:

Hello Sir,

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

> 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
>
> On 16 Mar 2018 22:36, "Manasvi Saxena"  wrote:
>
>> 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 "hello ignore
>>> this world".
>>>
>>> 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
>>
>> --
>> 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.

Re: GSoC 2018

Hello Sir,

On Saturday, March 17, 2018 at 5:39:34 AM UTC+5:30, Tom Forbes wrote:
>
> 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
>
> On 16 Mar 2018 22:36, "Manasvi Saxena"  
> wrote:
>
>> 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 "hello ignore 
>>> this world".
>>>
>>> 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
>>
>> -- 
>> 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/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 

-- 
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/d7c3d5a2-a205-4aea-adf9-2758df190d09%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: GSoC 2018

Hello Sir,

On Saturday, March 17, 2018 at 5:39:34 AM UTC+5:30, Tom Forbes wrote:
>
> 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
>
> On 16 Mar 2018 22:36, "Manasvi Saxena"  
> wrote:
>
>> 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 "hello ignore 
>>> this world".
>>>
>>> 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
>>
>> -- 
>> 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/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

-- 
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

Re: GSoC 2018

2018-03-16 Thread 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

On 16 Mar 2018 22:36, "Manasvi Saxena"  wrote:

> 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 "hello ignore
>> this world".
>>
>> 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
>
> --
> 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/2cf482cc-0f2e-4182-ae34-
> 951a74b43731%40googlegroups.com
> 
> .
> 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 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/CAFNZOJOwW59_TYcg8w1JVBOFXoNP5SjC%2BxDZCg49oH%2Bh%2BUZAOQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: GSoC 2018

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 "hello ignore 
> this world".
>
> 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

-- 
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/2cf482cc-0f2e-4182-ae34-951a74b43731%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: GSoC 2018

Hello Sir,

On Saturday, March 17, 2018 at 3:08:02 AM UTC+5:30, Josh Smeaton wrote:
>
> 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 :
>
>> 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.
>
> content 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

Re: GSoC 2018

2018-03-16 Thread 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 "hello ignore
this world".

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

On Fri, Mar 16, 2018 at 3:48 PM 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 :

> 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.

 content 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

Re: GSoC 2018

Hello Sir,

On Saturday, March 17, 2018 at 2:44:03 AM UTC+5:30, Rotund wrote:
>
> 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  > 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 :

> 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.

 content 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

Re: GSoC 2018

2018-03-16 Thread Journeyman

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

> import pyhtml
> 
> a = p("hello world")
> a.style("color":"red")
> 
> OUTPUT:
> hello world

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

-- 
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/f0ab11a7-b892-5b44-ba1b-1287643f71a1%40storiepvtride.it.
For more options, visit https://groups.google.com/d/optout.


0x60CDC382.asc
Description: application/pgp-keys

Re: GSoC 2018

2018-03-16 Thread 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.


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 :

> 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.

 content 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

Re: GSoC 2018

2018-03-16 Thread 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

On Fri, Mar 16, 2018 at 3:27 PM 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 :
>>>
 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.
>>>
>>> content 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

Re: GSoC 2018

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 :
>>>
 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.
>>>
>>> content 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

Re: [RFC]GSoC 2018 Test framework improvement

2018-03-16 Thread Joe Tennies

Django does have a testing framework that's based on the unittest module
from Python standard library. That stated, I've seen people use nose and
other frameworks in the past. (More info at:
https://docs.djangoproject.com/en/2.0/topics/testing/)

I feel there is always a need for better helper utilities to make writing
tests so easy that people have no excuse NOT to write them. That stated,
the GSoC's that have been accepted in the past have been very specific
about what they are proposing and milestones as to what will be done and
when. There is no time in schedule to discover or define the scope.
Obviously, there will always be issues that come up and changes are
inevitable, but Django has a limited number of slots and wants to choose
projects that not only provide good benefits to the project but are likely
to succeed as well,

Hopefully this is helpful. You may be on the right track, but you'll have
to not only sell on what you will do but that you're the correct person to
do it and you understand the scope.

On Fri, Mar 16, 2018 at 12:56 PM Su Billy  wrote:

> Hello developers,
>
> My name is BING-LI SU from Taiwan, you can simply call me Billy.
>
> *Background*
> I'm an undergraduate student at National Chiao Tung University, major in
> Computer Science.
> I have been contributed to several open source projects for one year, such
> as CDNJS, pyqtgraph, and I host my own project using Tornado Web to build a
> simple digital signage system which contain a little bit unit test, CI, and
> docker image for fast deployment.
> I have know Django when I chose the framework of the digital signage, but
> I haven't used it util these few days, knowing that Django is a more
> sophisticated and handy framework compared to Tornado. In my opinion, the
> best way to be familiar with a project is to understand the test of the
> project (if there has one), therefore I choose test framework as my
> proposal idea.
>
> *Ideas*
> I'd like to add some new feature to the test framework, it is mainly about
> provide some groups of common used tests for user to choose, and maybe
> provide hook function to add their own test before, after, during each
> group of tests.
>
> *Plan*
> Here is my draft plan to achieve above ideas
> 1. To make me better understand the whole test framework, I will briefly
> trace the test framework in May
> 2. Find out and discuss with mentor about how to group up the tests and
> what this feature should look like.
> 3. Implementation and discuss with mentor once or twice a week.
>
> Thanks for any suggestion or comments, i.e: I should start to trace which
> part of test framework? The idea has some problem...? etc.
>
> sincerely
> Billy Su
>
> --
> 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/ad1d498b-c14b-40a5-9ca0-fee65814ed59%40googlegroups.com
> 
> .
> 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 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/CACiOJ6upNb%2BGpdxBMt2n31k6WciAfNWog%2B1_O9MtmN-uSukeZA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [RFC]GSoC 2018 Test framework improvement

2018-03-16 Thread Josh Smeaton

Hi Billy,

This plan sounds more like a plan for a plan. If you're serious about 
wanting to participate in GSoC, then you need to have **specific** ideas 
and goals. By this, I mean your proposal should be able to be picked up by 
anyone and implemented. You're missing any actual feature proposals. To be 
successfully chosen, what you'd need to demonstrate is that you have a good 
understanding of how things already work, and the problems that people 
face. You'd also accompany your proposal with code/test examples of **how 
things are now** and **how things will be** once you've completed the 
project.

Regards,

On Saturday, 17 March 2018 04:56:53 UTC+11, Su Billy wrote:
>
> Hello developers, 
>
> My name is BING-LI SU from Taiwan, you can simply call me Billy.
>
> *Background*
> I'm an undergraduate student at National Chiao Tung University, major in 
> Computer Science.
> I have been contributed to several open source projects for one year, such 
> as CDNJS, pyqtgraph, and I host my own project using Tornado Web to build a 
> simple digital signage system which contain a little bit unit test, CI, and 
> docker image for fast deployment.
> I have know Django when I chose the framework of the digital signage, but 
> I haven't used it util these few days, knowing that Django is a more 
> sophisticated and handy framework compared to Tornado. In my opinion, the 
> best way to be familiar with a project is to understand the test of the 
> project (if there has one), therefore I choose test framework as my 
> proposal idea.
>
> *Ideas*
> I'd like to add some new feature to the test framework, it is mainly about 
> provide some groups of common used tests for user to choose, and maybe 
> provide hook function to add their own test before, after, during each 
> group of tests.
>
> *Plan*
> Here is my draft plan to achieve above ideas
> 1. To make me better understand the whole test framework, I will briefly 
> trace the test framework in May
> 2. Find out and discuss with mentor about how to group up the tests and 
> what this feature should look like.
> 3. Implementation and discuss with mentor once or twice a week.
>
> Thanks for any suggestion or comments, i.e: I should start to trace which 
> part of test framework? The idea has some problem...? etc.
>
> sincerely
> Billy Su
>

-- 
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/381ad22a-86f7-4982-bf63-a680274aaa86%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: GSoC 2018

2018-03-16 Thread 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,

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 :
>>
>>> 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.
>>
>> content 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 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/c4a290e2-ca6a-476e-8339-57c967db6a53%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[RFC]GSoC 2018 Test framework improvement

2018-03-16 Thread Su Billy

Hello developers,

My name is BING-LI SU from Taiwan, you can simply call me Billy.

*Background*
I'm an undergraduate student at National Chiao Tung University, major in
Computer Science.
I have been contributed to several open source projects for one year, such
as CDNJS, pyqtgraph, and I host my own project using Tornado Web to build a
simple digital signage system which contain a little bit unit test, CI, and
docker image for fast deployment.
I have know Django when I chose the framework of the digital signage, but I
haven't used it util these few days, knowing that Django is a more
sophisticated and handy framework compared to Tornado. In my opinion, the
best way to be familiar with a project is to understand the test of the
project (if there has one), therefore I choose test framework as my
proposal idea.

*Ideas*
I'd like to add some new feature to the test framework, it is mainly about
provide some groups of common used tests for user to choose, and maybe
provide hook function to add their own test before, after, during each
group of tests.

*Plan*
Here is my draft plan to achieve above ideas
1. To make me better understand the whole test framework, I will briefly
trace the test framework in May
2. Find out and discuss with mentor about how to group up the tests and
what this feature should look like.
3. Implementation and discuss with mentor once or twice a week.

Thanks for any suggestion or comments, i.e: I should start to trace which
part of test framework? The idea has some problem...? etc.

sincerely
Billy Su

--
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/ad1d498b-c14b-40a5-9ca0-fee65814ed59%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: GSoC 2018

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  >:
>
>> 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.
>
> content 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 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/cfc4f1b6-25ed-42f6-81ca-b3cbf9133dce%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: GSoc 2018

2018-03-16 Thread jimwangcx

I'm sorry to say that I haven't seen it before. But I notice that it only 
deals with the models and I want to deal with the views, URLs and settings 
too. Has someone done that before? 

On Thursday, March 15, 2018 at 10:29:01 AM UTC+8, uri...@gmail.com wrote:
>
> Have you seen 
> https://github.com/LegoStormtroopr/django-spaghetti-and-meatballs  ?
>
> On Wednesday, March 14, 2018 at 9:11:59 PM UTC-4, jimw...@gmail.com wrote:
>>
>> Hello,
>>
>> My name is Chenxu Wang from China and I'd like to participate in the GSoC 
>> with coding for Django.
>>
>> *My idea:*
>> I want to develop a tool which can make statistics of every single Django 
>> project. This tool will describe the structure of the selected project, 
>> list its apps, URLs, models and things like that. I also want to draw a GUI 
>> for it if possible.
>>
>> *Background and Significance:*
>> About one year ago, I joined a club in my university which was developing 
>> a wonderful campus App. My mentor was going to graduate and i had to take 
>> over the project. I was a newcomer of Django at that time and it was 
>> difficult for me to master the project in such a short time.
>> It took me for a long time to understand the system structure and began 
>> to contribute to the project(Of course, the doc is not very detailed). 
>> Therefore, I guess it will be more friendly for a newcomer to a big project 
>> if there is a tool to show them the URL path, models, 
>> even views in a tree diagram.
>>
>> *About me and the Feasibility:*
>> I am a computer science student and i have over three years experience of 
>> programming(mainly in C/C++) and over one years experience of Python and 
>> Django programming. I've developed few projects of Django and even tried to 
>> translate its document( but its too much so I failed to translate it all) 
>> and I am kind of familiar with compilers.
>>
>> I think I can get main URLs from urls.py and track them to find out the 
>> tree of URLs(If there are other URL files in apps). I can get models in all 
>> models.py in apps(I can also track them if necessary). It might be kind of 
>> difficult to find the views,  but I guess track the URLs may help.
>> If possible, I want to show them in GUI in order to be more friendly to 
>> people who take over a new project especially if they are new to Django and 
>> I plan to show the settings.py in GUI too so that users can easily find and 
>> change their settings.
>>
>> Any advice?Sincere appreciation for any suggestion.
>>
>

-- 
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/c4f29f2b-a624-4470-8140-85417d6dd01f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: GSoC 2018

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  >:
>
>> 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.
>
> content 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.
>

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

-- 
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/af193f5c-c6d3-4245-b7d2-45e676d9ec03%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: GSoC 2018

Hello,

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  >:
>
>> 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.
>
> content 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.
>

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

-- 
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/d9e3f107-8469-4fa8-ac99-49d28e04d863%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: GSoC 2018

2018-03-15 Thread Aymeric Augustin

Hello,

2018-03-15 14:24 GMT+01:00 Manasvi Saxena :

> 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.

content 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.

-- 
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/CANE-7mUBWAeZ%2BkzcWm-Q52jbivOmiSqz_j%2BaUtDjbnshxkzhog%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: GSoC 2018

Hello Sir,

On Thursday, March 15, 2018 at 3:52:36 AM UTC+5:30, Aymeric Augustin wrote:
>
> Hello Manasvi,
>
> On 14 Mar 2018, at 09:09, Manasvi Saxena  
> 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.
>
>
>
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 

-- 
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/9ca8311b-3b70-44ae-a681-80873d0a86ca%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: GSoC 2018