Re: Ticket #7591: Authenticate By Email Support
On Wed, Jul 2, 2008 at 1:10 PM, Paul Kenjora <[EMAIL PROTECTED]> wrote: > So whats the best way to get involved in proving myself to the group? Are > there bugs I can pick up, code I can contribute? At the moment, all eyes are focused on getting Django 1.0 out the door in early September. The best way to help Django out at the moment is to help with that process by working on stuff that's scheduled for 1.0. Some linkage: * The roadmap: http://code.djangoproject.com/wiki/VersionOneRoadmap * Detailed feature list: http://code.djangoproject.com/wiki/VersionOneFeatures * Tickets organized by milestone http://code.djangoproject.com/roadmap (very incomplete) Thanks! Jacob --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: ManyToManyField in Admin list_display
Please send usage questions to django-users - this list is for the development of django itself. -- Collin Grady --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Ticket #7591: Authenticate By Email Support
Sounds good, I've been porting the patch since version 0.95 on my own personal blog, comments seem fairly positive. I've also been a contributing community member for over a year, as well as having implemented close to 12 sites in Django over the past year with a few million hits this year alone. So whats the best way to get involved in proving myself to the group? Are there bugs I can pick up, code I can contribute? Thanks, -Paul On Wed, Jul 2, 2008 at 11:56 AM, George Vilches <[EMAIL PROTECTED]> wrote: > > > On Jul 2, 2008, at 1:24 PM, Paul Kenjora wrote: > > > I understand the resistance but you've got demand, you've got a > > willing developer, and you've got a clean fix that significantly > > improves the adaptability of the framework. What better reason > > would you need? > > Someone who has a proven history of contributions and maintenance of > the core framework for a significant period of time. > > When you contribute an entire backend that goes into core, it will > have to be maintained forevermore. People severely underestimate the > need for this, and even Django has suffered a bit from this over its 3 > years of life (the signal framework had a period of time like this, > although it's getting more attention again). > > Providing the addition as a 3rd party framework allows the community > to vet your work and decide whether 1) it's worth inclusion, and 2) > that you have the stamina to maintain it in Django for a long while to > come. > > gav > > > > -- - Paul Kenjora - 602-214-7285 --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Ticket #7591: Authenticate By Email Support
On Wed, Jul 2, 2008 at 2:56 PM, George Vilches <[EMAIL PROTECTED]> wrote: > On Jul 2, 2008, at 1:24 PM, Paul Kenjora wrote: > >> I understand the resistance but you've got demand, you've got a >> willing developer, and you've got a clean fix that significantly >> improves the adaptability of the framework. What better reason >> would you need? > > Someone who has a proven history of contributions and maintenance of > the core framework for a significant period of time. > > > > Providing the addition as a 3rd party framework allows the community > to vet your work and decide whether 1) it's worth inclusion, and 2) > that you have the stamina to maintain it in Django for a long while to > come. I'll also add that appealing to the community is often a much better way to get feedback on improvements that can be made. My first contribution, signed cookies,[1] started as a patch in Trac, that ended up moving to its own application, at which point I got a much better response of people using it, finding bugs, suggesting enhancements, etc. My second, dbsettings,[2] started as its own project, then had the possibility of being included in trunk, so I immediately started making changes to satisfy the immediate onslaught of suggestions. As time went on, I came to regret that, as sitting back and riding the normal community support wave would've made for a much better, more usable application. I think the main issue is that when something's sitting in trunk, or even in Trac, there's something of a bureaucracy, whether real or perceived, where the core developers are the gatekeepers of all decisions. People are quick to identify bugs, but given how long some decisions can take in trunk, people are less likely to speak up about suggestions or improvements. On the other hand, third-party applications in general have a better track record for acknowledging and responding to feedback much more quickly, and by more people. This helps get everything refined and polished fairly quickly, and with a high level of quality. And, as has been said before, if you write a good application, support it well, make it consistent with how Django itself works, and help a lot of people with it, there's a good chance it could be considered for inclusion into Django itself later on. Certainly a much better chance than if you just throw it in a ticket and ask why it hasn't been committed yet, anyway. Jonathan Buchanan's django-tagging[3] is a prime example of this, and will probably be one of the first considered for django.contrib after Django 1.0 hits store shelves. It's already on the shortlist of applications that many developers install in every new environment they work with, and once Django itself settles down, it'll probably work its way in fairly quickly. Mind, though, that I'm not one of the people who makes those decisions, I've just been observing conversations for quite a while. -Gul [1] http://code.google.com/p/django-signedcookies/ [2] http://code.google.com/p/django-values/ [3] http://code.google.com/p/django-tagging/ --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: GIS: support for Points (markers) in Google Maps
> I could clean this up as a patch to the GIS branch, but there seems to > be some confusion as to whether such functionality should be in the > core product. > > What is the right way forward here? > File a ticket with your patch -- I'm +1 because it doesn't make sense to support GPolygon and GPolyline but not GMarker (I haven't had time to implement myself yet). For the record, I think the confusion is localized to the extent we should have an OpenLayers API; it has so much functionality it may be counter-productive to try and box users into an extremely small subset of its features. -Justin --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
ManyToManyField in Admin list_display
Hi,
right now I'm working on one model and it looks like this
class Area(models.Model):
region = models.CharField(max_length = 2, choices =
SLOVAK_REGION_CHOICES,
radio_admin = True, db_index = True, blank = True, null = True)
city = models.CharField(max_length = 4, choices =
SLOVAK_DISTRICT_CHOICES,
db_index = True)
def __str__(self):
return '%s:' '%s' %(self.region, self.city)
class Admin:
list_display = ('region', 'city')
class JobOffer(ATag):
created = models.DateTimeField(_('created'), default =
datetime.datetime.now)
changed = models.DateTimeField(_('changed'), default =
datetime.datetime.now)
name = models.CharField(_('name'), max_length=80, core = True)
company = models.ForeignKey(Company)
loc = models.ManyToManyField(Area)
...
And I wanna display field "loc" in Admin's list_display, but that's
impossible because it's ManyToManyField and only way to do that is to write
down proper method...and that's the problem. Just can't figure it out :(
Can anybody please help me?
Thanks a lot!!!
--
View this message in context:
http://www.nabble.com/ManyToManyField-in-Admin-list_display-tp18241702p18241702.html
Sent from the django-developers mailing list archive at Nabble.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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
GIS: support for Points (markers) in Google Maps
The Google maps creation facility in the GIS branch does not support the display of points (only polylines and polygons). I have a working version that supports points and displays them as GMarkers on the map, which is in IMHO just a straightforward extension of the existing model to points. There is a running version of this in the little map in the right panel at http://www.yunnanexplorer.com/festivals/ (In overlays.py a GMarker class is added with functionality similar to the existing geometries and the GoogleMap class just takes an additional points parameter. The google-map.js has then an additional loop to display the markers. I have furthermore an extension that supports events together with markers (like click)). I could clean this up as a patch to the GIS branch, but there seems to be some confusion as to whether such functionality should be in the core product. What is the right way forward here? Ludwig --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Ticket #7591: Authenticate By Email Support
On Jul 2, 2008, at 1:24 PM, Paul Kenjora wrote: > I understand the resistance but you've got demand, you've got a > willing developer, and you've got a clean fix that significantly > improves the adaptability of the framework. What better reason > would you need? Someone who has a proven history of contributions and maintenance of the core framework for a significant period of time. When you contribute an entire backend that goes into core, it will have to be maintained forevermore. People severely underestimate the need for this, and even Django has suffered a bit from this over its 3 years of life (the signal framework had a period of time like this, although it's getting more attention again). Providing the addition as a 3rd party framework allows the community to vet your work and decide whether 1) it's worth inclusion, and 2) that you have the stamina to maintain it in Django for a long while to come. gav --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Newforms Admin - Overriding the Save Method of a ModelForm
Thanks Brian, Reposted: http://groups.google.com/group/django-users/t/2ccf2bb1dc06058e On Jul 2, 8:47 am, Brian Rosner <[EMAIL PROTECTED]> wrote: > On Jul 2, 2008, at 9:08 AM, John Boxall wrote: > > > > > But in NFA - it seems the save method isn't called! > > It works for me. If the print statement is not working then see about > tracking it down and post a detailed ticket with what is happening. > Also you will want to make sure you are returning the value from the > super call. The parent save method will return an instance that is > needed else where in the newforms-admin views. > > A quick side note, it is best to ask these question on the django- > users mailing list. django-developers is meant for the development of > Django. > > Brian Rosnerhttp://oebfare.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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Ticket #7591: Authenticate By Email Support
On Wed, Jul 2, 2008 at 1:24 PM, Paul Kenjora <[EMAIL PROTECTED]> wrote: > Reasons why an alternate backend or view is not good: > 3. Maintaining my own back end, means others are doing the same, again poor > re-use. Not if you: 1. Write it well 2. Distribute it freely 3. Make its presence known You'll find people in the Django world are quite happy to use third-party applications. -Gul --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Ticket #7591: Authenticate By Email Support
Right, but it makes me think that if this has come up before its not a minor feature request. The fact that huge numbers of well known sites are using email based authentication suggests its time for the 4 lines of code to be added to contrib/auth. Files in contrib are not written in stone. I still have not heard a good enough reason not to add the code. Reasons why an alternate backend or view is not good: 1. Doing it in a view would bypass the auth system entirely, bad use of framework, poor re-use. 2. Adding a back end would introduce lots of code maintenance on the trunk, not optimal insertion point. 3. Maintaining my own back end, means others are doing the same, again poor re-use. Reasons why it is good: 1. Proven demand for feature (see previous tickets and threads). 2. No risk to existing functionality. 3. Very little additional code to maintain/debug. 4. Intuitive place to put this functionality is authentication. 5. Function is called authenticate, not authenticate_by_username_only. I understand the resistance but you've got demand, you've got a willing developer, and you've got a clean fix that significantly improves the adaptability of the framework. What better reason would you need? -Paul On Wed, Jul 2, 2008 at 9:30 AM, Waylan Limberg <[EMAIL PROTECTED]> wrote: > > Paul, > > I believe this issue has been brought up in various ways before. I'd > suggest searching the list archives and old closed tickets. You'll > likely find your answer there. > > More generally, there is already a mechanism in place to override the > default behavior and implement your own (building your own auth > backend), so I suspect the core devs would prefer that you do that > rather than build everyones minor feature request into the core. > Actually, I believe there are at least a few existing solutions out > there. A search should turn up a few gems for you. > > On Wed, Jul 2, 2008 at 11:48 AM, Paul Kenjora <[EMAIL PROTECTED]> wrote: > > I've been using Django for a while and recently started contributing to > the > > trunk. Previously I ran my own branch but sooner or later that gets > > tiresome. So I created a ticket the other day: > > > > http://code.djangoproject.com/ticket/7591 > > > > The ticket suggests a patch to contrib/auth that will allow authenticate > by > > email as well as username. The idea was shot down rather quickly without > > any particularly good reason. In order for me to continue contributing > to > > the trunk I'd like to get in line with the thought processes on Django > > development. Could someone here please elaborate on why ticket 7591 is a > > bad idea? Or better yet why its a worse idea than other approaches? > > > > > > Thanks, > > -- > > - Paul > > > > > > > > > > > -- > > Waylan Limberg > [EMAIL PROTECTED] > > > > -- - Paul Kenjora - 602-214-7285 --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Ticket #7591: Authenticate By Email Support
Paul, I believe this issue has been brought up in various ways before. I'd suggest searching the list archives and old closed tickets. You'll likely find your answer there. More generally, there is already a mechanism in place to override the default behavior and implement your own (building your own auth backend), so I suspect the core devs would prefer that you do that rather than build everyones minor feature request into the core. Actually, I believe there are at least a few existing solutions out there. A search should turn up a few gems for you. On Wed, Jul 2, 2008 at 11:48 AM, Paul Kenjora <[EMAIL PROTECTED]> wrote: > I've been using Django for a while and recently started contributing to the > trunk. Previously I ran my own branch but sooner or later that gets > tiresome. So I created a ticket the other day: > > http://code.djangoproject.com/ticket/7591 > > The ticket suggests a patch to contrib/auth that will allow authenticate by > email as well as username. The idea was shot down rather quickly without > any particularly good reason. In order for me to continue contributing to > the trunk I'd like to get in line with the thought processes on Django > development. Could someone here please elaborate on why ticket 7591 is a > bad idea? Or better yet why its a worse idea than other approaches? > > > Thanks, > -- > - Paul > > > > -- Waylan Limberg [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Ticket #7591: Authenticate By Email Support
On Jul 2, 8:48 am, "Paul Kenjora" <[EMAIL PROTECTED]> wrote: > I've been using Django for a while and recently started contributing to the > trunk. Previously I ran my own branch but sooner or later that gets > tiresome. So I created a ticket the other day: > > http://code.djangoproject.com/ticket/7591 > > The ticket suggests a patch to contrib/auth that will allow authenticate by > email as well as username. The idea was shot down rather quickly without > any particularly good reason. In order for me to continue contributing to > the trunk I'd like to get in line with the thought processes on Django > development. Could someone here please elaborate on why ticket 7591 is a > bad idea? Or better yet why its a worse idea than other approaches? It's almost absurdly easy to write your own authentication backend including one that supports authentication through email addresses. See [1] and [2]. The particular axe that I'm grinding lately is for Ticket 3011 [3], which would allow for a pluggable user model. Perhaps that's more what you're looking for? [1] http://www.djangosnippets.org/snippets/74/ [2] http://www.djangoproject.com/documentation/authentication/#other-authentication-sources [3] 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Ticket #7591: Authenticate By Email Support
I've been using Django for a while and recently started contributing to the trunk. Previously I ran my own branch but sooner or later that gets tiresome. So I created a ticket the other day: http://code.djangoproject.com/ticket/7591 The ticket suggests a patch to contrib/auth that will allow authenticate by email as well as username. The idea was shot down rather quickly without any particularly good reason. In order for me to continue contributing to the trunk I'd like to get in line with the thought processes on Django development. Could someone here please elaborate on why ticket 7591 is a bad idea? Or better yet why its a worse idea than other approaches? Thanks, -- - Paul --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Newforms Admin - Overriding the Save Method of a ModelForm
On Jul 2, 2008, at 9:08 AM, John Boxall wrote: > > But in NFA - it seems the save method isn't called! > It works for me. If the print statement is not working then see about tracking it down and post a detailed ticket with what is happening. Also you will want to make sure you are returning the value from the super call. The parent save method will return an instance that is needed else where in the newforms-admin views. A quick side note, it is best to ask these question on the django- users mailing list. django-developers is meant for the development of Django. Brian Rosner http://oebfare.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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Community representation
On Wed, Jul 2, 2008 at 7:17 AM, Arien <[EMAIL PROTECTED]> wrote: > > Can we get back to our regular program now and move personal problems > to private communication, please? Thank you. Insofar as referencing particular individuals goes, I agree. I should have raised any issues with particular community members in private, and I ask that others do the same. That said — I do think it would be nice to outline just exactly what is, and isn't, over the line for *anyone*; if we have a yardstick, we can measure, as opposed to this vague "I know it when I see it" pornography-like property of rudeness that everyone seems to disagree on. I honestly don't know if this is the right mailing list for such a discussion; it's certainly not "development of django", but a case might be made that it's "development of the community". I *do* want to have that discussion, however; I'd just like to know where to have it before continuing. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Spam detection
On Wed, Jul 2, 2008 at 10:47 AM, Steve Holden <[EMAIL PROTECTED]> wrote: > Rob van der Linde wrote: > > I see there is now a link to the registration page when you go to file a > > ticket, but why not put it on page where the login/settings links are > > (just underneath the search box). This is where it is by default in Trac > > and people might expect to see it there, like I did myself initially. > > ... and why not have it say "Your post *will* be rejected as spam unless > you are registered and logged in"? At the moment it sounds like you > *might* get away with an unregistered posting. > > Because it is not true that you *will* be rejected by the spam filter if you are not registered. There are still plenty of anonymous updates to trac. I don't know what fraction of anonymous postings are rejected as spam, but it is not 100% Karen --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Newforms Admin - Overriding the Save Method of a ModelForm
Hey Marc - that's what I thought! But in NFA - it seems the save method isn't called! For instance: class ModelUserAdmin(admin.ModelAdmin): form = ModelUserForm ... class ModelUserForm(forms.ModelForm): def clean(self): # This method will successfully be called from the add_view or change_view # of NFA print 'ModelUserForm >>> clean()' super(ModelUserForm, self).clean() def save(self, commit=True): # This method -WILL NOT- be called from the add_view or change_view # of NFA - but I would like it to be! print 'ModelUserForm >>> save()' super(ModelUserForm, self).save(commit) On Jul 2, 3:50 am, Marc Garcia <[EMAIL PROTECTED]> wrote: > Sure, > > just remember to return > > super(YourModelForm, self).save(commit) > > in it. > > On Jul 2, 9:10 am, John Boxall <[EMAIL PROTECTED]> wrote: > > > Hi everyone! > > > I'm just trying out newforms admin - it's fantastic. I can't wait > > until this makes it's way into trunk - > > > A question - > > I'd like to add custom behavior when a object is saved in the admin > > console. > > > I'm following this example of how to add custom behaviour to validate > > an > > object:http://code.djangoproject.com/wiki/NewformsHOWTO#Q:HowdoIaddcustomval... > > > I would expect to be able to add a save() method to my ModelForm and > > have it be called when I hit save... how ever this does not seem to be > > the case! > > > Has anyone had any luck overriding the save method of a model form in > > NFA? > > > Cheers, > > > John --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Community representation, or, #django user "Magus-" needs to go far away
Eric wrote: > Well, you can teach someone to fish without telling them to "get an > f'n fishing pole". > > "Give a man a fish and he will eat for a day. Teach him how to fish and for the rest of his life he will bore you with stories about the one that got away". regards Steve --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Spam detection
Rob van der Linde wrote: > I see there is now a link to the registration page when you go to file a > ticket, but why not put it on page where the login/settings links are > (just underneath the search box). This is where it is by default in Trac > and people might expect to see it there, like I did myself initially. ... and why not have it say "Your post *will* be rejected as spam unless you are registered and logged in"? At the moment it sounds like you *might* get away with an unregistered posting. regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: MS SQL pyodbc backend update to trunk
On Wed, Jul 2, 2008 at 9:48 PM, vcc <[EMAIL PROTECTED]> wrote: > I port MS SQL pyodbc backend (django-pyodbc) to newforms-admin r7671, tested > on ubuntu 8.04 and with SQL Server 2005. > I found sql server need convert boolean value to integer (BooleanField), so > need add a new feature like 'needs_bool_to_integer' to DatabaseFeatures, > deafult to False. > > Since this MS SQL backend work both on Linux and Windows, so we may consider > have MS SQL backend back in Django internal. > > Please see patch in attachment. Please see the many, many threads about MS-SQL support which discuss at length Django's policy on adding new database backends. We have repeatedly said that we will only consider a database backend for inclusion in trunk when there is a demonstrated long term commitment to supporting the patch. 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
MS SQL pyodbc backend update to trunk
I port MS SQL pyodbc backend (django-pyodbc) to newforms-admin r7671, tested on ubuntu 8.04 and with SQL Server 2005. I found sql server need convert boolean value to integer (BooleanField), so need add a new feature like 'needs_bool_to_integer' to DatabaseFeatures, deafult to False. Since this MS SQL backend work both on Linux and Windows, so we may consider have MS SQL backend back in Django internal. Please see patch in attachment. Best regards, Wei Guangjing _ --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~--- django-pyodbc-r7671.patch Description: Binary data
Re: Community representation
Can we get back to our regular program now and move personal problems to private communication, please? Thank you. Arien --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Community representation
The guy is rude. I never go in the IRC channel to help because he's there being an ass. The reason why I fell in love with Django way back in 2005 was because of the community in #django and I'm worried that he's stunting adoption because he's turned the channel into #linux. E. On Jul 2, 7:41 am, Steve Holden <[EMAIL PROTECTED]> wrote: > Russell Keith-Magee wrote: > > On Tue, Jul 1, 2008 at 5:25 PM, Kenneth Gonsalves > > <[EMAIL PROTECTED]> wrote: > >> Let him be as rude as he wants, as long as he is there. > > > Lets stop this idea before it grows legs. One of the strengths of > > Django is the community, and one of the reasons the community is > > strong is because it is approachable for newcomers. > > > There's no problem with being blunt or brusque, but straight out > > rudeness is not appropriate, and it will not be tolerated. > > In which case perhaps a change of subject line might be appropriate? > > I would say that Magus *is* blunt or brusque rather than rude. His > approach isn't always appreciated because he won't "spoon-feed" people, > preferring instead to lead them by the hand (or, occasionally, a rather > more tender body part). But that's going to make for a more capable > community in the end, and is better from a learning point of view. > > Besides which, sometimes it's amusing to watch the conversations. We are > a long way from the c.l.perl flaming of newbies. People are definitely > getting the answers they need, and Magus is a prime distributor of > high-quality information to the IRC channel. > > regards > Steve > -- > Steve Holden +1 571 484 6266 +1 800 494 3119 > Holden Web LLC http://www.holdenweb.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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Some ideas about AUTH_PROFILE_MODULE (tickets: #7584, #7592 and #7400)
May be better way to use ``OneToOneField`` with proper ``related_name`` like "profile" for example. Than profile can be accessed very simple ``user.pofile``. and its creation machinery leave to profile app author? On Jul 2, 12:38 pm, David Danier <[EMAIL PROTECTED]> wrote: > This basically started as a ticket suggesting adding some way to create > a default profile for users which don't have one, moving the need to > catch DoesNotExist-exceptions out of the applications using get_profile(). > ->http://code.djangoproject.com/ticket/7584 > > julien did suggest some alternatives, which all bring some drawbacks > with them and finally closed the ticket, as #7592 got closed, too. After > some discussion he suggested bringing the topic up here. > > My current idea is to add the possibility to provide a > get_for_user()-method in the profile manager, this would fix #7584, > #7592 and even #7400...and would possible add room for more ideas, hence > make the whole get_profile()-stuff more flexible. > Patch:http://code.djangoproject.com/attachment/ticket/7584/django-profile-m... > > So, about the alternatives: > > 1. Use signals (#7584, comment:1) > Might work, but does not support on demand creation of profiles for > legacy-users. There may be more use-cases where post_save is not enough. > Still need to catch the exception, as you can't guarantee the existence > of a profile. > > 2. Importing AUTH_PROFILE_MODULE yourself (#7592) > Not really possible, think about templates for example. Even if only > needed in views this duplicates code. > > 3. Own profile-module with appropriate manager (#7584, comment:3) > Like importing AUTH_PROFILE_MODULE yourself, but with cleaner code. > Still no easy support in templates. Does not work if application needs > to be reusable (on some other website with different profiles). > > 4. Overwrite get() on profile-manager (#7584, comment:4) > Possible, but seems rather hackish. Additionally nothing someone new to > django might do or want to do. > > So is there any reason not to support creating profiles on demand? The > patch is only three new lines and should not cause any trouble I think. > Of course docs are missing so far. > > Greetings, David Danier --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Community representation
Russell Keith-Magee wrote: > On Tue, Jul 1, 2008 at 5:25 PM, Kenneth Gonsalves > <[EMAIL PROTECTED]> wrote: >> Let him be as rude as he wants, as long as he is there. > > Lets stop this idea before it grows legs. One of the strengths of > Django is the community, and one of the reasons the community is > strong is because it is approachable for newcomers. > > There's no problem with being blunt or brusque, but straight out > rudeness is not appropriate, and it will not be tolerated. > In which case perhaps a change of subject line might be appropriate? I would say that Magus *is* blunt or brusque rather than rude. His approach isn't always appreciated because he won't "spoon-feed" people, preferring instead to lead them by the hand (or, occasionally, a rather more tender body part). But that's going to make for a more capable community in the end, and is better from a learning point of view. Besides which, sometimes it's amusing to watch the conversations. We are a long way from the c.l.perl flaming of newbies. People are definitely getting the answers they need, and Magus is a prime distributor of high-quality information to the IRC channel. regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Community representation, or, #django user "Magus-" needs to go far away
On Tue, Jul 1, 2008 at 5:25 PM, Kenneth Gonsalves <[EMAIL PROTECTED]> wrote: > >Let him be as rude as he wants, as long as he is there. Lets stop this idea before it grows legs. One of the strengths of Django is the community, and one of the reasons the community is strong is because it is approachable for newcomers. There's no problem with being blunt or brusque, but straight out rudeness is not appropriate, and it will not be tolerated. 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Community representation, or, #django user "Magus-" needs to go far away
On Wed, Jul 2, 2008 at 12:55 AM, Kenneth Gonsalves <[EMAIL PROTECTED]> wrote: > actually this debate belongs on django-users (which is why I put in > my 2 paise) - I think if taken there we can get a real measure of the > pros of his help against the cons of his curtness at times (I > wouldn't call it being rude) Or we could all just stop trying to deal publicly with what should be a private issue. -Gul --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Newforms Admin - Overriding the Save Method of a ModelForm
Sure, just remember to return super(YourModelForm, self).save(commit) in it. On Jul 2, 9:10 am, John Boxall <[EMAIL PROTECTED]> wrote: > Hi everyone! > > I'm just trying out newforms admin - it's fantastic. I can't wait > until this makes it's way into trunk - > > A question - > I'd like to add custom behavior when a object is saved in the admin > console. > > I'm following this example of how to add custom behaviour to validate > an > object:http://code.djangoproject.com/wiki/NewformsHOWTO#Q:HowdoIaddcustomval... > > I would expect to be able to add a save() method to my ModelForm and > have it be called when I hit save... how ever this does not seem to be > the case! > > Has anyone had any luck overriding the save method of a model form in > NFA? > > Cheers, > > John --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: FormWizard - GETs on all but last step?
On Tue, Jul 1, 2008 at 9:00 PM, Waylan Limberg <[EMAIL PROTECTED]> wrote: > > On Tue, Jul 1, 2008 at 8:28 PM, Arien <[EMAIL PROTECTED]> wrote: >> >> On Tue, Jul 1, 2008 at 6:10 PM, Waylan Limberg <[EMAIL PROTECTED]> wrote: >>> >>> On Tue, Jul 1, 2008 at 5:59 PM, David Durham, Jr. >>> <[EMAIL PROTECTED]> wrote: Nice thing about GETs is that users aren't confronted with the dreaded "Data was submitted with POST" confirmation, which is confusing to most people and usually not tested. Basically you end up breaking the back button and the reload button. >>> >>> Um, this is intentional and a good thing. If you read the spec, not >>> only is the difference between GET and POST defined, but the way user >>> agents (browsers) should treat them is defined as well. Breaking the >>> back & reload buttons is a requirement of the spec to, among other >>> reasons, avoid multiple posts by impatient (or double-clicking) users. >>> Granted, browsers could provide more helpful messages, but we want >>> that behavior for POSTing data. >> >> What specification requires this? >> > A number of them actually. To name a few: > > http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9 > http://www.w3.org/TR/REC-html40/interact/forms.html#h-17.13 > http://www.w3.org/2001/tag/doc/whenToUseGet.html > > A decent summary of the issues are found here: > http://www.cs.tut.fi/~jkorpela/forms/methods.html Oh, right, now I see what you (and David Durham) are getting at when you say "breaking the back and reload buttons". It's this part of the HTTP spec: 9.1.1 Safe Methods [...] In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered "safe". This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested. I'll try and read more carefully next time. :-) Arien --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Some ideas about AUTH_PROFILE_MODULE (tickets: #7584, #7592 and #7400)
This basically started as a ticket suggesting adding some way to create a default profile for users which don't have one, moving the need to catch DoesNotExist-exceptions out of the applications using get_profile(). -> http://code.djangoproject.com/ticket/7584 julien did suggest some alternatives, which all bring some drawbacks with them and finally closed the ticket, as #7592 got closed, too. After some discussion he suggested bringing the topic up here. My current idea is to add the possibility to provide a get_for_user()-method in the profile manager, this would fix #7584, #7592 and even #7400...and would possible add room for more ideas, hence make the whole get_profile()-stuff more flexible. Patch: http://code.djangoproject.com/attachment/ticket/7584/django-profile-manager.patch So, about the alternatives: 1. Use signals (#7584, comment:1) Might work, but does not support on demand creation of profiles for legacy-users. There may be more use-cases where post_save is not enough. Still need to catch the exception, as you can't guarantee the existence of a profile. 2. Importing AUTH_PROFILE_MODULE yourself (#7592) Not really possible, think about templates for example. Even if only needed in views this duplicates code. 3. Own profile-module with appropriate manager (#7584, comment:3) Like importing AUTH_PROFILE_MODULE yourself, but with cleaner code. Still no easy support in templates. Does not work if application needs to be reusable (on some other website with different profiles). 4. Overwrite get() on profile-manager (#7584, comment:4) Possible, but seems rather hackish. Additionally nothing someone new to django might do or want to do. So is there any reason not to support creating profiles on demand? The patch is only three new lines and should not cause any trouble I think. Of course docs are missing so far. Greetings, David Danier --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Newforms Admin - Overriding the Save Method of a ModelForm
Hi everyone! I'm just trying out newforms admin - it's fantastic. I can't wait until this makes it's way into trunk - A question - I'd like to add custom behavior when a object is saved in the admin console. I'm following this example of how to add custom behaviour to validate an object: http://code.djangoproject.com/wiki/NewformsHOWTO#Q:HowdoIaddcustomvalidation I would expect to be able to add a save() method to my ModelForm and have it be called when I hit save... how ever this does not seem to be the case! Has anyone had any luck overriding the save method of a model form in NFA? Cheers, John --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Paginator vs. QuerySetPaginator
Hi, On Wed, 02 Jul 2008 05:55:26 +0200, Gary Wilson Jr. <[EMAIL PROTECTED]> wrote: > Jeremy Dunck wrote: [Pagintor problems] >> Is there some other way we can point the gun away from our foot? > > I, for one, would be in favor of doing away with QueryPaginator and > bringing back the behaviour of the _get_count() method of the lecacy > ObjectPaginator: > > def _get_count(self): > # The old API allowed for self.object_list to be either a QuerySet > or a > # list. Here, we handle both. > if self._count is None: > try: > self._count = self.object_list.count() > except TypeError: > self._count = len(self.object_list) > return self._count > count = property(_get_count) > > The legacy _get_count first tries to do object_list.count() with no > arguments. That raises a TypeError if object_list is a list, since > list.count() requires an argument. If the TypeError is raised, then > _get_count falls back to using len(object_list). > > Seems like this is a nice interface, either have your object_list > provide a count() method or rely on len(object_list). I believe this > sort of duck typing would be better than an explicit type check. > > Then, we would have no dangers when passing a QuerySet, no confusion as > to which Paginator class to use, and the ability to accept any other > "object_list" instance that has a count() method or can have len() > called on it. > There is an open ticket for this: http://code.djangoproject.com/ticket/7478 If the consens is that this should go in (I'm not sure who mrts is), I could create a patch for this. The docs probably need updating too. Regards adi --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
