Re: Proposal: Django URL Admin (django-urls)

[Sam Solomon]

Yeah, I agree, as it is, I can't see any reason why I would use it, but I 
could see it being useful with some modifications such as:

1) Being able to create redirects (which seems to already be on the 
todo-list)
2) Being able to specify extra kwargs to pass to a view so that it would be 
possible to change the functionality of a view without adding a new model 
to store the different options (or have to change the urlconfig and push 
new code every time).

Until those things are implemented (which allow for things that could 
probably be implemented in more straightforward/non-dev-user friendly 
ways), it seems like a bad idea to store infrastructure in the database (I 
can only see it causing problems when you have developers working from a 
different urlconf than the production server is using).

On Friday, December 14, 2012 11:31:34 PM UTC-6, Amirouche B. wrote:
>
>
>
> On Friday, December 7, 2012 9:07:32 PM UTC+1, Zach Borboa wrote:
>>
>> Does something like this exist already? If not, it should.
>
>
> How this can be useful ? You still need to write the view in Python then 
> why not write the urls in Python too, like it's currently the way to go.
>
> If something in this spirit might be useful is something where the view 
> could be generated which would be something like databrowser or admin.
>
> Could you elaborate ?
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/GSfX8xoF550J.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Perception of attitude in tickets

[Sam Solomon]

As an outsider with very little data (so you can ignore this if you 
strongly disagree), I sort of agree with the notion that "WONTFIX" could be 
sending a different signal that it is being used for.

WONTFIX to me would mean, "We acknowledge that this is an annoyance for 
some people, but we're not going to fix it no matter what you or anyone 
else says".

Maybe a compromise is using a variation on the same terminology but 
softening it to "PROBABLYWONTFIX" when it's something that you don't think 
is a serious problem but could theoretically be swayed with a good proposal 
and other people stepping up to submit patches and fight for the feature.

"WONTFIX" would still be appropriate for firm "no, never, this isn't just a 
poorly stated proposal, it's either too difficult or is actually counter to 
our overall goals even though it is a valid 'issue'".

Some references of WONTFIX in the wild/in other contexts/discussions:

http://contribute.jquery.org/wont-fix/

http://wiki.eclipse.org/Development_Resources/HOWTO/Bugzilla_Use "WONTFIX 
is used for things that are valid requests, but that the team can't do"

http://programmers.stackexchange.com/questions/58950/defect-statuses-wont-fix-vs-cancelled




On Tuesday, May 14, 2013 3:56:26 AM UTC-7, Daniele Procida wrote:
>
> On Mon, May 13, 2013, Łukasz Rekucki > 
> wrote: 
>
> >> The status WONTFIX sounds awfully rude to me. It's like saying "That's 
> a 
> >> pony and you can't have one, ever." It implies a terminal finality 
> which 
> >> actually isn't meant in some cases, because it is possible (as we've 
> seen) 
> >> and even sometimes recommended by a core developer, for a sufficiently 
> >> determined person to push for change on the mailing list and make it 
> happen. 
> >> 
> > 
> >You can blame this on my lack of social skills, but I really don't see 
> how 
> >it's rude. 
>
> Maybe it's not rude, but it is off-putting. Perhaps there are some 
> proposals that really do deserve to have the door closed firmly in their 
> faces - that's what "WONTFIX" suggests to me, even if it's not what's 
> intended. 
>
> Daniele 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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 http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Feature: Template Components

[Sam Solomon]

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:
Background: What?

Specialized class based views and sub-views, that facilitate:

   - Split page template into components, each of which can be POSTed to 
   and/or updated via ajax.
   - View code and templates for full page view and ajax update is the same 
   code. (DRY, though more data over the wire than some of the newer 
   javascript frameworks)
   - Updating multiple parts of the page with a single request (example: 
   POSTing to one component can cause dependent components to also be updated 
   in the same request)
   - Built-in compatibility to handle no-js in most situations
   - Deferred loading of components, for performance

Background:
 
Why?
   
   - Complex site with lots of logged in user interactions where content 
   should be easy to change dynamically
   - Slow connections overseas (minimize round trips and limit full page 
   loads without sacrificing dev time too much)
   - Some may not even have JS? (Though we don't really cater to them that 
   much anymore, this was a consideration originally and still mostly 
   supported by default outside of where we use d3 and things like that for 
   rendering certain things.)


On Monday, June 1, 2015 at 12:55:08 AM UTC-7, Unai Zalakain wrote:
>
> Finally someone expressed my own feelings about it perfectly :D 
>
> On Sun, May 31, 2015 at 08:32:18PM -0500, Joe Tennies wrote: 
> >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. 
> > 
> >On Sun, May 31, 2015 at 5:26 AM, Emil Stenström  > wrote: 
> > 
> >> On Sunday, 31 May 2015 11:36:51 UTC+2, riccardo.magliocchetti wrote: 
> >>> 
> >>> Il 31/05/2015 11:00, Emil Stenström ha scritto: 
> >>> > On Sunday, 31 May 2015 10:27:24 UTC+2, riccardo.magliocchetti wrote: 
> >>> > Il 30/05/2015 18:52, Emil Stenström ha scritto: 
> >>> > 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 :) 
> >>> > 
> >>> > I agree that I don't quite do it the same way as React. But that's 
> not 
> >>> the point 
> >>> > here either, to somehow bundle Reacts ideas inside Django. My point 
> is 
> >>> that 
> >>> > keeping the four parts that make a component closely together in the 
> >>> project 
> >>> > source, would make for a better structure. They only idea that comes 
> >>> from React 
>

Re: Feature: Template Components

[Sam Solomon]

_p }}



*templates/framework_example/listing_component.html:*

{% for attendance_record in attendance_list %}

{{ attendance_record.name }} - {{
attendance_record.arrival_time }}

{% endfor %}


*templates/framework_example/attendance_page.html*
{% extends "base.html" %}

{% block content %}
{% comment %}
The surrounding div id follows a specific formula so it can be
automatically updated on ajax requests: `cmp__id`
{% endcomment %}

{% comment %}
Similarly, you can grab the rendered html from the component by
asking for `component_name` from the dictionary of rendered html
        `components`:
{% endcomment %}
{{ components.framework_example_listing }}



{{ components.framework_example_attendance_entry }}

{% endblock content %}


On Mon, Jun 1, 2015 at 11:54 PM, Emil Stenström  wrote:

> On Monday, 1 June 2015 19:12:36 UTC+2, Sam Solomon wrote:
>>
>> 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
>> 
>>
>
> Interesting! I would definitely want to see some code examples here. Could
> you show me how me more about how it works?
>
> --
> 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-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@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
> <https://groups.google.com/d/msgid/django-developers/5e562720-9484-4e4f-9507-129d55a4cfce%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
> 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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CADGELX_0G%2BeyQLqzxa-enpVG_m10NeOcjyjiY_7b0c%2BbwHhqMQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Feature: Template Components

[Sam Solomon]

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