GSOC 2015 project ideas suggestion

[Asif Saifuddin]

Hi,

Although probably It's quite very early to ask about GSOC 2015 in January,  I would like to start analyzing to prepare myself for choosing a correct project and submitting a good proposal for that to get selected. I haven't found any GSOC 2015 project ideas pages yet. But got some older idea pages  of year 2013 and 2014. Should I look forward to the ideas that were unimplemented or wait for gsoc 2015 wiki ideas page?

./auvipy

[Marc Tamlyn]

Anything not done from previous years is likely to be suitable yes.

It would also be very beneficial to familiarise yourself with the contributing guidelines for Django[1] and take on some small fixes, perhaps in related areas to your interests for GSOC.

Marc

[1] https://docs.djangoproject.com/en/1.7/internals/contributing/

--
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/92f8aa3d-69da-4be2-af5a-b2a0f55d616b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Tim Graham]

I've created a wiki page for this year. It includes some ideas from past years which may or may not still be relevant (I did some light editing). Of course, you are welcome to propose something entirely different related to your interests.

https://code.djangoproject.com/wiki/SummerOfCode2015

[Asif Saifuddin]

Hi,

Thank you both of you for your response with guidelines.

I found a old project 

Reducing coupling in Django components

• Complexity: Hard

and a newer project

Improving URL dispatch 

• "Complexity:" Hard

Interests me.

With the first project I have some concrete ideas on mind to share with technical aspects and my proposed terms to be reviewed by the core team. I will soon share my understanding and proposal about this project.

With The second project I'm still not fully sure about the technical implementation and I need some more analysis to understand.

./auvipy

--
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/cfe3dfff-2099-4715-a04c-f43c3120a6c3%40googlegroups.com.

[Asif Saifuddin]

Hi,

For the Reducing coupling of Django components project I have some broader Aim and objectives in my which I am planning to propose.

The main goal of this project proposal is to lay down the stepping stones for reducing coupling in django internal components. To achieve the goal

1. Analyze and find out which components need to be included in django proper and which need to be shipped in a different package.

2. There are Contrib Apps which are mainly django applications and can be moved and evolved as different packages outside django repo. like dj-admin/django-admin, django-gis/geodjango etc

3. Django ORM, Forms, Test, template this need work for moving as single packages. Probably django-orm/django-db, django-forms etc.

This are the basic objectives of my proposals in very brief.

I would like to propose more detail  one with with technical details and my plans to make this project success after having some feedback from core dev teams.

Looking forward to some feedback if my initial move is okeyish?

./auvipy

[Josh Smeaton]

I don't think there is enough time in GSOC to properly extract so many components into separate packages. I don't even know if this would be a long term goal for Django. Even if it were, there's more to it than just creating a new repository. Maintainers would have to put their hand up to manage the new repo. Testing and CI will have to be setup. Dependencies and release management would have to be looked at.

If this project interests you, I think you should investigate ways to reduce tight coupling whilst keeping the majority of components where they are.

Examples of tight coupling include relying on global settings (settings.py/django.conf), various utils modules that are referenced from all over the code base, and knowledge of internal APIs across components. Some of the work that Aymeric has done with the Templates refactor in 1.8 is a good example of reducing tight coupling in a single component.

- Josh

[Fabio Caritas Barrionuevo da Luz]

Some ideas. (which still require approval of the core developers):

* Improve database backend base API and related features(including introspection feature used by inspectdb), so that it is less complicated to add in the future support the specific features of some backends. eg multiple database schemas (common used in Oracle and PostgreSQL) and/or Oracle synonym tables

* port Django i18n and i10 and related translation features to use Babel: http://babel.pocoo.org/ 

[Asif Saifuddin]

Hi Fabio,

Thank you for your project ideas. I'm going to follow the ideas from https://code.djangoproject.com/wiki/SummerOfCode2015

for your babel porting probably Aymeric Augustin's template refactor project have some plan with babel integration, but I'm willing to work on reduce decoupling/Improve template dispatching for first priority from my side till now.

Regards

./auvipy

--

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/cbb457c7-66cb-4370-99de-c9cfcd2a5622%40googlegroups.com.

[Asif Saifuddin]

Hi Josh,

There are two technical problems that need to be solved in order to make this happen.

• Implement the packaging definitions to allow for multiple packages.
• Clean up dependencies between components. Despite the best of intentions, there are some interesting dependencies between modules, some of which may need to be clarified or separated.

The aim of this project would be to clean up one or more of Django's internal "parts" so that it could be delivered as a standalone package. This may not be something that can be immediately delivered - for example, it may be necessary to move or rename components to enable separate packaging. In this case, the project deliverable would be to document the strategy, and provide whatever initial moves in that direction are possible.

A simpler version of this project would be to enable separate packaging and distribution of Django's contrib apps.

alongside reduce tight coupling how should I approach to following part? 

"A simpler version of this project would be to enable separate packaging and distribution of Django's contrib apps."

I am looking for dev teams suggestions

./auvipy

[Tim Graham]

The description of that project needs to be updated as I don't think it accurately reflects a direction we want to go.  A goal might be the ability to use django.forms without the rest of Django, but there's no need to break django.forms into a separate repository to make this possible. In fact, doing so would probably create a lot of chaos. For example, if a change requires modifying both django/forms/forms.py and django/forms/models.py, then it would require coordinating two patches in two separate repositories and how you can you run CI on that combination of pull request? Similar issues with removing other parts like django.utils.

So if one of your project's goals is to allow using django.forms without the rest of Django, then for your proposal you need to research what the current obstacles are for doing so (dependency on settings, for example), and then explain the solution you will implement to allow this.

I don't think there's strong or desire to remove any of the current contrib apps (some have already been removed recently).

By the way, have you contributed to Django before? Your odds of acceptance are greatly enhanced if you have a track record of producing good patches (and it will also help you write a better proposal, I think).

[Russell Keith-Magee]

On Mon, Feb 2, 2015 at 11:39 PM, Fabio Caritas Barrionuevo da Luz <bna...@gmail.com> wrote:

Some ideas. (which still require approval of the core developers):

* Improve database backend base API and related features(including introspection feature used by inspectdb), so that it is less complicated to add in the future support the specific features of some backends. eg multiple database schemas (common used in Oracle and PostgreSQL) and/or Oracle synonym tables

A project like this is more likely to get traction if you're targeting a specific feature. Instead of targeting a generic cleanup for a theoretical feature, you're more likely to find acceptance for implementing a *specific* feature that is database specific - like, for example, multiple schema support. 

 

* port Django i18n and i10 and related translation features to use Babel: http://babel.pocoo.org/ 

As a concept, I suspect this one would definitely be of interest. However, it would also be a very *big* project, and one where you can't really deliver small parts, so it's extremely ambitious for the GSoC timeframe. I'm not ruling it out, but it would require a very special student, and a very willing mentor.

Yours

Russ Magee %-)

[Russell Keith-Magee]

On Mon, Feb 2, 2015 at 11:58 PM, Asif Saifuddin <auv...@gmail.com> wrote:

Hi Fabio,

Thank you for your project ideas. I'm going to follow the ideas from https://code.djangoproject.com/wiki/SummerOfCode2015

 

While this is definitely a safe option, don't rule out a 'not-on-the-official-list' project. The GSoC project list is a good list of pre-vetted projects, but it's not exhaustive. A well posed project, especially one relating to an old ticket, would certainly be a good candidate for the GSoC -  For example, multiple schema support is #6148

https://code.djangoproject.com/ticket/6148

Yours,

Russ Magee %-)

[Asif Saifuddin]

Thank you both for the feedback. I will continue my analysis to understand django well and also try to contribute some patch on django if I can.

For django URL dispatcher improvement I am also looking for some suggestions. Should I also look to some tool like werkzeug, webob along side django http, url dispatch, middleware and related stuffs. Some guide will help me to dig more and go to proper direction.

./auvipy

--

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/CAJxq849-9bAeo7dfoAk1XdGBFnBkykGVekRbJbs19_5UH3C1Kg%40mail.gmail.com.

[Russell Keith-Magee]

On Wed, Feb 4, 2015 at 1:49 AM, Asif Saifuddin <auv...@gmail.com> wrote:

Thank you both for the feedback. I will continue my analysis to understand django well and also try to contribute some patch on django if I can.

For django URL dispatcher improvement I am also looking for some suggestions. Should I also look to some tool like werkzeug, webob along side django http, url dispatch, middleware and related stuffs. Some guide will help me to dig more and go to proper direction.

Take inspiration from wherever you can. Those patches will demonstrate different ways of doing dispatch, and different ways to organize a stack; in an ideal world, you should be able to use any of those techniques in Django as well. If you can find a way to modify Django so that those techniques can be used (either by directly using a third party package, or by building a Django equivalent), then I'd say you've cracked the core of the project.

Yours,

Russ Magee %-)

[Asif Saifuddin]

Hi,

Analyzing django code base docs and other tools I'm thinking of using werkzeug's routing infrastructure for developing django's one. django http mechanism can e re written using webOb/werkzeugs utilities too. this will need working django urlresolve, urls, middlewares, views, http and some more related components. Introducinf werkzeug/+webOb in django will let eliminate some of django's built in way of handling request/response processing, urlresolving, url routing, view processing some error handling etc. 

Sould I go for a detail one with what I have thought to implement till now?

./auvipy

--

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/CAJxq84_XbuDCeX5LHgP4%2BuCYdzBAUUMY4EJxYj8WU%3DBP43onXA%40mail.gmail.com.

[Florian Apolloner]

Hi Aisf,

while it theoretically would be possible to replace all of Django's request/response handling with Werkzeug, there is not much gain in it currently -- especially when considering backwards compatibility etc…

Cheers,
Florian

[Josh Smeaton]

To expand on Florians reply, why do you think replacing the routing infrastructure is a good idea? Is there any tangible benefit in doing so? Can you demonstrate that you can stay completely backwards compatible while realising those benefits? If there answer is no to benefits or backwards compatibility, then I don't think you're going to see much support for the idea.

Regards,

[Russell Keith-Magee]

To my mind, the goal of this project isn't to replace Django's routing infrastructure - as Josh and Florian have pointed out, unless you can provide a backwards compatible interface as well as tangible API improvements, we're unlikely to adopt that code. 

However, there *would* be benefit in making changes to Django's codebase so that if someone *wanted* to use an alternate routing infrastructure, they could, *in their own project*. In this context, the purpose of using webOb/werkzeug routing isn't to provide new features or backwards compatibility - it's to demonstrate that a completely alien codebase with analogous features can be integrated into Django's infrastructure using a standardised API.

That said, I don't know enough about webOb or werkzeug to know if this is even plausible, so you'd need to provide a very strong technical proposal for this to be selected as a GSoC project. 

Yours,

Russ Magee %-)

--

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/c35b86be-cba9-4d66-8e8b-fb5fcb7cf92a%40googlegroups.com.

[Asif Saifuddin]

Seems my previous idea is not well suited for gsoc right now. have to look for more convanient ideas then. what about best practise update? where will I get Ideas about what are considered as best practise in django 1.8/+? or other suggestions?

Regards

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAJxq84_tfCxFPG3fTY%2BNWcAcWV1tjv4VwE%2BvmWiKTsnTyPLAcg%40mail.gmail.com.

[Cheng Chi]

What about a built-in models.BitField ? Or a generic tagging function giving related items recommended by TF-IDF?

[Russell Keith-Magee]

Hi Asif,

The "Best Practices" project requires a bit of investigation on your part. The project description gives one suggestion (expanding the use of Class-based views), but essentially, pick any feature that has been added in the last 5 years, and see if Django is making good use of that feature internally. If not, propose how we could be doing better.

Yours,

Russ Magee %-)

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAKAqTgrbTn1B77-N7Qf1iya4oX1Btt7u37u5kfyoNQq%2BdW-h2w%40mail.gmail.com.

[Asif Saifuddin]

Thanks Russell.

Investigating contrib apps I can see some are django apps using django framework and some are modules which is used to extend django frameworks functionality.

For admin app theres is no use of urls.py for the admin app but admin_urls in template tags, admin_lists etc. isn't it possible to used classed based views,  to handle views and forms? there are also many files some of them could be changed unders class based views. are this type of checking shoul I perform to prepare my proposal for best practices ?

Reagrds

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAJxq849jNhnGUyxw5sXoC_MtHpsBC8G9%3DXKogLe2bKomnRT5Ng%40mail.gmail.com.

[Asif Saifuddin]

Hi,

running django test suite under python 3.4.3 on my ubuntu 14.10 produce the below output

ERROR: test_extract_function (utils_tests.test_archive.TestBzip2Tar)

----------------------------------------------------------------------

Traceback (most recent call last):

  File "/home/asif/foss/django/tests/utils_tests/test_archive.py", line 42, in test_extract_function

    extract(self.archive_path, self.tmpdir)

  File "/home/asif/.pyenv/versions/3.4.3/lib/python3.4/site-packages/Django-1.9.dev20150303124612-py3.4.egg/django/utils/archive.py", line 49, in extract

    with Archive(path) as archive:

  File "/home/asif/.pyenv/versions/3.4.3/lib/python3.4/site-packages/Django-1.9.dev20150303124612-py3.4.egg/django/utils/archive.py", line 58, in __init__

    self._archive = self._archive_cls(file)(file)

  File "/home/asif/.pyenv/versions/3.4.3/lib/python3.4/site-packages/Django-1.9.dev20150303124612-py3.4.egg/django/utils/archive.py", line 138, in __init__

    self._archive = tarfile.open(file)

  File "/home/asif/.pyenv/versions/3.4.3/lib/python3.4/tarfile.py", line 1553, in open

    raise ReadError("file could not be opened successfully")

tarfile.ReadError: file could not be opened successfully

======================================================================

ERROR: test_extract_function_no_to_path (utils_tests.test_archive.TestBzip2Tar)

----------------------------------------------------------------------

Traceback (most recent call last):

  File "/home/asif/foss/django/tests/utils_tests/test_archive.py", line 51, in test_extract_function_no_to_path

    extract(self.archive_path)

  File "/home/asif/.pyenv/versions/3.4.3/lib/python3.4/site-packages/Django-1.9.dev20150303124612-py3.4.egg/django/utils/archive.py", line 49, in extract

    with Archive(path) as archive:

  File "/home/asif/.pyenv/versions/3.4.3/lib/python3.4/site-packages/Django-1.9.dev20150303124612-py3.4.egg/django/utils/archive.py", line 58, in __init__

    self._archive = self._archive_cls(file)(file)

  File "/home/asif/.pyenv/versions/3.4.3/lib/python3.4/site-packages/Django-1.9.dev20150303124612-py3.4.egg/django/utils/archive.py", line 138, in __init__

    self._archive = tarfile.open(file)

  File "/home/asif/.pyenv/versions/3.4.3/lib/python3.4/tarfile.py", line 1553, in open

    raise ReadError("file could not be opened successfully")

tarfile.ReadError: file could not be opened successfully

======================================================================

ERROR: test_extract_function_with_leadpath (utils_tests.test_archive.TestBzip2Tar)

----------------------------------------------------------------------

Traceback (most recent call last):

  File "/home/asif/foss/django/tests/utils_tests/test_archive.py", line 46, in test_extract_function_with_leadpath

    extract(self.archive_lead_path, self.tmpdir)

  File "/home/asif/.pyenv/versions/3.4.3/lib/python3.4/site-packages/Django-1.9.dev20150303124612-py3.4.egg/django/utils/archive.py", line 49, in extract

    with Archive(path) as archive:

  File "/home/asif/.pyenv/versions/3.4.3/lib/python3.4/site-packages/Django-1.9.dev20150303124612-py3.4.egg/django/utils/archive.py", line 58, in __init__

    self._archive = self._archive_cls(file)(file)

  File "/home/asif/.pyenv/versions/3.4.3/lib/python3.4/site-packages/Django-1.9.dev20150303124612-py3.4.egg/django/utils/archive.py", line 138, in __init__

    self._archive = tarfile.open(file)

  File "/home/asif/.pyenv/versions/3.4.3/lib/python3.4/tarfile.py", line 1553, in open

    raise ReadError("file could not be opened successfully")

tarfile.ReadError: file could not be opened successfully

======================================================================

ERROR: test_extract_method (utils_tests.test_archive.TestBzip2Tar)

----------------------------------------------------------------------

Traceback (most recent call last):

  File "/home/asif/foss/django/tests/utils_tests/test_archive.py", line 31, in test_extract_method

    with Archive(self.archive) as archive:

  File "/home/asif/.pyenv/versions/3.4.3/lib/python3.4/site-packages/Django-1.9.dev20150303124612-py3.4.egg/django/utils/archive.py", line 58, in __init__

    self._archive = self._archive_cls(file)(file)

  File "/home/asif/.pyenv/versions/3.4.3/lib/python3.4/site-packages/Django-1.9.dev20150303124612-py3.4.egg/django/utils/archive.py", line 138, in __init__

    self._archive = tarfile.open(file)

  File "/home/asif/.pyenv/versions/3.4.3/lib/python3.4/tarfile.py", line 1553, in open

    raise ReadError("file could not be opened successfully")

tarfile.ReadError: file could not be opened successfully

======================================================================

ERROR: test_extract_method_no_to_path (utils_tests.test_archive.TestBzip2Tar)

----------------------------------------------------------------------

Traceback (most recent call last):

  File "/home/asif/foss/django/tests/utils_tests/test_archive.py", line 37, in test_extract_method_no_to_path

    with Archive(self.archive_path) as archive:

  File "/home/asif/.pyenv/versions/3.4.3/lib/python3.4/site-packages/Django-1.9.dev20150303124612-py3.4.egg/django/utils/archive.py", line 58, in __init__

    self._archive = self._archive_cls(file)(file)

  File "/home/asif/.pyenv/versions/3.4.3/lib/python3.4/site-packages/Django-1.9.dev20150303124612-py3.4.egg/django/utils/archive.py", line 138, in __init__

    self._archive = tarfile.open(file)

  File "/home/asif/.pyenv/versions/3.4.3/lib/python3.4/tarfile.py", line 1553, in open

    raise ReadError("file could not be opened successfully")

tarfile.ReadError: file could not be opened successfully

----------------------------------------------------------------------

Ran 9087 tests in 214.033s

FAILED (errors=5, skipped=535, expected failures=7)

Destroying test database for alias 'default'...

Destroying test database for alias 'other'...

before that python 3.4.3 was installed under pyenv without bztar2 or something like that and gnu readline

I was preparing to work on some old tickets actually. Although not sure its the right place to post this issue.

regards

[Tim Graham]

I have seen that error on my own system Ubuntu 14.04 & Python 3.4.2 (installed from source), but didn't investigate the cause. I just installed Python 3.4.3, however, and don't have the problem there. Now I've reinstalled 3.4.2 and the error is resolved there as well.

[Asif Saifuddin]

About the best practice project idea I'm analyzing contrib apps. I found Admin docs app using class based views and probably it's almost up to date. for admin and some other apps there are no class based views used. for revamping django admin as a part of best practice update hoow about extending django admin with the ideas from 3rd party apps llike djang admin 2? or others. just for querying

Regards

--

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/cbcd7c47-efaf-4ec6-a2d5-75f73d60f3a5%40googlegroups.com.

[Tim Graham]

It's up to you to convince the value in your ideas. The more specific you can be, the easier we'll be able to give feedback. Here's a related ticket about using class-based views in contrib.auth which may be helpful: https://code.djangoproject.com/ticket/17209

[Asif Saifuddin]

Thanks a lot tim! that will be really helpful!

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/3b78ee4a-2724-4dcb-9d56-69cee1379f8c%40googlegroups.com.

[Asif Saifuddin]

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

for backward compatibility the following way can be followed

def password_change_done(request, *args, **kwargs):

      return PasswordChangeDoneView.as_view(**kwargs)(request, *args, **kwargs)

[Tim Graham]

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?

[Asif Saifuddin]

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

--

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.

[Tim Graham]

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."

[Asif Saifuddin]

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.

[Asif Saifuddin]

Have a look. though rough draft and many place for improvment

https://gist.github.com/auvipy/1da0d96f826bd8da4d47

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/d1396618-9c67-4034-be34-66049ef13cbb%40googlegroups.com.

[Tim Graham]

Sorry, but to be honest I am not enthusiastic about this proposal. I'm not sure there's a great need or value in converting all function based views to class-based views. Your plans regarding django-extra-views and admin improvements have not been described in sufficient detail that give me a good idea of what you plan to do. Finally, the lack of a timeline leaves me wondering how many weeks worth of work you have planned.

[Russell Keith-Magee]

I agree with Tim's assessment - this is not a compelling proposal at the moment.

There is value in converting *some* of the function based views to CBVs, but unilaterally converting all of them doesn't seem especially worthwhile. The key thing is to identify what features need to be factored out. A view doesn't get better just because it's class-based. It gets better because the class-based structure allows you to factor out key functionality in a way that subclasses can override or modify that functionality. I might be more enthusiastic about this aspect of the proposal if you detailed what features of each view you were hoping to make user-overridable.

The Formset and Admin parts of your proposal are sufficiently nebulous that it's impossible to see what you have in mind. "The good parts" from formset-extras and "the goodies" from admin2 could easily be a project in itself. 

The lack of a timeline is also a major omission. For me, the timeline is the most important part of the proposal.

Yours,

Russ Magee %-)

--

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/a1a4d8a8-9b46-410c-89f9-171ca135bd6f%40googlegroups.com.

[Asif Saifuddin]

I have updated the proposal with what I'm planning to acheive in the program and updating  with my analysis and plans to acheive the goal. still in draft and am editing according the goal I wanted to acheive/implement in this project proposal.

[Asif Saifuddin]

Hi,

I have been updating my proposal and as the deadline is friday Your feedback will help me to make it better in technical point of view

https://gist.github.com/auvipy/1da0d96f826bd8da4d47

Regards

[Tim Graham]

It still doesn't interest me enough to provide any additional feedback.