Speaking only for myself and the component framework we built here, I don't think I would expect it to ever be rolled into Django itself.
However, the framework we made does work without any modifications to Django and works just fine alongside existing function and classed based views. This means no changes to existing codebases would be necessary (unless you wanted to buy into the concept completely and switch existing stuff over rather than just use it for new features, in which case it would require a lot of work to split up your views/templates into components (though if you already split up the code in your views in a logical way and use template includes rather than really long template files and stuff like that, it may not be that bad)). On Tuesday, June 9, 2015 at 4:21:27 AM UTC-7, Yoong Kang Lim wrote: > > This seems like a huge change. If you were to include this feature in > Django, would it be straightforward for users to migrate from previous > versions? > > > > On Sunday, May 31, 2015 at 2:52:37 AM UTC+10, Emil Stenström wrote: >> >> Hi, >> >> This is the first feature proposal as part of my general drive for >> getting Django to work better for javascript heavy sites. >> >> Template Components >> ------------------- >> >> React.js popularized the notion that in front-end development, code >> organization should be based on interface components, not split up into >> HTML, Javascript and CSS. Here's the original presentation and the >> rationale behind organizing around components: >> https://www.youtube.com/watch?v=x7cQ3mrcKaY&t=2m7s >> >> In Django, adding a Javascript calendar to you site requires changes to >> four different locations in your project: >> >> - /app/templatetags/calendar_tags.py <- A custom inclusion template tag >> - /app/templates/calendar.html <- Some HTML in the template dir >> - /static/css/style.css <- Add some CSS to style.css >> - /static/js/script.js <- Add some JS to scipt.js >> >> There is no connection within Django between HTML and the CSS + JS. >> Django does not help you, or even suggest a structure for you, like it >> does with all Python code. >> >> On the other hand, we have Form Assets: >> https://docs.djangoproject.com/en/1.8/topics/forms/media/ >> >> Example: >> >> from django import forms >> class CalendarWidget(forms.TextInput): >> class Media: >> css = {'all': ('calendar.css',)} >> js = ('calendar.js',) >> >> >>> w = CalendarWidget() >> >>> print(w.media) >> <link href="calendar.css" media="all" rel="stylesheet" /> >> <script src="script.js"></script> >> >> ... which define a kind of component, but one that is tied to a form >> field. My suggestion is a new package: django.template.component, that >> builds on the Media class from Form Assets, and allows you to define >> your components like this: >> >> from django.template import component >> class Calendar(component.Component): >> def context(self, date): >> return {"date": date} >> class Media: >> template = "app/components/calendar/calendar.html" >> css = {'all': ('app/components/calendar/calendar.css',)} >> js = ('app/components/calendar/calendar.js',) >> >> component.register(name="calendar", component=Calendar) >> >> ... and later in your template: >> >> {% load components %} >> {% block extra_media %}{% component_dependencies %}{% endblock %} >> {% block main %} >> {% component "calendar" date=custom_date %} >> {% endblock %} >> >> --- >> >> Advantages: >> - You to keep the python, html, css, and javascript in one location, and >> explicitly define the dependencies between them. >> - All <link> and <script> tags would be handled by the >> component_dependencies template tag (the Media class behind the scences). >> - No need for inclusion template tags >> - Better customization of the admin, where you could simply register >> your own components to replace existing ones >> - Reuse of components from the admin outside of it. Just use the name >> from the admin and send the correct parameters. If you want to change >> the CSS, just import the class and override the properties you want to >> change. >> >> --- >> >> I think this would be a great addition to Django, and some of the work >> is already done in the Media class that form assets is using. This would >> of course be optional, but I think lots of people would see the benefits >> of using this structure instead of their existing one. >> >> Would anyone we willing to work with me on this? Do you think it makes >> sense to put this in Django? I don't see any need for this code to >> change often, and the API is fairly similar to an existing one. >> >> Thoughts? Ideas? >> >> Regards, >> >> Emil Stenström >> Twitter: @EmilStenstrom >> > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/84b2d8d3-9c0f-47d6-83ea-41622ba6f8ec%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
