Hi,
Il 30/05/2015 18:52, Emil Stenström ha scritto:
> Hi,
>
> This is the first feature proposal as part of my general drive for getting
> Django to work better for javascript heavy sites.
This is a bold premise :)
[snip]
> ... 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 %}
But your proposal keeps html and js separated. I think you are solving a problem
for the one that just want to use a component but you are not solving the
problem for the one that is writing components. At least not in the react.js
way, especially from such a bold premise :)
class ReactCalendar(component.Component):
def context(self, date):
return {"date": date}
class Media:
template = None
css = {'all': ('app/components/calendar/calendar.css',)}
js = ('app/components/calendar/calendar.js',)
--
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/a05f2dc1-3515-4b23-96f5-479d2722b82c%40googlegroups.com.
Specialized class based views and sub-views, that facilitate:
I actually think this is a great idea. In my mind it parallels Drupal's "block" idea. (This is actually what I keep hoping DjangoCMS is.)
That stated, it is more of a construct. I think a great idea is to make an extension module.
I don't know how long you've been in this community, but Django is now quite stable and people rely on their APIs. Your bold ideas really need to be tested by fire before they go into the Django proper. There's been lots of discussion about a year ago to remove/reduce a lot of the contrib.
Being in Django is where things go to die. Once an API is released to the public, it takes a fair amount of work to remove/change it. You don't even want to know how long it took to get schema migrations into Django. South had been the defacto way for quite a few years. That stated, Andrew had to make some changes to South due to design decisions that were made earlier in South. Before that, there was other projects like django-evolution (which just got an update 2 months ago).
So, I followed the Drupal group for a while. The thing the Django community really needs is a couple good opinionated groups of how to put together a good Django site. Drupal has Lullabot (who have quite a few core devs on staff). Django is not going to be the people telling people how to use Django. You seem like a great person to start this for Django. Note that you'll have to have a thick skin and create some pretty great sites in your own right to prove out your ideas to others. You'll also need to get your ideas out via things like blog posts, tutorials, and podcasts.I would like the Caktus, DjangoCMS, FeinCMS, etc people to do the same. This would help people to see some different ideas on how to use and extend Django.
So a former co-worker with some help/guidance from me developed a component system on top of Django that sounds sorta like what you are all talking about. It's very complicated and I'm still not sure whether it was ultimately a good idea to use or not, but it does make some things very simple (and we have no plans to move away from it at this point after ~2 years of use). I'll post some snippets from our internal docs on it now and if people are interested, I can explain more and possibly open source it <snip>
--
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/FmBM8VdxJ08/unsubscribe.
To unsubscribe from this group and all its topics, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/5e562720-9484-4e4f-9507-129d55a4cfce%40googlegroups.com.
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?
--
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/5569EAC5.1020804%40kth.se.
This sounds a bit like combining django-sniplates with django-amn, and going a bit further...Fragments of templates, list of JS/CSS dependencies, and a way to collect it all together and ensure your page has everything you need...Sounds interesting to me... I'd be happy to collaborate on it with you... once we see where it goes, and compare it with the existing implementation, people will have more food for thought :)