Re: Digest for django-developers@googlegroups.com - 3 Messages in 1 Topic

[Daniel Greenfeld]

> Adrian Holovaty <adr...@holovaty.com> Jan 13 12:07PM -0600

> The ultimate solution is: don't use model forms. I never use them for
> anything, precisely because of things like this, where the framework
> is trying to do too much behind the scenes. It's too magical for my
> tastes, and while I understand why we added it to the framework, I see
> it as a crutch for lazy developers. C'mon, it's not a lot of work to
> create a "normal" (non-model) form class and pass its cleaned data to
> a model's save() method.
>
> End rant. :-)


I pretty much agree with Adrian. I use ModelForms when I'm grinding
out stuff fast, but for real, detail work, I rely on normal
forms.Forms.

My reasons match Adrian's reasons. I use them as a crutch, but the
magic can hurt at the worst time. So when I have time, I refactor to
make thing simpler and less atomic.

I leave all the magic stuff to smart people. ;)

-- 
'Knowledge is Power'
Daniel Greenfeld
http://pydanny.blogspot.com

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

Feature request: read-only admin view

[Daniel Greenfeld]

> Russell Keith-Magee <russ...@keith-magee.com> Jan 28 10:28AM +0800
>
>> feature is out of scope. A lot of people believe that it should be in
>> scope. Therefore I would like to politely request a reconsideration of
>> this decision.
>
> Even though I'm the person who wonfixed the ticket most recently, I'm
> inclined to agree with you -- but for a different reason.
>
> The original reason -- that the admin isn't intended as a general
> purpose site, just a backend editing interface -- is still valid. I'm
> not in favor of trying to turn the admin into something that people
> will try to interpret as a publicly visible CMS.

I agree 100%. The admin should remain the admin.

> I'd also point out that at DjangoCon.US last year, there were some
> initial discussions about developing a "NewAdmin". I don't think this
> effort has gone very far since then, but it's worth noting that there
> is high-level agreement that Django's admin is in need of a bit of a
> shakeup; increased functionality (like view permissions) might be
> something that could fit into that broader change.

Working with NoSQL these days I found the first big problem in Django
was the lack of a reliable django.contrib.admin alternative that works
with NoSQL. I looked into various third party apps that stapled
themselves into the Django Admin, and was unhappy. Why? Because the
Django Admin was designed for the ORM, and stapling additional non-ORM
functionality on it was outside it's original design scope.

I think increasing that design scope is a bad idea. The admin should
remain pretty much as it is, just incrementally changed to match the
rest of Django.

However, I think there is a viable alternative available right now.
And that is using CBVs and *perhaps* the existing css/js from the
admin to create 3rd party comparable tools that could include
non-editable views, NoSQL views and more all following a relatively
common pattern. It's not that hard, and it is certainly easier than
trying to either extend django.contrib.admin to a crazy extent or
rolling a new hyper-abstracted newadmin.

My first effort is django-mongonaut. It's still pretty new, but we are
using a more feature complete version in production now
(django-mongonaut is basically an extraction like Django was extracted
from Ellington). It has non-editable views for non-staff users and
fully editable views for people with rights.

In any case, I'm not advocating of django-mongonaut, I'm advocating
it's approach. Which is new code in 3rd party apps to solve new
problems but using the old patterns established by
django.contrib.admin. I think this is is the better, easier way to go
because it keeps Django's core scope smaller. Which makes advancement
of the framework easier for the hard-working people who contribute to
it.

-- 
'Knowledge is Power'
Daniel Greenfeld
http://pydanny.blogspot.com

-- 
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: Proposal: upgrading the choices machinery for Django

[Daniel Greenfeld]

On Wednesday, April 4, 2012 9:41:23 AM UTC-7, Adrian Holovaty wrote:

> 2012/4/3 Łukasz Langa :
> > Explicit choice values::
> >
> >  GENDER_MALE = 0
> >  GENDER_FEMALE = 1
> >  GENDER_NOT_SPECIFIED = 2
> >
> >  GENDER_CHOICES = (
> >  (GENDER_MALE, _('male')),
> >  (GENDER_FEMALE, _('female')),
> >  (GENDER_NOT_SPECIFIED, _('not specified')),
> >  )
> >
> >  class User(models.Model):
> >  gender = models.IntegerField(choices=GENDER_CHOICES,
> >  default=GENDER_NOT_SPECIFIED)
> >
> >  def greet(self):
> >  if self.gender == GENDER_MALE:
> >  return 'Hi, boy.'
> >  elif self.gender == GENDER_NOT_SPECIFIED:
> >  return 'Hello, girl.'
> >  else: return 'Hey there, user!'
> >
> > This is a saner way but starts getting overly verbose and redundant. You 
> can
> > improve encapsulation by moving the choices into the ``User`` class but 
> that on
> > the other hand beats reusability.
>
> I don't see the immediate need for Yet Another Sub-framework, as
> described in this proposal. This is what I normally do, and it works
> fine:
>
> class User(models.Model):
> MALE = 0
> FEMALE = 1
> GENDERS = [(MALE, 'Male'), (FEMALE, 'Female')]
> gender = models.IntegerField(choices=GENDERS)
>
> def greet(self):
> return {MALE: 'Hi, boy', FEMALE: 'Hi, girl.'}[self.gender]
>
> If people aren't understanding that, we should improve our documentation.
>
> Also, the fact that we *don't* have a sub-framework for this lets
> people do whatever they want -- including using the dj.choices module.
> So I am -1 on including this in Django proper.
>
> Adrian
>


+1 to what Adrian says. In fact...

On two occasions now I've had to do serious debugging on implementations 
done by other people who used a technique not dissimilar to what Łukasz 
proposes. In both cases, while the inheritance and better control 
structures were nice, the issue was that if you give people enough rope to 
hang themselves, they will.

The current system works very well, especially when you follow Adrian's 
pattern. Lukasz' system works well too. Therefore...

I submit that we keep Django core for choices as is and let people who want 
to use another system implement 3rd party packages. 
 

-- 
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/-/F20PJZowsZ4J.
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: Digest for django-developers@googlegroups.com - 3 Messages in 2 Topics

[Daniel Greenfeld]

On Sun, Jun 24, 2012 at 12:17 PM,  <django-developers@googlegroups.com> wrote:
>   Today's Topic Summary
>
> Group: http://groups.google.com/group/django-developers/topics
>
> Proposal: Add some extensibility / decoupling features to Django templates
> [1 Update]
> Django-nonrel patches [2 Updates]
>
>  Proposal: Add some extensibility / decoupling features to Django templates
>
> Yo-Yo Ma <baxterstock...@gmail.com> Jun 23 05:17PM -0700
>
> I'll start with an example:
>
> Using Jinja2, I can create an environment which is pretty secure (no access
> to anything but built-ins and objects explicitly marked "safe"), and
> provide a loader who's templates are loaded from the database (e.g.,
> ``request.client.template_set.all()``), and customize all this for a single
> request (Since I can simply instantiate an ``Environment`` per request with
> a custom ``Loader`` which has access to only the ``request.client``
> templates). I can also customize the extensions on a per-request basis
> (that's sort of analogous to customizing template tag/filter built-ins), in
> order to limit or add to the type of tools that clients have access to.
>
> Using Django templates, I'm left with simply running my clients' sites
> portion of the app under a different settings file. This *almost* cuts it
> too (since I can use a different URL conf which includes different
> template.add_to_builtins() calls, etc.), but it doesn't give me all the
> things that I need, like the ability to instantiate the loader with a
> queryset of templates for the ``request.client``, etc.
>
> "Why don't you just use Jinja2 then?"
>
> The Django core team is a pretty intelligent team, and the philosophy
> behind the style of tags / filters / lack of logic in Django templates is
> far superior to Jinja2. I simply want a more Jinja2-ish Python API for
> using Django templates.
>
>
> My Proposal (abstract explanation, btw, I'd be happy to help architect /
> write code):
>
> Without changing any of the existing functionality or settings in Django,
> refactor the template system to use an ``Environment`` class (something
> akin to Jinja2's ``Environment``) which takes a list of loaders, and a
> number of other arguments. Then, instantiate this class, using the provided
> settings, and use it for all the default functionality (the admin,
> render_to_response, CBV template access, etc.). This would allow developers
> to make their own ``Environment`` instance with different arguments,
> request-specific or otherwise, and without having to do a lot of evil
> things.
>
>
> Thanks
> Fellow Djangonaut
>
>
>
>  Django-nonrel patches
>
> Andres Douglas <andres.doug...@gmail.com> Jun 22 09:30PM -0700
>
> Hey All,
>
> I've been trying to use django with mongo and it seems like django-nonrel
> is still the best option out there. The only sad fact is that it's still
> not part of the official django. Looking for an answer as to why that was
> the case, I came across this thread. Are tests and docs all that are
> missing? Can someone provide pointers to what might be expected and
> considered acceptable?
>
> It seems like a lot of the hard work has already been done figuring out
> what needed to change and the only thing left shouldn't be as hard -
> hopefully these are not famous last words.
>
> On Sunday, January 8, 2012 12:45:08 PM UTC-5, Jonas H. wrote:
>
>
>
> "Cal Leeming [Simplicity Media Ltd]" <cal.leem...@simplicitymedialtd.co.uk>
> Jun 23 08:13PM +0100
>
> Hi Andres,
>
> Afaik, there's currently some compatibility issues with Django 1.4 - so
> it's not currently stable.
>
> Also, in my own personal opinion - after having a chance to use the mongo
> models with Django, in my personal opinion, it just didn't "feel right".
> Not entirely sure how to explain what that means, but for whatever reason
> the approach used just didn't feel like it was the best approach that could
> be used.
>
> Would be interesting to hear what conclusions other people came too,
> especially any core devs involved in the ORM.
>
> Cal

We evaluated django-nonrel for use in projects and looked again at
django-nonrel for our talk at DjangoCon Europe. To summarize our
findings and opinions:

1. django-nonrel is stuck on Django 1.3, which has some security implications.
2. django-nonrel is unsupported. It switched maintainers and the
current maintainer is not working on it.
3. [pydanny opinion warning] django-nonrel wasn't adopted in Django
core because it lacked adequate documentation and tests.
4. [pydanny opinion warning] django-nonrel treats MongoDB as a
relational store, which it most certainly is not.
5. [pydanny opinion warning] dj

Re: Django-nonrel patches

[Daniel Greenfeld]

On Sunday, June 24, 2012 10:31:41 PM UTC+8, Cezar Jenkins wrote:
>
> I'm only lightly involved in the project, but there is some misinformation 
> going around about it.
>
> On Sun, Jun 24, 2012 at 5:47 AM, Daniel Greenfeld <pyda...@gmail.com> 
> wrote:
>
>>
>>
>> We evaluated django-nonrel for use in projects and looked again at
>> django-nonrel for our talk at DjangoCon Europe. To summarize our
>> findings and opinions:
>>
>> 1. django-nonrel is stuck on Django 1.3, which has some security 
>> implications. 
>
> 1.4 support is implemented and being tested in a beta mode right now.
>

I don't mean to pick bones, but looking at the github account, BETA 
apparently means being a port with stern warnings about not using it right 
now.
 

> 2. django-nonrel is unsupported. It switched maintainers and the
>> current maintainer is not working on it.
>
> Django-nonrel is very much maintained. Look at the github 
> https://github.com/django-nonrel/
>  
>
This does not match what someone claiming to be the current lead maintainer 
said to me personally after my talk in front of dozens at DjangoCon Europe. 

While I understand this sort of misinformation I may have spread is 
annoying to you, imagine how it comes to the rest of us when project 
leadership is not clear. 

1. http://django-nonrel.readthedocs.org lacks any sort of team/contributor 
listings.
2. https://github.com/django-nonrel/mongodb-engine/blob/master/AUTHORS.rst 
has people in it who may no longer maintain it.

What's going on? What can django-nonrel do to make it much more clear to 
everyone who is involved and who is the actual leadership?

>
> I have to agree with you here. The nature of the Django ORM makes anything 
> like this a hack. Not much choice in that regard.
>
> I've wondered if it's possible to make an ORM that API compatible with 
> forms/admin/etc that doesn't hack onto the existing ORM?
>
>>
>> In my humble opinion, the answer is no. ORM is for mapping objects onto 
relational databases, and the entire API is designed around that concept. 
MongoDB is a Document store and should be handled differently. 
 Django-nonrel adds a lot of magic, not necessarily in code, but in API 
design. It turns non-relational databases into relational databases, IMO 
removing many of the advantages of those systems for little gain except for 
in early speed of development.

The trick is, as I believe others have raised, is how to get Admin and 
Forms and other things in Django to work with MongoDB. :-)

Danny Greenfeld

>

-- 
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/-/VktFJetdkWIJ.
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: Why doesn't DjangoProject.com downloads provide a Windows installer like web2py does?

[Daniel Greenfeld]

On Sunday, December 23, 2012 9:45:46 AM UTC-8, ted wrote:
>
> This has lead me to the belief that a virtual linux box is the "right way" 
> to develop on django on windows.  On its face, adding a virtualbox/vagrant 
> setup step makes using django more complicated.  But, on net it makes the 
> first few days on django windows a lot faster/easier/better/less stressful 
> because you don't get the ecosystem issues Jason talked about.  Not to 
> mention making dev/prod parity better, which while a newcomer might not 
> understand they will appreciate in the long run.




I have to step in and strong object to Virtualbox as the 'right way' for 
Django on windows. I've made this argument plenty of times.

I've taught enough introductory classes and worked with enough people on 
Windows over the years to know that a huge number of beginning developers 
around the world are running on less than adequate machines. Python, 
Django, and SQLite3 have a low footprint that even an ancient computers can 
handle them easily. 

On the other hand, VirtualBox has a significant footprint. Older machines 
so frequently owned by beginning developers often do not have the resources 
to run VirtualBox without slowing down to unacceptable levels. Forcing 
beginning developers to play in VirtualBox will exclude a lot of incoming 
talent, especially in less privileged areas of the world. 

Which would be a terrible shame.

The solution is to make the Python installation story on Windows easier. 
It's not the fun or easy answer, and maybe we need to convince Microsoft to 
throw money and resources at the problem. Since Python and Django supported 
on Azure, this may be the perfect time to make such a request.


-- 
'Knowledge is Power'
Daniel Greenfeld
http://pydanny.com

-- 
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/-/42rkFbdDvlkJ.
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: make the source code of the django tutorial available ?

[Daniel Greenfeld]

On Wednesday, January 16, 2013 4:43:14 PM UTC-8, Russell Keith-Magee wrote:
>
> Hi Daniele,
>
> On Thu, Jan 17, 2013 at 7:07 AM, Daniele Procida 
> <evi...@googlemail.com
> > wrote:
>
>> I'm re-opening an old discussion - 
>> https://groups.google.com/d/topic/django-developers/MbLD1BL5xkQ/discussion. 
>> Sorry if it all comes out weird, I'm having to do it in Google Groups.
>>
>> I propose maintaining a repository of the Polls tutorial code, with each 
>> branch representing the state of the code at the end of each tutorial.
>>
>> I realise that there is a danger that people might be tempted simply to 
>> checkout the code rather than type it in, following all the useful steps 
>> and mis-steps that the tutorial provides, but at the same time it would 
>> have other significant advantages that it would be a shame to forego just 
>> in order to save people from temptation, especially if they are strongly 
>> warned against it.
>>
>>
> Yes, because the best way to make sure nobody presses a button is to put a 
> sign over it saying "Under no circumstances press this button" :-)
>

What Russell said. 
 

> I can see what you're trying to achieve here, but I'm still not convinced. 
>
>  1) The tutorials aren't that complex; even if you did have to reproduce 
> them from scratch, it doesn't take that long (I've done this quite a few 
> times, so I'm speaking from experience here). 
>

If you copy/paste from an existing code base to get the tutorial working, 
then the tutorial is meaningless. Part of learning Django, Python, or 
whatever is through the experience of finding and fixing your mistakes. 
Making an official repository for the tutorial would be a disservice for 
would-be developers.
 

>
>  2) This is what version control is for. I'd much rather see someone do 
> the tutorial and use version control on their own repository, rather than 
> just pull down the latest version of a repo that contains all the code they 
> need.
>
> Following point 2, it might be worth suggesting that people use version 
> control during the tutorial. I'm not suggesting we turn the Django tutorial 
> into a parallel tutorial on git, but seeding the idea in people's heads has 
> the benefit of reinforcing best practice (you do version control everything 
> you do, right?), and makes it easier to work around the rollback problems 
> you describe; if they don't know what version control is, they might be 
> encouraged to go investigate, and as a result, another code-fairy gets 
> their wings :-)
>

There are already third-party versions of the Django tutorial that also 
instruct on source control and TDD. These are great, and wonderful, but I 
feel they overwhelm beginner Django developers with too much.
 

>
> It will help the documentation writers. It's difficult to build on the 
>> work in the tutorial if it's not easy to get where it was. For example, a 
>> new tutorial could use the Polls application to tackle logging or static 
>> files - which is what I would like to start doing now - but it's quite a 
>> bore to have to go through all the steps in all the previous tutorials just 
>> so you can start writing it.
>>
>
> I'm definitely not convinced by this. Anyone who is in a position to be 
> writing documentation should *definitely* be able to wrap their head around 
> enough version control to handle this sort of thing, or be sufficiently 
> expert to rebuild the tutorial in a couple of minutes.
>

This is a fact.

In August, when we worked on refactor of page 3 of the tutorial Dave and I 
spent about 5 minutes setting up things to match. The real spent was 
gathering feedback from beginners to find their pain points with the 
tutorial.
 

>  
>
>> I think it would be worthwhile having an official repository for this 
>> purpose.
>>
>  
> Thanks for the feedback. I'm still not convinced, but I'm always 
> interested to hear the opinion of others. Eventually, someone (or the 
> weight of public opinion) might convince me to change my mind
>

I'm completely with Russ. Scratch that, I feel much stronger about this 
issue then he does. 

Zed Shaw, with LPTHW, has proven that by forcing people to type stuff out 
they learn better. You don't learn by copy/pasting or checking against a 
working implementation. It's not always fun to learn this way, but learning 
software development is a process of doing.

There are other places the tutorial needs improvement besides an official 
working implementation of the app. Off the top of my head here are a couple 
of items:

1. The new tutorial intros are nice but missing some pieces. I'll document 
this in tickets soon.
2. Page 2 of the tutorial is too long. People start copy/pasting 

Re: deprecation of AUTH_PROFILE_MODULE

[Daniel Greenfeld]

I agree that email-as-username should be a built-in User abstract model (or 
something) in Django. It's an incredibly common use case and for once I 
think Django could use some additional functionality.

+1 to email as username model in core.

Danny

On Sunday, March 3, 2013 10:21:55 AM UTC-8, Florian Apolloner wrote:
>
> Hi Jacob,
>
> On Sunday, March 3, 2013 5:08:24 PM UTC+1, Jacob Kaplan-Moss wrote:
>>
>> I actually strongly disagree: I think Django *should* ship an 
>> "authenticate-using-email" system.
>>
>
> Out of curiosity, since I barely have this need by myself: Is it 
> "authenticate-using-email" or "use-email-as-username". Authentication via 
> Email can be done via a backend easily (though we should make the email 
> column unique then). So I am wondering what the main issue here is: is it 
> having username beeing a required field (an uuidv4 should suffice as a 
> workaround currently) or something different? 
>
> I can't promise it'd go in -- I'm not going to 
>> overrule a -1 from Florian by fiat -- but I think having a concrete 
>> patch on the table will make it easier to make a decision.
>
>
> No worries, if it would exist it would have been a -0.5; either way, a 
> concrete patch would certainly help. If it does make it into core I'd still 
> prefer the most minimal solution possible.
>
> Regarding the current proposal: Luke, can you tell us how your changes 
> would play with the current forms etc? Especially since some forms have a 
> hard coded dependency on a concrete user model (by design). I'd prefer not 
> to duplicate all those forms if somehow possible.
>
> Cheers,
> Florian
>

-- 
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: Deprecate admindocs?

[Daniel Greenfeld]

Can we assume it will be separated out? While none of us on the list use 
admindocs or care, a decent number of beginners seem to like to use it.

--Daniel Greenfeld

On Thursday, July 25, 2013 7:21:08 PM UTC+2, Julien Phalip wrote:
>
> On Jul 25, 2013, at 5:29 AM, Aymeric Augustin <
> aymeric@polytechnique.org > wrote: 
>
> > Hello, 
> > 
> > I'd like to deprecate admindocs. Here are my reasons: 
> > 
> > 1) It's called the "documentation generator", but it only operates on 
> docstrings. This promotes the idea that docstrings are appropriate 
> documentation, while the Python and Django communities now favor prose 
> documentation. 
> > 
> > 2) Even though it's possible to use docstrings to generate API 
> documentation, for instance with Sphinx' autodoc, I find that heavily 
> formatted, Javadoc-style docstrings (or late epydoc-style) [1] tend to be 
> hard to read for humans and I don't want Django to encourage them. 
> > 
> > 3) Its age shows [2]; it was a decent idea at the time it was created 
> but the standard for documentation has evolved a lot since then. 
> > 
> > 4) The featureset is very reminiscent of Django's origins, see for 
> example the "edit this object" bookmarklet. 
> > 
> > 5) Generating documentation doesn't belong to a web framework. There are 
> better tools for this purpose — namely, Sphinx. 
> > 
> > 6) There are a few old, unresolved tickets with patches, indicating low 
> interest [3]. 
> > 
> > 7) Test coverage is low (22%), discouraging contributions. 
> > 
> > 8) We could get rid of the optional dependency on docutils. 
> > 
> > What do you think? 
> > 
> > [1] 
> https://docs.djangoproject.com/en/dev/ref/contrib/admin/admindocs/#view-reference
>  
> > [2] 
> https://code.djangoproject.com/wiki/BackwardsIncompatibleChanges#Movedadmindocviewsintodjango.contrib.admindocs
>  
> > [3] 
> https://code.djangoproject.com/query?status=!closed=contrib.admindocs
>  
>
> That sounds reasonable to me. +1

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Proposal: Implement CORS & OAuth/OAuth2

[Daniel Greenfeld]

I'm going to give a strong +1 here. In fact, can I inflate that to +100?

As soon as something gets into Django itself then any improvements or API 
changes occur at a much slower pace. This is out of the necessity of 
providing a stable interface for developers. This becomes incredibly 
problematic when you need to have changes to reflect new developments in 
authentication and authorization. While things have currently 'stabilized' 
on OAuth 1 and OAuth 2, other systems may suddenly leap to the fore. In 
addition, major implementors of them (Twitter, Facebook, et al) are know to 
change things with little to no warning. Finally, there is always the risk 
of a security breach being discovered.

Putting this into contrib means that the community cannot quickly adapt to 
the changes in the authentication landscape. If Django had a faster release 
pattern that might not be a problem, but I'm not so sure about it.

As for the Django Packages site, we've been slowly working on fixing some 
bugs and bitrot. Once we've gotten the priority items done we plan to 
implement a way to promote and demote packages which will make grids much 
more useful. We've had this request several times for security-related 
packages, database connectors, and other things. We're not sure about the 
API yet, but there you go.

-- 
'Knowledge is Power'
Daniel Greenfeld
Principal at Cartwheel Web; co-author of Two Scoops of Django; Maintainer 
of Django Packages
cartwheelweb.com | pydanny.com | django.2scoops.org



On Sunday, July 28, 2013 5:25:43 PM UTC+2, Aymeric Augustin wrote:
>
>
> I have to disagree. The ecosystem of third-party packages is much more 
> instrumental to the success of Django than contrib apps (with the exception 
> of the admin). Blessing a solution stifles competition, hinders progress, 
> and makes it much harder for (possibly better) alternatives to emerge. 
> That's why the current trend is to slim down contrib. 
>
> -- 
> Aymeric. 
>
>

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Proposal: A diagram showing Class Based View inheritance and mixins.

[Daniel Greenfeld]

Seth,

I like it a lot. Is there any chance you can provide a focused version per 
Class-Based View?

Daniel Greenfeld

On Sunday, August 18, 2013 10:03:59 PM UTC+2, Seth Moon wrote:
>
> I believe it would be beneficial to the Django developers and users if the 
> documentation included a diagram showing the complete structure of how 
> Class Based Views get their functionality. This would be a relatively 
> simple diagram that shows the classes each generic view inherits from. The 
> reason I am proposing this is because the current state of Generic Class 
> Based Views is too complex for many people, myself included, with some 
> views inheriting from 9 other classes (CreateView, UpdateView) down a long 
> chain of both single and multiple inheritance. This would also enable 
> people to gain a deeper understanding of why the Views are structured the 
> way they are, and encourage people to explore the available BaseViews and 
> mixins in order to assemble more customized applications without having to 
> reinvent the wheel.
>
> I posted this on the Django Reddit 
> community<http://www.reddit.com/r/django/comments/1kkl2t/a_diagram_showing_the_entire_django_class_based/>with
>  relative success being the top post. There is a 
> DIA <https://projects.gnome.org/dia/> diagram file and SVG available on a 
> Google 
> Drive 
> folder<https://drive.google.com/folderview?id=0B4OX1EeVEeoKQWtQNF9ZMUpMOVE>that
>  is publicly accessible for you to download and modify. Version 3 is 
> the most current revision and differs extensively from what I originally 
> posted on Reddit.
>
> A preview of the diagram can be seen below (It's a fairly large image):
>
>

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Proposal: Revised form rendering

[Daniel Greenfeld]

I agree with Eric and my experiences back it up. Most of the people
who want to custom form widgets are the ones who are unprepared to dig
into Django/Python code. The easier we can make creating/extending
form widgets the better.

This looks like what I'll be sprinting on at DjangoCon. :)

Danny

On Jul 11, 1:14 pm, "flo...@gmail.com"  wrote:
> I'm glad to see that some serious thought is going into this issue!
> This proposal sound very good (to me, at least) on the whole.
>
> One thing that occurs to me, though, is that the people who are going
> to want to customize form output are very frequently going to be the
> people working mostly in the templates: the designers. It looks like
> you're not fully settled on the interface, but I think that exposing
> it on the form class like as_* means that it's going to be difficult
> for designers to customize that output.
>
> It seems to me that one way to give designers the ability to customize
> that output is to move some of that output logic out of Python and
> into templates.  Widgets could load up a template from a well-known
> location--something like e.g. django/widgets/textarea.html--and then
> template authors could customize that by providing their own template
> in that same path.  There would be some issues to sort out there, like
> the fact that Django would have to install some implicit Django-
> provided template directory at the end of TEMPLATE_DIRS, but I don't
> think that's too onerous.
>
> I'm not 100% sure that that's the answer, but whatever the answer is,
> I think it's important to note that the target audience for
> customizing form output isn't always going to be the Python
> programmer.
>
> Thanks,
> Eric Florenzano

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: Proposal: Revised form rendering

[Daniel Greenfeld]

On Jul 12, 8:12 am, Russell Keith-Magee <russ...@keith-magee.com>
wrote:
> On Mon, Jul 12, 2010 at 10:31 AM, André Eriksson <ean...@gmail.com> wrote:
> > Good proposal overall. One thought I have in order to try and combat
> > the massive parameter list of {% form %} is to optionally add an
> > ending tag, as well as sub-tags:
>
> > {% form myform %}
> >    {% using birthday=calendar %}
> >    {% renderer "as_ul" %}
> >    {% autocomplete "name_autocomplete" %}
> >    {% doctype xhtml1 %}
> > {% endform %}

In django-uni-form (http://github.com/pydanny/django-uni-form) we pass
into the form tag a 'form helper' object that contains attributes as a
parameter. This means that assembling the special qualities of the
form can happen in the view.py or forms.py.

helper = FormHelper()
helper.use_csrf_protection = True

{% uni_form myform helper %}

This approach has been popular in the community that uses django-uni-
form although mostly it is used to add buttons and layout options that
come in django-uni-form. People do really complex forms using the
layout extension of the project (especially using BartTC's Layout
module).

Its possible to extend this approach to include other options and
capabilities and work that into the proposed forms changes:

helper = FormHelper()
helper.doctype = 'xhtml1'
helper.use_csrf_protection = True

{% form myform helper %}
  {% form myform errors %}
  {% form myform hidden %}
  {% form myform field name using autocomplete:"name_autocomplete" %}
  {% form myform field birthdate using calendar important %}
{% endform  %}

I'm not sure this is the right way to do things here. The FormHelper
object as implemented needs to be controlled outside the templates.
Which possibly defeats some of Russ' goals in this effort. Also, from
experience, when people put a lot of functionality in the FormHelper
object (django-uni-form's Layout module comes to mind), it means that
the layout controls are in view.py, not in the template. Which
arguably means that the controls are out of the hands of the designer
and in the hands of the developer.

Until I get around to refactoring django-uni-form,

Daniel Greenfeld
pydanny.com

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: four NoSQL backends you want? :)

[Daniel Greenfeld]

On Sep 28, 3:07 am, Thomas Wanschik <twansc...@googlemail.com> wrote:
> On 28 Sep., 02:45, Russell Keith-Magee <russ...@keith-magee.com>
> wrote:
> We've started a supported/unsupported feature list on 
> djangopackages:http://www.djangopackages.com/grids/g/cloud/
>
> So please help in order to get closer at least one step towards NoSQL
> in Django.

NoSQL != cloud, so I changed the name, slug, and description for
http://www.djangopackages.com/grids/g/cloud/

It is now: http://www.djangopackages.com/grids/g/nosql/

Perhaps it should even be nosql-backends?

Daniel Greenfeld

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: [GSoC] Revised form rendering

[Daniel Greenfeld]

First off, for some arcane reason Google is forcing formatting on me. 
Hopefully that doesn't make this email that ugly.

Anyway, as the current lead on Django Uni-Form I think its great that Gregor 
is picking up the torch for refactoring form rendering in Django 1.40. He's 
obviously done his homework and put a lot of thought into this critical part 
of Django. 

I'm not a core developer my vote doesn't count, but I'm giving it anyway. +1 
from me.

Daniel Greenfeld
pyda...@gmail.com


-- 
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: Timezone-aware storage of DateTime

[Daniel Greenfeld]

I think this topic is not realistic.

If you store DateTime in another format then what the database is designed 
to deliver, then you don't just lose sorting and search capabilities, you 
also lose the ability for that data to be read and understood trivially by 
other tools besides Django. Which means the task of moving data from one 
database to another, or applying non-Django tools to the data suddenly has 
become much more complicated - to the point that non-Django people looking 
at the database will rightly wonder why the framework is obfuscating data.

Daniel Greenfeld
pyda...@gmail.com

-- 
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/-/SUJHN3lvZmlSd0lK.
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: Django Docs for Forms - Alternative Pattern from Advanced Django Forms Usage talk?

[Daniel Greenfeld]

One of the things that I think would be wonderful is to see this and other 
issues such as server specific settings actually described in a Django best 
practices document. And not as part of the wiki.

-- 
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/-/x2P5VD53QTsJ.
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: Django Tutorials

[Daniel Greenfeld]

Javair,

Not to put a fine point on it, but did you actually bother to look at 
djangobook.com? It says: "A warning about this edition" on the front page 
and then goes into asking that users not work on it. Is this why you don't 
want to work on it?

Daniel Greenfeld

On Monday, October 28, 2013 7:29:40 PM UTC-7, Jasvir Singh wrote:
>
> On Tue, Oct 29, 2013 at 1:22 AM, Tim Graham <timog...@gmail.com> 
> wrote: 
> > I don't mean to be a downer, but I don't see anything in your outline 
> that's 
> > substantially different from what the official Django documentation 
> offers. 
> How it can be different, as both are about same topic. 
>
> > Is there a reason you think you need to create a new resource 
> Actualy when I have started working on Django and I open Django book, 
> I got scared. I was like, "do i have to read all this?this is huge". 
> When I start with tutorial of poll application, it does'nt make that 
> much clearence, 
> what is going on at the beckend, what are views, models etc, because I 
> have no 
> knowledge about working on frameworks, even I didn't know what a framework 
> is. 
> I was totaly a NOOB. These things can demotivate the begginers as I 
> got demotivated 
> in initial stage. 
>
> So I have started these articles. 
> I have tried to cover all the basic concepts which are required for 
> working on Django in 
> very compact way. 
>
> No doubt, django's official documentation is best way to learn but if 
> someone read 
> django book after reading these articles, then he/she can have better 
> understanding 
> and can gain more from django. 
>
> > mentor someone contributing to the official docs which will likely reach 
> a 
> > much wider audience. 
> It would be my pleasure If I can contribute to official docs under 
> your mentorship. 
> We can add these articles to django official docs when they get 
> polished to that level. 
>
> -- 
>
> Jasvir Singh Grewal 
> Blog:http://jasvirsinghgrewal91.wordpress.com/ 
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/3faa1cda-75ef-4902-8518-340ba84c40b1%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: GSOC 2014 Project Proposal

[Daniel Greenfeld]

Time for me to delurk and cover a few things. I'm not a core developer of 
Django, but I honed my skills on the first edition of the Definitive Guide 
some years ago and am a co-author of a recently released Django-related 
book and it's sequel (Two Scoops of Django). 

First off, I'm not certain what Devashish was asking, but that's okay, I'm 
going to broach the issue of updating djangobook anyway.

As Camilo mentioned, the control of the web version of the book is in the 
hands of the authors. The author with the most recent exercise of control 
is Jacob Kaplan-Moss. Since the last pull request was accepted 9 months 
ago, there have been 34 pull requests submitted for updating content. At 
this moment, the book is a strange mix of 0.96 era and 1.4 era practices, 
confusing anyone new to the framework.

Now I'm not Jacob Kaplan-Moss, and I'm not going to put words in his mouth, 
but I completely understand why no activity has occurred on djangobook.com. 
As a fellow author I can tell you that managing the content on a large, 
heavily studied volume is an unbelievable amount of work. Pull requests are 
nice, but there are no tests suites for prose.

Note #1: There have also been several 'modernized' forks launched, but as 
far as I'm aware, none of them have been consistently maintained.

In any case, as the book is notoriously out-of-date and inconsistently 
updated, when I last requested to Jacob that the book needed a warning 
around it at the end of July, his response was to grant me commit rights. 
Ahem... The warning on the front of djangobook.com, reviewed by a couple of 
others, is my contribution. Considering how frequently the book is still 
recommended and the front page warning ignored, I've considered adding a 
warning bar at the top of every page. That's arguably controversial, and 
I've got enough stress in my life to not warrant any more. 

Note #2: I did consider managing the pull requests and updating 
djangobook.com myself, but the burden it would cause to my already heavy 
workload is too much. (Heck, I want open source time right now but that's 
my business...)

Note #3: I've considered taking djangobook.com off the wikipedia page at 
https://en.wikipedia.org/wiki/Django_(web_framework)#Online_resources. 
However, as an author of a published Django book myself, it feels weird and 
arguably inappropriate. So I'm recusing myself from editing if off that 
document.

So where am I going with all this?

Well, I would love to see an updated djangobook.com. I'm tired of people 
emailing me questions asking for help with things on which djangobook.com 
led them astray. I'm not the person to do this work, to manage this 
project, but I think it should be updated and managed by someone. The 
project should be managed by someone in the Django community who:

1. Has a deep understanding of Django. This needs has to be proven via 
current and previous projects or commits available 
2. Has a demonstrable grasp of RestructuredText. 
3. Has excellent writing and reading comprehension skills. They need to 
have publicly available examples of writing.
4. Displays good pull request management techniques. It's easy to accept 
pull requests, it's hard to reject them without hurting people.
5. Should have written technical tutorials available online in HTML format.
6. Can convince Jacob Kaplan-Moss to grant them commit rights.

This _could_ be a GSOC project, or it could be the work of an interested 
party. It would be nice to see it happen, just as it would be nice to see 
djangobook.com taken off the wikipedia page until it does get updated.

In the meantime, unless no core developer objects, after getting yet 
another emailed question about mod_apache deployment (thanks to 
http://www.djangobook.com/en/2.0/chapter12.html); on Monday I'll be adding 
a top-of-the-page warning at djangobook.com.

Regards,

Daniel Greenfeld
pyda...@gmail.com

On Friday, February 21, 2014 7:56:58 AM UTC-8, Camilo Torres wrote:
>
> On Thursday, February 20, 2014 2:42:07 PM UTC-4:30, Devashish Badlani 
> wrote:
>>
>> I am into my last year of graduation and I am currently an intern in Khan 
>> Academy ,Foundation for Learning Equality from IIT Bombay .I have been 
>> developing working with Django for the same
>>
>> *Title*: Building basic Web Frameworks for each module of Django Book 
>> for the beginners 
>>
>> I have prepared sample code which uses a JSON file and converts it in to 
>> a hierarchial topic tree so that a basic developer with the knowledge of 
>> HTML,CSS can easily understand with the documentation to each of the app 
>> prepared the interactive way to code in Django
>>
>> *Sample Code*
>> Git Repo:
>> https://github.com/deebee07
>>
>
> Hello Devashish,
>
> If you are planning to contribute to: http://www.djangobook.com, glad to 
> hear that. The http://www.djangobook.com pro

Re: GSOC 2014 Project Proposal

[Daniel Greenfeld]

After due consideration, I think updating djangobook.com should not be a 
GSOC project. Why not?

First, the book is owned by the authors and Apress, not the Django project. 
The Django community has no control. This probably runs afoul of some sort 
of GSOC rule.

Second, it's representative of something that is at least partly a 
commercial effort. In theory, Apress could take the revised content and 
publish it as a third edition. While I'm not opposed to the commercial 
selling of books at all, I think Google would take significant exception to 
GSOC funds being used this way.

Third, I think providing example projects for the tutorial chapters is not 
worthy of a GSOC project. It's too much of a low-hanging fruit and people 
have certainly done it already. I know because people try to do this with 
Two Scoops of Django's chapters (search GitHub and you'll find some 
attempts).

Fourth, because of the third issue, we risk complaints of plagiarism. The 
content already exists, it's just a matter of finding it. GSOC funding for 
code examples that already exist? No. No. No. Bad idea!

Daniel Greenfeld 

On Monday, February 24, 2014 2:28:41 AM UTC-8, Tom Evans wrote:
>
> On Sat, Feb 22, 2014 at 5:31 PM, Devashish Badlani 
> <deebe...@gmail.com> 
> wrote: 
> > Sir, 
> > 
> > 
> > Sample projects with the updated Django 1.6.2,use of latest modules in 
> each 
> > of them and an helpful documentaion ,would certainly enhance the value 
> of 
> > DjangoBook is what I feel 
> > 
>
> How would this work? The book currently admonishes readers that: 
>
> """ 
> The community edition of The Django Book is in transition. While the 
> book mentions Django version 1.4 in places, the vast majority of the 
> book is for Django version 1.0 
> """ 
>
> So you will write sample projects aimed at 1.6.2 for each chapter in a 
> book written for 1.0? This does not seem wise. 
>
> Cheers 
>
> Tom 
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/c1720c55-3b90-42e4-9045-9c06b8b99e84%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: GSOC 2014 Project Proposal

[Daniel Greenfeld]

One more note in this thread:

http://www.amazon.co.uk/The-Definitive-Guide-Django-Development/dp/1430258810

The Definitive Guide to Django is being revised. Apress has added Katie 
Cunningham to the author list, something that now I just remembered Jacob 
Kaplan-Moss mentioned to me in early 2013. I can only guess that 
djangobook.com will be updated as well.

I apologize for not considering the ownership issues in my first email in 
this discussion.

Daniel Greenfeld


On Monday, February 24, 2014 8:39:41 AM UTC-8, Daniel Greenfeld wrote:
>
> After due consideration, I think updating djangobook.com should not be a 
> GSOC project. Why not?
>
> First, the book is owned by the authors and Apress, not the Django 
> project. The Django community has no control. This probably runs afoul of 
> some sort of GSOC rule.
>
> Second, it's representative of something that is at least partly a 
> commercial effort. In theory, Apress could take the revised content and 
> publish it as a third edition. While I'm not opposed to the commercial 
> selling of books at all, I think Google would take significant exception to 
> GSOC funds being used this way.
>
> Third, I think providing example projects for the tutorial chapters is not 
> worthy of a GSOC project. It's too much of a low-hanging fruit and people 
> have certainly done it already. I know because people try to do this with 
> Two Scoops of Django's chapters (search GitHub and you'll find some 
> attempts).
>
> Fourth, because of the third issue, we risk complaints of plagiarism. The 
> content already exists, it's just a matter of finding it. GSOC funding for 
> code examples that already exist? No. No. No. Bad idea!
>
> Daniel Greenfeld 
>
> On Monday, February 24, 2014 2:28:41 AM UTC-8, Tom Evans wrote:
>>
>> On Sat, Feb 22, 2014 at 5:31 PM, Devashish Badlani <deebe...@gmail.com> 
>> wrote: 
>> > Sir, 
>> > 
>> > 
>> > Sample projects with the updated Django 1.6.2,use of latest modules in 
>> each 
>> > of them and an helpful documentaion ,would certainly enhance the value 
>> of 
>> > DjangoBook is what I feel 
>> > 
>>
>> How would this work? The book currently admonishes readers that: 
>>
>> """ 
>> The community edition of The Django Book is in transition. While the 
>> book mentions Django version 1.4 in places, the vast majority of the 
>> book is for Django version 1.0 
>> """ 
>>
>> So you will write sample projects aimed at 1.6.2 for each chapter in a 
>> book written for 1.0? This does not seem wise. 
>>
>> Cheers 
>>
>> Tom 
>>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/8decc06e-2704-446a-a900-30fc0802de3c%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Pull django-registration into contrib?

[Daniel Greenfeld]

What no one is discussing here is is that django-registration is just one 
out of several popular authentication backends that match it for use and 
great exceed it's functionality. They include:

* django-allauth
* django-userena
* python-social-auth (nee django-social-auth)

These three projects are extremely well maintained (huge communities of 
supporters), support dozens of OAuth implementations, and are the modern 
cornerstone of current Django registration. Bugs are fixed quickly, updates 
for OAuth providers come frequently, and **just plain work without 
forking**.

django-allauth in particular not only easily mirrors django-registration 
core functiomality, it has a safer logout mechanism.

Why do I bring this up? Well, if Django is going to have a built-in 
registration system, then I think it should benefit from having more eyes 
on the problem. While James Bennett is an awesome coder whose work has been 
a foundation of my own, his solitary effort 
(https://www.djangopackages.com/packages/p/django-registration/ shows only 
one committer) simply doesn't compare to the legions of people who have 
contributed to these other packages. Therefore, I submit that if a 
registration package will be brought into django.contrib, it should be one 
of these alternatives.

That said, I don't like the idea of adding more functionality to Django, 
even within django.contrib. IMO, a better alternative would be to suggest 
registration packages in the documentation of django.contrib.auth.

--Daniel Greenfeld



On Friday, August 1, 2014 9:17:30 AM UTC-7, Collin Anderson wrote:
>
> It seems to me, in any case, the first step is to get django-registration 
> actively maintained again. James Bennett is welcoming proposals of people 
> to take over maintenance of the project. Get it working well with custom 
> user models and with python 3. Once django-registration is a thriving app 
> as popular as django-south (about 10x as many people using it), it would 
> make sense to think about the possibility of adding it to contrib.
>
> I think LDAP and oauth (facebook login) support out of the box in django 
> would be great, though I think it's easier said than done, and 
> django-registration doesn't even do it out of the box.
>
> As for me personally. I use the admin in every one of the 18 django 
> websites I maintain, and in the few websites where non-staff users login to 
> the website, including this line in urls.py goes a long way for me:
>
> url(r'^accounts/', include('django.contrib.auth.urls')),
>
> If email-verification is required, I re-use the password reset code to 
> handle the tokens.
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/f5813b1d-529a-45b2-b14a-b4a78cf99757%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Requiring GitHub login for actions on Trac

[Daniel Greenfeld]

On Sunday, August 10, 2014 2:37:01 AM UTC-7, Aymeric Augustin wrote:

 

Using GitHub for auth a giant +1 from me. 

For me, this ranks up with the SVN to Github move as a: "Why hasn't this 
been done already?"

Daniel Greenfeld
co-author Two Scoops of Django

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/c71e5f12-822f-45d9-9880-149ae1e79061%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal new Django Admin css style

[Daniel Greenfeld]

Thanks for the mention, but I haven't had time to work or maintain that for 
months. I'm not sure how it works with the upcoming Django 1.7.  Also, for 
the sake of simplicity, the default skin for it is bootstrap 3. Any CSS in 
there is per skin, and probably doesn't belong in this discussion.

On Sunday, August 17, 2014 11:18:33 AM UTC-3, Danilo Bargen wrote:
>
> Just for the record, there's also 
> https://github.com/pydanny/django-admin2, another project that attempts 
> to create a more modular and extensible admin. 
>
> Danilo 
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/e5697a3c-aca2-4517-9632-29939bce66c2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Ticket #25236: Remove ifequal from the template language

[Daniel Greenfeld]

No modern project uses ifequal. No one recommends it. I argue it is taking 
up valuable bytes in the project. Let's remove it.

Reference https://code.djangoproject.com/ticket/25236

In there you'll see Tim Graham mentions that older Django projects may push 
back on it, and suggests that a good medium ground would be to remove it 
from the documentation.

Any comments?

Regards,

Daniel Roy Greenfeld

-- 
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/add63617-a253-4571-a705-bf5773ed18ec%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.