Re: Tickets on send_mass_mail functionality (multipart/encoding/TLS/BCC)

Simon G. wrote: > #3307 - Add BCC to mail framework. > I've renamed this ticket from what it used to be. This originally had > two issues - one which overlapped with #1541, and the other this BCC > request. There's a patch here with adds a parameter to send_mass_mail > to suppress the recipi

Re: specifying newforms-admin options

Max Battcher wrote: > The problem with that is that there is a good amount of description > per model (list_display, et al in the current inner class) that I > would hate to have to move to other files because I think it mentally > makes sense to keep with the model because: a) It's "meta-informat

Re: specifying newforms-admin options

Max Battcher / WorldMaker wrote: >>ADMIN_FIND_ADMIN_CLASSES = True >>ADMIN_MODELS = ( >>'myproj.myapp.admin.PollAdmin', >>'someotherproj.someapp.admin.FooAdmin', >>) > > [...] Let me throw in another option: maybe > it's time to return to Meta? [...] For instance:: > > class Meta: >

Re: specifying newforms-admin options

Adrian Holovaty wrote: > But the bigger question is, should the "class Admin" even live in the > model at all, given that it's gaining many more hooks, not all of > which are simple data structures. With each hook I add, it feels more > and more messy to have that functionality within the model. O

Re: django.contrib.formtools: High-level abstractions of common form tasks

Adrian Holovaty wrote: > What other sorts of things can we make abstractions for, > given a Form? Wizards, maybe? Given a series of forms, run through them all appending data from previous forms to next ones, or processing each in turn. Maybe an option to have it do either, so you can process

Re: Default representation of a Form

Lakin Wecker wrote: > as_dl() gets a +1 from me. I've used definition lists for forms and > prefer it over tables. :) Maybe there needs to be an easy hook for people to specify their own way of laying a form out. It seems the as_ methods are gonna keep growing and growing. -- Lach Personal: h

Re: Yet another proposal for urlconf: use urls.py! (Was: Think about urlconf again)

Guys, I think maybe we're thinking about resolving urls the wrong way. We have urls.py already, which maps urls -> views. Most of the proposals so far for getting urls back seem to have revolved around getting a url for a model -- I think this is looking at the situation the wrong way. We're no

Re: Any other Australian Django heads?

Melbourne 'Djypsy' here. -- Lach http://illuminosity.net/

Re: Django Ajax Redux

Using classes it's not clear if it's there to style an element or to pass params to some js widget or whatever. When using custom attrs it's much clearer what's going on. I couldn't disagree more. :) class is there to 'subclass' elements. The W3C themselves say

Re: Removing the magic

Jacob Kaplan-Moss wrote: * Model definitions (with properties, etc): +1 * Database connections: -0 * Putting lookups under Person.objects: Not a fan of the aesthetic, but I can't think of anything better, and it looks like it'll work fine, so... +0 * Overwriting model methods