Re: RedirectView supporting View-Names
Well, ... I know about reverse_lazy
Sorry for not explaining myself good enough:
reverse_lazy can't do:
url( 'bar/foo/(?P[0-9]*)/', *RedirectView*( url=
*reverse_lazy*('foo_stuff')
),
url( 'foo/(?P[0-9]*)/', some_view_func, name = 'foo_stuff' ),
What a RedirectView supporting URL Names (...) could do:
url( 'bar/foo/(?P[0-9]*)/', *RedirectView*( view_name = 'foo_stuff' ),
url( 'foo/(?P[0-9]*)/', some_view_func, name = 'foo_stuff' ),
I'm handling it as a view-name instead of url name, because in my opinion,
a view in -some specific URL-Context- always has a name that can be chosen,
that even if the URL changes in some detail, it would remain the same:
* posts_by_specific_user * or something like that - if it is located in
'/user//posts/' or
'/department//users//posts/'
An URL... well i wouldn't know why to name a URL - a URL is more or less
something like a name / identifier. Just not this intuitive understandable
or in some cases longtime-persistent. Changing a URL would somehow result
in changing the url-name (because otherwise the name would result form
something else than the URL itself) - and thats just a real pity because
something that does the same would be named differently.
Benefit for using it like this:
- Caused by whatever decisions (this shouldn't happen but most likely
always will..) the url of a specific VIEW changes, one can now support the
legacy URL because other sites might have linked to it and 301 (Moved
Permanently) Redirect it to the new URL, specified by the view name.
- Or in some other case for APIs when representing a Resource: when
having the same resource at two different URLs, one can easily 302 redirect
it to one *base* view (once again, the URL might change. especially when
using versioned URLs)
What would needed to be changed in *RedirectView*:
By having something like this in the *get()* method:
*get_redirect_url(request, args=args kwargs=kwargs)*
and in *get_redirect_url:*
*elif self.view_name:*
*url = reverse( self.view_name, args=args, kwargs=kwargs)*
one could dynamically pass those url args and kwargs, of a dynamic url
regarding to https://code.djangoproject.com/ticket/15273:
i don't understand why such a basic concept like named urls/views are
somehow integrated in django (template tag: url) but in this case just
accessible
through nasty workarounds (reverse_lazy). In my opinion a workaround like
this often just points out, that something is probably unfinished. And in
my opinion this is definitely the case when looking at RedirectView and
those .. view-names .. because some important functionality is not
available.
So - i would really appreciate having this functionality (as far as i don't
miss anything you guys thought about, that speaks against it).
best regards
ludwig
--
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/-/39XYBkpXwncJ.
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: GitHub migration
Hello, Django's development moved to GitHub 7 months ago, and it's a success! No guidelines for pull requests were published, but usage patterns have emerged. Here's what I've observed. 550 pull requests have been opened: - 20% of them are still open. This figure is a slightly above reality because pull requests sometimes stay open even after the corresponding problem is fixed. - 80% are closed. There's no easy way to tell if they were merged or rejected. Most open pull requests reference a Trac ticket. Trac is used for almost all discussions. I believe there are two reasons for this: - every action on Trac is notified to more than 900 subscribers to the django-updates mailing list; - Trac is customized to match the community's and the core team's workflows. Pull requests are used as a replacement for patches uploaded to Trac, and as an code review UI. The killer features here are line-by-line commenting, and to some extent incremental review. Pull requests that don't reference a Trac ticket tend to get lost into the noise (507, 500, 497, 478, 451, 432, 421, 402, 393, 317, 272, 211, etc.). They suffer from the lack of a triage process to ensure every PR gets looked at, and categorization to help to locate PRs of interest. (By the way, these are the main reasons why we didn't switch issue management to GitHub.) In the end, trivial fixes such as typos generally get merged, more complex ones don't without a discussion in a ticket. Have you noticed other interesting patterns? What improvements to the development processes would you suggest? -- Aymeric. -- You received this message because you are subscribed to the Google Groups "Django developers" group. 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: GitHub migration
One major improvement I've seen is that when there's a small issue in a commit (such a typo) a contributor often leaves an inline comment and it can get fixed directly. This is a great workflow for simple issues. Alex On Sun, Nov 25, 2012 at 3:46 PM, Aymeric Augustin < aymeric.augus...@polytechnique.org> wrote: > Hello, > > Django's development moved to GitHub 7 months ago, and it's a success! > > No guidelines for pull requests were published, but usage patterns have > emerged. Here's what I've observed. > > 550 pull requests have been opened: > - 20% of them are still open. This figure is a slightly above > reality because pull requests sometimes stay open even after the > corresponding problem is fixed. > - 80% are closed. There's no easy way to tell if they were merged > or rejected. > > Most open pull requests reference a Trac ticket. > > Trac is used for almost all discussions. I believe there are two reasons > for this: > - every action on Trac is notified to more than 900 subscribers to > the django-updates mailing list; > - Trac is customized to match the community's and the core team's > workflows. > > Pull requests are used as a replacement for patches uploaded to Trac, and > as an code review UI. The killer features here are line-by-line commenting, > and to some extent incremental review. > > Pull requests that don't reference a Trac ticket tend to get lost into the > noise (507, 500, 497, 478, 451, 432, 421, 402, 393, 317, 272, 211, etc.). > They suffer from the lack of a triage process to ensure every PR gets > looked at, and categorization to help to locate PRs of interest. (By the > way, these are the main reasons why we didn't switch issue management to > GitHub.) In the end, trivial fixes such as typos generally get merged, more > complex ones don't without a discussion in a ticket. > > Have you noticed other interesting patterns? What improvements to the > development processes would you suggest? > > -- > Aymeric. > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > 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. > > -- "I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire) "The people's good is the highest law." -- Cicero -- You received this message because you are subscribed to the Google Groups "Django developers" group. 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: Improved ajax support idea
On Saturday, November 24, 2012 9:11:17 AM UTC-8, is_null wrote: > > Hello everybody, > > > I can understand most of the points made here, expect just one, please > bare with me. Several hackers on this list stated that it has "obviously > not its place in Django". I don't understand why generic non ajax views > would have a their place in django, and ootb ajax support would not. But > I'm really curious. > > It would be great if someone could elaborate on that, because from what I > understand: > > - django has generic views, you are free to use them, you can use your > own, or you can use those that are provided by external apps, > - if django had generic views with ajax support, you would be free to use > the ajax support, or use your own, or use those that are provided by > external apps. > One distinction is that generic views don't provide anything in the way of default templates. They help with the data pattern on the Django side, and you choose how it goes to the browser in a template. In an ajax response, the data is returned directly to the JS code in the browser. Because different JS frameworks may expect data in different arrangements - you end up coupling the generic ajax code to some expectation set by the browser JS code. More relevant to such an effort would be whether there was anything in the CBVs that stood in the way fundamentally. The current thought is that there isn't, but one couldn't be sure until there was an attempt. -Preston -- 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/-/VGMl8ei_U-gJ. 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.
