For the wont fix ticket I'm considering that to introduce django extra view 
like features in django will help fix many problem related to FormSet and 
ModelFormSet and then use them in improving django admin and possibly 
django-admin2 like features in django.

On Monday, March 23, 2015 at 4:43:30 AM UTC+6, Tim Graham wrote:
>
> Please explain what you plan to implement in the other apps rather than 
> what's already been implemented in contrib.auth. You'll also need to 
> explain your reasoning for addressing a ticket that's been marked as "won't 
> fix."
>
> On Sunday, March 22, 2015 at 4:36:26 PM UTC-4, Asif Saifuddin wrote:
>>
>> I do belive to implement auth patch cleanly wont take more then a few 
>> days. But I have plans with django admin app and others which will need 
>> more tasks and also thinking about working with formset . The part I posted 
>> here is just a very little/start point of my proposal :)
>>
>> And I am working on a draft gist for full proposal. This part was posted 
>> to have an Idea if I'm going to right direction. I found admin-docs up to 
>> date with class based views and using that as a good reference to 
>> understand the implementation and also getting ideas about the problems 
>> people faced earlier and theie thoughts about the possible solutions :)
>>
>> I'm I in right direction? at least in some context? knowing that will 
>> help me a lot
>>
>> ./auvipy
>>
>>
>>
>> On Mon, Mar 23, 2015 at 1:14 AM, Tim Graham <timog...@gmail.com> wrote:
>>
>>> I see there's already a patch attached to the ticket that implements 
>>> your proposal. While it likely needs to be updated to apply cleanly, I 
>>> don't imagine that will take more than a few days?
>>>
>>>
>>> On Sunday, March 22, 2015 at 2:19:37 PM UTC-4, Asif Saifuddin wrote:
>>>>
>>>> Hi All,
>>>>
>>>> during my analyzing and making proposal for django best practices 
>>>> updates (class based view etc)  I found this ticket related 
>>>> https://code.djangoproject.com/ticket/16256 [though closed by a core 
>>>> dev I think this should be addressed to resolve some issues in admin as 
>>>> per 
>>>>  https://code.djangoproject.com/ticket/17209]
>>>>
>>>>
>>>> Here goes some of my initial proposal plan I will be updating regularly 
>>>> to complete the proposal in a gist and share that again. before that 
>>>> please 
>>>> give some feedback :)
>>>>
>>>> Background
>>>>
>>>> Over the years, as Django has evolved, the idea of what constitutes 
>>>> "best practice" has also evolved. However, some parts of Django haven't 
>>>> kept up with those best practices. For example, contrib apps do not use 
>>>> class based views.
>>>>
>>>> In short, Django has been bad at eating it's own dogfood. The contents 
>>>> of contrib should be audited and updated to make sure it meets current 
>>>> best 
>>>> practices.
>>>>
>>>> For updating best practices first think to consider is to convert the 
>>>> functional views of django contrib apps to class based views where 
>>>> possible 
>>>> and necessary. To do so first app to consider is django contrib auth.
>>>>
>>>> contrib-auth views.py now have function based views and they are
>>>>
>>>> login logout logout_then_login redirect_to_login password_reset 
>>>> password_reset_done password_reset_confirm password_reset_complete 
>>>> password_change password_change_done
>>>>
>>>> and in urls.py url mapping for function based views as follows
>>>>
>>>> urlpatterns = [ url(r'^login/$', views.login, name='login'), 
>>>> url(r'^logout/$', views.logout, name='logout'), url(r'^password_change/$', 
>>>> views.password_change, name='password_change'), 
>>>> url(r'^password_change/done/$', views.password_change_done, 
>>>> name='password_change_done'), url(r'^password_reset/$', 
>>>> views.password_reset, name='password_reset'), 
>>>> url(r'^password_reset/done/$', views.password_reset_done, 
>>>> name='password_reset_done'), url(r'^reset/(?P[0-9A-Za-z_-]+
>>>> )/(?P[0-9A-Za-z]{1,13}-[0-9A-Za-z]{1,20})/$', 
>>>> views.password_reset_confirm, name='password_reset_confirm'), 
>>>> url(r'^reset/done/$', views.password_reset_complete, 
>>>> name='password_reset_complete'), ]
>>>>
>>>> and tests for this in tests/auth_tests/test_views.py
>>>>
>>>> the views have to be converted into CBV and also the urls. and this 
>>>> should be done in a backward compatible manner.
>>>>
>>>> as an example password_change_done view is now implemented as below.
>>>>
>>>> @login_required def password_change_done(request, 
>>>> template_name='registration/password_change_done.html', 
>>>> current_app=None, extra_context=None): context = { 'title': _('Password 
>>>> change successful'), } if extra_context is not None: 
>>>> context.update(extra_context)
>>>>
>>>> if current_app is not None:
>>>>     request.current_app = current_app
>>>>
>>>> return TemplateResponse(request, template_name, context)
>>>>
>>>> this could be changed to cbv like below
>>>>
>>>> class PasswordChangeDoneView(TemplateView): 
>>>> template_name='registration/password_change_done.html' 
>>>> current_app=None extra_context=None
>>>>
>>>> @method_decorator(login_required)
>>>> def dispatch(self, request, *args, **kwargs):
>>>>     return super(Password_Change_Done, self).dispatch(request, *args, 
>>>> **kwargs)
>>>>
>>>> def get_context_data(self, **kwargs):
>>>>     context = super(Password_Change_Done, self).get_context_data(**kwargs)
>>>>     context.update({
>>>>              'title': _('Password change successful'),
>>>>              'current_app': self.current_app,
>>>>     })
>>>>     if self.extra_context is not None:
>>>>         context.update(self.extra_context)
>>>>     return context
>>>>
>>>>
>>>> <https://gist.github.com/auvipy/1da0d96f826bd8da4d47#for-backward-compatibility-the-following-way-can-be-followed>for
>>>>  
>>>> backward compatibility the following way can be followed
>>>>
>>>> def password_change_done(request, *args, **kwargs):
>>>>
>>>>       return PasswordChangeDoneView.as_view(**kwargs)(request, *args, 
>>>> **kwargs)
>>>>
>>>  -- 
>>> 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/WF3My-cZNtY/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/c26f31b0-a4af-4a0d-818d-d4f62ef430ac%40googlegroups.com
>>>  
>>> <https://groups.google.com/d/msgid/django-developers/c26f31b0-a4af-4a0d-818d-d4f62ef430ac%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/6fb6212c-a5db-49d7-8efb-683260877af6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to