Hi, Robert, I just wanted to say that I'm +9000 in favor of your proposal. In fact, I think Django as a whole can benefit from the kind of reasoning behind your argument. Having key strengths is what drives adoption from new users, and that should be any framework's concern. I strongly feel that this sort of "commercial" concern is the only thing that is really lacking in Django as a framework today.
The admin has been touted as one of Django's most prominent features, because it lets you work with data easily and early in the development process. Is it complete? No. Is it perfect? Definitely not. But it's damn good for a significant number of use cases, and that is why it is still part of core. For what it's worth, I have used django-registration much more frequently than I have used the admin, and I'm willing to bet that's the case with other users as well. Therefore, the "percentage of use cases" is not a valid argument. We ought not to confuse is and ought. Cheers, AT On Fri, Aug 1, 2014 at 10:28 AM, Robert Grant <[email protected]> wrote: > Hi Tim > > I did. I just reread it though; thanks for the link. There are multiple > ways to do registration, agreed, but then one could - for example - make > your same argument about logging into a system. Why provide that when some > people might not want a site with authentication, or might want to do it > through Facebook or OpenID? (Or, as per your reference to James' reasons, > Persona?) > > What I'm (primarily) talking about is a registration system that > complements Django's user system. Registering a user that can log in via > Django's built in login functionality as a Django user, with some > toggleable features that can be extended by future releases or 3rd party > packages. This might not be a 90% use case for all of Django, though I > don't know how to measure the number of people that use the various > registration tools plus the number that roll their own unnecessarily, but > I'd imagine it's useful for a very high percentage of the projects that use > Django's user system. > > > On Friday, 1 August 2014 15:30:31 UTC+2, Tim Graham wrote: >> >> Did you read the reasons that James decided to stop maintaining it? >> >> http://www.b-list.org/weblog/2013/aug/26/catching/ >> >> Any Django site that uses a database will benefit from integrating >> database migrations. On the other hand, there are many ways to do user >> registration (as James described in his post) so django-registration isn't >> a 90% use case that qualifies for inclusion in contrib. >> >> On Friday, August 1, 2014 9:02:54 AM UTC-4, Robert Grant wrote: >>> >>> Hi Tim >>> >>> Thanks for the reply. I'd say that it's only been viable so far because >>> James created and maintained it (for most of that long time), it's only >>> been a year since then and Django is pretty stable around users and >>> authentication. And even then people have forked the thing to Github to >>> create ad-hoc compatible versions for 1.6, because it's a very important >>> package. However, this isn't a stable situation; it was once, but now is >>> going to decay without proper maintenance. >>> >>> The reason why I think it should be pulled into contrib is because >>> registration goes hand in hand with changes to the way users and >>> authentication work in Django, and keeping the two in lockstep should be >>> relatively simple for those with an intimate knowledge of that part of >>> Django. Additionally, I think it's a key reason why people use Django, and >>> protecting features like that is important. >>> >>> Lastly, regarding the trend. South has been viable as a third party tool >>> for a long time, and has said "buck you" to the trend and made it all the >>> way into core. Which is great, because it means Django competes at the >>> highest levels in ORM, and that's another key reason to use Django. >>> >>> I suppose what I'm saying is that not everyone uses Django for love or >>> loyalty, or at least not to start with, and you have to pick which things >>> to maintain as its strengths and which to let go of to the community. >>> Coming from the outside, but having a fair amount of technology dev, design >>> and decision experience, I'd say having proper users and authentication >>> makes for a big, fairly rare distinguishing feature, and reliable >>> registration capabilities are an important complement to that. >>> >>> >>> On Friday, 1 August 2014 13:25:25 UTC+2, Tim Graham wrote: >>>> >>>> If no one has volunteered to maintain it in nearly a year since James >>>> stepped down, I think you'll have a tough time convincing us it's important >>>> enough to move into contrib. Also, the recent trend has been to remove >>>> things from contrib (comments, localflavor, formtools soon). >>>> django-registration has been viable as a third party package for a long >>>> time and I don't see a reason it couldn't continue as one. >>>> >>>> On Friday, August 1, 2014 7:07:19 AM UTC-4, Robert Grant wrote: >>>>> >>>>> Hello all >>>>> >>>>> I've just started using Django for a serious project and am really >>>>> enjoying using it; thank you. >>>>> >>>>> I'm using Django 1.6 and Python 3.4. For user signups, everyone >>>>> recommends using django-registration. However this is not under >>>>> active development >>>>> <https://bitbucket.org/ubernostrum/django-registration/wiki/Home> >>>>> (still works with a small code change) and as a budding Djangoer that >>>>> worries me twice: >>>>> >>>>> 1) as a developer, it makes my job much easier if standard functions >>>>> are provided. This is one of the (only) advantages of expensive corporate >>>>> tools; things such as registration and user management are well thought >>>>> through. >>>>> 2) as a Django fan (edjangalist?) I can already see that one of >>>>> Django's big advantages is that decent user management comes built in. >>>>> However it's not complete, and django-registration plugs a big hole, as >>>>> most websites will need this feature. Without it the user side of things >>>>> becomes less useful. >>>>> >>>>> Here's my proposal: >>>>> >>>>> Create a django.contrib.registration package. >>>>> Pull into it the existing django-registration code and update it to >>>>> work with the latest version of Django. >>>>> Keep it tightly in sync with changes to django.contrib.auth in the >>>>> future. >>>>> Add more flexibility, e.g. corporate options such as perhaps an admin >>>>> user can input email addresses of people to sign up, and the system >>>>> generates basic unactivated profiles that when triggered allow the users >>>>> to >>>>> then fill in their remaining details (for example, this is how JIRA >>>>> works). >>>>> And/or autodiscovery of users from LDAP settings and autopopulation of >>>>> user >>>>> models from LDAP queries. This may be too unfocussed for the team though; >>>>> it's just a very nice to have! >>>>> >>>>> Anyway, that's my idea. I'm worried that as over time >>>>> django-registration drifts farther from the current version of Django, the >>>>> amount of work developers have to do every time will increase to the point >>>>> where it's better for them to roll their own than try and work out how >>>>> Django 1.5 worked with django-registration and what they need to do to >>>>> patch the differences. This will lead to developers - who are attracted to >>>>> Django because of useful stuff such as this - abandoning the platform for >>>>> ones that provide benefits in other areas. >>>>> >>>>> Thanks for reading >>>>> >>>>> >>>>> Robert Grant >>>>> >>>> -- > 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 [email protected]. > To post to this group, send email to [email protected]. > 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/ea15b826-5fe2-45e0-940a-9f4ed3e41a4b%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/ea15b826-5fe2-45e0-940a-9f4ed3e41a4b%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" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. 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/CAKBiv3yM%2BSDyX%3DAyD4q8YSF5VhmcnQZWFY-O0ZrKesbL19GGaQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
