Re: #10355 Add support for email backends

[Russell Keith-Magee]

On Fri, Aug 21, 2009 at 12:34 PM, Andi
Albrecht wrote:
>
> Hi,
>
> I'm interested in working on #10355 "Add support for email backends."
>
> IMHO it's an good idea to make the email backend configurable. There
> are at least two use cases I can think of. The first is to send email
> with other services than SMTP, like App Engine as noted in the
> ticket's description. The second is to deliver email asynchronously,
> like the django-mailer application does already.
>
> The ticket currently needs a design decision, so my question is what
> the actual concerns to change this are.

I think the original concern was the time required to triage the
ticket :-) The original report is fairly light on detail, so I suspect
Jacob punted the proposal to DDN in a fit of rapid triage.

However, your proposal gives us a bit more detail to work with. On the
whole, I have to say I like what I see. This is the sort of thing I'd
like to see more of in Django - less specific feature enhancements
baked into the core, and more opening of interfaces that let people
plug their own capabilities in where they need to.

> I would propose the following changes. It's a very simplistic approach
> that tries to keep the current API as much as possible:

To qualify this - "as much as possible" must include "100% backwards
compatible with 0 code changes with all public advertised interfaces".

> Add a new setting EMAIL_BACKEND. A string that can be resolved to a
> class. Default should be the current SMTP implementation.

No problem with this, and follows the precedent set by other backends
(such as the cache backend)

> Provide a base class for mail backends. A mail backend must provide
> the method send_messages(email_messages) and must return the number of
> messages sent to provide backward compatibility. The constructor of a
> mail backend should take at least the keyword argument fail_silently
> (default: False). What I'm a bit unsure about are additional
> constructor arguments. Currently the SMTP backend allows in addition
> host, port, username, password and use_tls. Those are very
> SMTP-specific, but only username and password are used by the
> mail.send_mail* APIs. It would be an agreement to allow username and
> password in addition to fail_silently to not break the send_mail* API.

I'll need to look into this in more detail. I'm hesitant to lock down
APIs like this too much - the more rigid you make an interface, the
harder it becomes to use it in interesting way. I'm sure that some
insights will emerge as a result of writing the code.

> The SMTP backend could accept host, port and use_tls as extra keywords
> again to provide backward compatibility for code that directly uses
> SMTPConnection (within Django SMTPConnection is not used outside
> django.core.mail). I would suggest to rename SMTPConnection to
> SMTPBackend, but only if this would break too much third-party code as
> SMTPConnection is mentioned in the docs.

Breaking _any_ third party code is a non-starter. We can deprecate the
old name and provide an alias from the old name to the new name, but
historical usage must continue without modification.

> The test utils could be refactored to use a TestMailBackend instead of
> monkey-patching the mail module, but this would be a fairly invisible
> change as it would just change the way how the test utils provide the
> mailbox attribute in the mail module for unittests.

This is an interesting suggestion all by itself. It also dovetails
nicely with #8638. That ticket was on the list for v1.1, and
originally proposed including a 'test email server'. Ultimately, it
was decided not to include an email server, but to document the ways
you could use existing mail servers.

A 'test email backend' (as well as a dummy no-mail-at-all backend, and
a log-to-console/log-to-file backend) is a different way to target the
underlying problem posed by #8638.

> A nice addition to Django would be to include parts of django-mailer
> to provide a backend for asynchronous mail delivery. That could be the
> models and command line script to deliver mails. While thinking about
> this, django-mailer has a nice option for setting priorities to mails.
> IMO Django's API for sending mails should be as simple as possible
> (like it is today), but a priority option would be a nice addition
> even if the SMTP backend (as the default) wouldn't respect this option
> when sending mails.

I'm aware of the existence of django-mailer, but I haven't looked into
it in detail. At least for the first cut, I'd be more comfortable
seeing django-mailer-esque capabilities living as a community project.
Then, maybe in the v1.3 timeframe, we can look at adding it as a
'batteries included' backend.

That said - if a prototype django-mailer backend were to be developed
as part of this development effort, it would go a long way to proving
that the backend API you are proposing is sufficiently flexible. The
code doesn't need to be 

#10355 Add support for email backends

[Andi Albrecht]

Hi,

I'm interested in working on #10355 "Add support for email backends."

IMHO it's an good idea to make the email backend configurable. There
are at least two use cases I can think of. The first is to send email
with other services than SMTP, like App Engine as noted in the
ticket's description. The second is to deliver email asynchronously,
like the django-mailer application does already.

The ticket currently needs a design decision, so my question is what
the actual concerns to change this are.

I would propose the following changes. It's a very simplistic approach
that tries to keep the current API as much as possible:

Add a new setting EMAIL_BACKEND. A string that can be resolved to a
class. Default should be the current SMTP implementation.

Provide a base class for mail backends. A mail backend must provide
the method send_messages(email_messages) and must return the number of
messages sent to provide backward compatibility. The constructor of a
mail backend should take at least the keyword argument fail_silently
(default: False). What I'm a bit unsure about are additional
constructor arguments. Currently the SMTP backend allows in addition
host, port, username, password and use_tls. Those are very
SMTP-specific, but only username and password are used by the
mail.send_mail* APIs. It would be an agreement to allow username and
password in addition to fail_silently to not break the send_mail* API.
The SMTP backend could accept host, port and use_tls as extra keywords
again to provide backward compatibility for code that directly uses
SMTPConnection (within Django SMTPConnection is not used outside
django.core.mail). I would suggest to rename SMTPConnection to
SMTPBackend, but only if this would break too much third-party code as
SMTPConnection is mentioned in the docs.

The test utils could be refactored to use a TestMailBackend instead of
monkey-patching the mail module, but this would be a fairly invisible
change as it would just change the way how the test utils provide the
mailbox attribute in the mail module for unittests.

A nice addition to Django would be to include parts of django-mailer
to provide a backend for asynchronous mail delivery. That could be the
models and command line script to deliver mails. While thinking about
this, django-mailer has a nice option for setting priorities to mails.
IMO Django's API for sending mails should be as simple as possible
(like it is today), but a priority option would be a nice addition
even if the SMTP backend (as the default) wouldn't respect this option
when sending mails.

Adding a App Engine backend is not covered here. I think it's up to
third-party code to add support for sending mails on App Engine.
However, such a backend would be pretty easy to implement.

It would be nice to get some feedback on this suggestions and in a
first step to find a design decision about #10355. Even if the
decision is to not change anything for good reasons :)


Regards,

Andi

--~--~-~--~~~---~--~~
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: 1.2 Proposal: Add a few more tutorial steps

[Rob Hudson]

On Thu, Aug 20, 2009 at 1:03 PM, Nicolas Steinmetz wrote:
> Maybe you can inspire from the Jobeet [1] tutorial which consists at the
> beginning as an advent calendar (a one hour tutorial published
> everyday). Jobeet is a Job board and allow to deal with all aspects of
> Symfony framework from framework installation to deployment.
>
> Building a job board as a *real* app is I think more interesting than a
> basic poll app that nobody will use or do not look like a real app.

I very much agree with this and would be on board to help.  Using a
full website as a tutorial allows for explanation of topics you might
not get in a simple example tutorial — things like deployment,
caching, tests, data/schema migration as models evolve (though not
currently part of Django), feeds, internationalization, etc.

I don't know that I'd necessarily copy what Jobeet has done, but
perhaps something that's already being used in the Django community,
is open source, and could be improved a bit.  Something like
DjangoSnippets perhaps?

-Rob

--~--~-~--~~~---~--~~
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: 1.2 Proposal: Add a few more tutorial steps

[Nicolas Steinmetz]

Rob Hudson a écrit :

> I'd be happy to help flesh out one or more of these.  This isn't
> necessarily a 1.2 feature but would be a nice addition to the
> documentation.
> 
> If someone already had an idea on these wanted to add some more
> details of what to cover under one of those topics, I (and others?)
> can try to flesh one out during the 1.2 phase.

Maybe you can inspire from the Jobeet [1] tutorial which consists at the 
beginning as an advent calendar (a one hour tutorial published 
everyday). Jobeet is a Job board and allow to deal with all aspects of 
Symfony framework from framework installation to deployment.

Building a job board as a *real* app is I think more interesting than a 
basic poll app that nobody will use or do not look like a real app.

You could have then a "One hour overview of django" == Poll app and a 
deep overview of django" == Jobeet like app.

Nicolas

[1] http://www.symfony-project.org/jobeet/1_2/Doctrine/en/


--~--~-~--~~~---~--~~
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: add static_fields to ModelAdmin

[Dj Gilcrease]

Now that 1.1 is out and proposals for 1.2 are being submitted I
decided I would revive this proposal for comments

--~--~-~--~~~---~--~~
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: Suggestion: Better way to extend user table

[Jonas Obrist]

Rob Hudson wrote:
> Take a look at ticket 3011:
> http://code.djangoproject.com/ticket/3011
>
>   

Thanks a lot! That's pretty much exactly what I want. In my opinion this 
should become a real feature and not just a patch.

--~--~-~--~~~---~--~~
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: Suggestion: Better way to extend user table

[Waylan Limberg]

On Thu, Aug 20, 2009 at 9:22 AM, Rob Hudson wrote:
>
> Take a look at ticket 3011:
> http://code.djangoproject.com/ticket/3011
>

I don't know, but that seems a little too "magic" for me. The User
model appears to be imported from somewhere else than it actually is.
Isn't this what the core devs don't want to do?

Anyway, you do realize there is already a set precedence in Django for
how to do this sort of thing. See custom comments [1] and get_model().
It seems more likely something like that would actually get in.

[1]: 
http://docs.djangoproject.com/en/dev/ref/contrib/comments/custom/#django.contrib.comments.get_model

-- 

\X/ /-\ `/ |_ /-\ |\|
Waylan Limberg

--~--~-~--~~~---~--~~
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: Suggestion: Better way to extend user table

[Rob Hudson]

Take a look at ticket 3011:
http://code.djangoproject.com/ticket/3011

--~--~-~--~~~---~--~~
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: Inline formsets

[Russell Keith-Magee]

On Sun, Aug 16, 2009 at 5:45 AM, mrts wrote:
>
> At HTML level, a form is a set of fields that gets submitted when
> a the form submit button is pressed.
>
> However, this is not the case with model forms and inline formsets
> (e.g. an admin page with inlines) -- inline formsets are
> disparate from the model form.
>
> This creates at least two problems:
> 1) it's impossible to display inline formsets in between ordinary
> form fields (although they may logically belong to a particular
> fieldset and not to the end of the form),

This is only true if you consider {{ form }} to be the only way to
render a form. Remember - you can modify your template to render
individual fields on a form. If you're looking for sophisticated
layout options, you should be looking at customizing your template,
not trying to turn Django's Form.as_ul into the One True Form
Rendering Tool (tm).

> 2) it's impossible to create nested (recursive) inlines.

This is true, but not necessarily a bad thing. I'm willing to be
convinced otherwise, but I'm yet to see a case where nested inlines
would yield a positive user experience. Forms inside forms inside
forms is a recipe for  UI disaster.

Yours,
Russ Magee %-)

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

Django Sites framework

[Vladimir Prudnikov]

I'm *not* using Sites framework ('django.contrib.admin' is not  
included in INSTALLED_APPS and SITE_ID is not defined), but there is  
an exception when I click on "View on website" link on the edit model  
page in admin interface.

Exception Value: You're using the Django "sites framework" without  
having set the SITE_ID setting. Create a site in your database and set  
the SITE_ID setting to fix this error.

There is no check that Sites framework is really used.

--~--~-~--~~~---~--~~
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: Django 1.2 proposal: revisit admin autodiscover improvement for custom sites

[Russell Keith-Magee]

On Thu, Aug 20, 2009 at 8:36 AM, Brian Rosner wrote:
>
>
> On Aug 19, 2009, at 3:32 PM, Manuel Saelices wrote:
>
>> This ticket was marked by duplicate of #8500, but I think #8572
>> approach is better (better explicit than implicit). Ticket number is
>> not important, but I think that functionality is easy to implement
>> (with several strategies) and has no colateral effects, being
>> backwards compatible.
>
> I am in agreement the approach in #8572 is best. This has something
> that has bitten me on a few occasions and would like to get this fixed
> in Django. If you are fired up about getting this in I would recommend
> including documentation and tests and attaching it to #8500.
>
> Of course I welcome the thoughts of others too.

#8572 looks like a much better approach to me. I also agree that this
is a problem worth addressing - anything that allows breaking the
dependency on a hardcoded default is almost always good in my book.

Yours,
Russ Magee %-)

--~--~-~--~~~---~--~~
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: Django 1.2 proposal: revisit admin autodiscover improvement for custom sites

[Manuel Saelices]

On 20 ago, 02:36, Brian Rosner  wrote:
> On Aug 19, 2009, at 3:32 PM, Manuel Saelices wrote:
>
> [...]
>
> I am in agreement the approach in #8572 is best. This has something  
> that has bitten me on a few occasions and would like to get this fixed  
> in Django. If you are fired up about getting this in I would recommend  
> including documentation and tests and attaching it to #8500.
>
> Of course I welcome the thoughts of others too.

Ok, I'll wait for others thoughts before doing anything :)

Thx!

>
> Brian Rosnerhttp://oebfare.comhttp://twitter.com/brosner
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---