Re: django and LDAP support
Hi Scott, for sure I understand now why you need a second search on update_user() and with the defaults for mk_pre_auth_bind those two searches should be the same. A security question about get_ldap_user() def get_ldap_user(l, username): """ Helper method, makes a user object and call update_user to populate """ user = User(username=username, password='Made by LDAP') LDAPBackend.update_user(l, user) return user Is setting password to 'Made by LDAP' opening a backdoor ? If somebody accidently remove the LDAP-Support or uses both DB and LDAP, can this open a security hole ? I would prever to use a random choose password. Regards, Dirk -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Pagination
I'm starting to play with Django and liking it... One thing I was wondering, though, about the pagination object is why django/core/paginator.py doesn't have get_next_page and get_previous_page functions (to return the appropriate page numbers), although it does have has_next_page and has_previous page functions? Cheers, Mike Cantelon --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Pagination
On Sat, 2006-08-12 at 03:00 -0700, Mike Cantelon wrote: > I'm starting to play with Django and liking it... > > One thing I was wondering, though, about the pagination object is why > django/core/paginator.py doesn't have get_next_page and > get_previous_page functions (to return the appropriate page numbers), > although it does have has_next_page and has_previous page functions? I'm not sure those functions make sense in the current ObjectPaginator implementation. The thing is, that object doesn't even have a concept of "current page". Instead it's an object from which you can retrieve any individual page (random access) and get information about whether there would be a next or previous page for some particular page number. Regards, Malcolm --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Pagination
Malcolm Tredinnick wrote: > I'm not sure those functions make sense in the current ObjectPaginator > implementation. The thing is, that object doesn't even have a concept of > "current page". Instead it's an object from which you can retrieve any > individual page (random access) and get information about whether there > would be a next or previous page for some particular page number. Thanks Malcolm... Taking a further look at it, you're totally right. Cheers, Mike Cantelon --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
A model_object.is_saved() method
Hi Everyone, I'd like to propose a small change to django.db.models.Model to make it neater to determine whether or not a model object is already stored in the database. Either: Option 1: Rename the _get_pk_val() method to get_pk_val(), marking it safe for public use. Option 2: Add a method named is_saved() which checks the value of the primary key. Here's the situation that inspired the proposal. I'm in the midst of some code to push objects in and out of custom FormManipulators. At several points, the code needs to determine whether or not the model objects are stored in the database, in order to know whether the object should be deleted. Since my model classes don't explicitly define primary keys, this is fairly simple - it's just a matter of checking model_object.id. Since I was doing it several times, I made up a utility method, "is_saved(model_object)". I now have this kind of code: if is_saved(object): object.delete() However, that doesn't look right - model objects know whether or not they've been saved, and should be able to communicate that without requiring the programmer to know the primary key name. I would have used django.db.models.Model._get_pk_val() method, except for the leading underscore marking the method as being for private use. Hence the first option, at the top of this email. If exposing the primary key value like that would be undesirable, a more modest option would be a simple "is_saved()" method. Does either of these options sound reasonable? If so, I'm happy to make up a patch, including changes to db-api.txt. Alan. -- Alan Green [EMAIL PROTECTED] - http://bright-green.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 -~--~~~~--~~--~--~---
Re: Proposed solution to deleting contents of FileField
On 8/9/06, James Bennett <[EMAIL PROTECTED]> wrote: > This is certainly a long-standing wart in Django, and on first glance > I like this solution a little better than the patch on #22, but we > also have a Summer of Code student working on major enhancements to > the admin's media support[1]; since there are only a couple weeks left > to go in SoC, I'd advise holding off on comitting any solution until > we see his final results. Thanks, James -- I hadn't realised that one of the SoC coders was working around FileField and ImageField. The code that we have now was written as a workaround for the problem, rather than as a patch against django source, for just this reason. We don't want to tread on anyone else's work if we can help it -- it just makes for bigger maintenance headaches for us ;) Unfortunately, (for us, possibly,) with further testing, we've discovered a couple of problems with Django's handling of FileFields and ImageFields -- not strictly limited to admin, but in the way that fields tagged "core=True" are handled by manipulators. Because of this, I've created a ticket (#2534) with a patch that fixes the core field handling, and makes FileFields deletable. http://code.djangoproject.com/ticket/2534 Regards, Ian Clelland <[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 -~--~~~~--~~--~--~---
Re: translation of content
Kenneth Gonsalves wrote: > hi, > just a few random thoughts on translation of content. At first i was > leaning towards developing a dependant model for each model which > would hold translations. One thing i have realised is that of all the > field types, only three - CharField, TextField and numeric fields > would need to be translated. So was thinking, why not have a model like: > > EnglishString: > fieldtype - this is text/char/number > englishstring - the english string > > Translation: > englishstring - foreignkey to EnglishString > language - foreignkey to Languages > translation - actualtranslation > > and something to prompt a lookup to see if there is a translated > string available. But this is going to be slow. An alternative would > be to eliminate the 'EnglishString' model and have only one model > like so: > > Translation: > origmodel - foreignkey to a the modelname+model_id > +fieldnameof_stringtobetranslated > language - foreignkey to Languages > translation - actualtranslation > > a mechanism should be there to serve these strings to a tranlator for > translation and saving into the database. translation of numeric data > could be automated. This is very similar to the way gettext works. English is considered the default and translations follow. I would use this method if I were only translating the interface of a web application, but then again, gettext is already a very good solution to this problem. For content however, there are a couple of issues with this method: 1. There is a performance hit for non-English pages. 2. The content in the actual models is duplicated in the EnglishString table. 3. The EnglishString table is not very rectangular (having a one fits all field), the same thing goes for the translation table. Another problem here is that you cannot add non-English content without corresponding English content, which might not always be the case. What I would do is to simply use the sites framework to create per-language sites. This way, content of the different sites is essentially independent. Then, on top of that, you can have a system linking several objects togther as translations of the same thing. For example, you can have a weblog entry in the English site linked to one in the French site and one in the German site. Then, in templates of a certain language site, you would look for objects that are related to the current object in the translation tables and link to them through their get_absolute_url preceded by their site's address. Of course, as I said, it all depends on what you are trying to achieve. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: django and LDAP support
On Sat, Aug 12, 2006 at 10:09:28AM +0200, [EMAIL PROTECTED] wrote: > for sure I understand now why you need a second search on update_user() and > with the defaults for mk_pre_auth_bind those two searches should be the same. > > A security question about get_ldap_user() > > def get_ldap_user(l, username): > """ > Helper method, makes a user object and call update_user to populate > """ > > user = User(username=username, password='Made by LDAP') > LDAPBackend.update_user(l, user) > return user > > Is setting password to 'Made by LDAP' opening a backdoor ? > If somebody accidently remove the LDAP-Support or uses both DB and LDAP, can > this open a security hole ? > > I would prever to use a random choose password. > That is a good point, if you have both backends working, this would present a problem. I'll go ahead and have it generate a random password in there instead. Scott -- Scott Paul Robertson http://spr.mahonri5.net GnuPG FingerPrint: 09ab 64b5 edc0 903e 93ce edb9 3bcc f8fb dc5d 7601 pgpEw6dDODQuN.pgp Description: PGP signature
big picture of middelware
Hi all, I read the middelware documentation on http://www.djangoproject.com/documentation/middleware/ and try to get a big picture of understanding. I also looked into the django/core/handler/base code. 1. incoming request is processed by each Middleware.process_request until a middleware returns a response (jump to 5. if response). 2. request/view is now processed by Middleware.process_view until a middleware returns a response (jump to 5. if response). 3. the view is called and returns a response (jump to 5.) or throw an exception (jump to 4.). 4. an exception is precossed by each Middelware.process_exception until a middleware returns a reponse (jump to 5) or reraise the exception. 5. the response from 1./2./3./4. is now processed by each Middelware.process_response with response-input of the previos iteration. 6. outgoing response will be served. Are those steps correct ? Regards, Dirk -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: multiple authentication and session keys
On Thu, Aug 03, 2006 at 10:42:39PM -0700, Gary Wilson wrote: > > So, the mutli authentication seems to work well for the use case of a > site accepting more than one authentication source to access some area, > but not so well for the use case of a site accepting one source of > authentication in one area and another source of authentication in a > different area. > > The contrib.auth.login function currently writes the user's id to > session['_auth_user_id'] and the backend to > session['_auth_user_backend']. When using more than one authentication > backend, the session data gets stomped on. I propose that the session > data be keyed by backend somehow so that authentication session data is > kept separate. > > The login function would change to key the session data by backend. > The logout function would log the user out of all backends, or > optionally take in a backend to log the user out of only that > particular backend. The get_user function with no parameters would > return the first user object it finds calling backend.get_user() for > each backend in AUTHENTICATION_BACKENDS in order, or optionally take a > backend to try and get the user from. > You also run into a problem if you change the authentication backends and don't clear out your cookie. Django will fail trying to authenticate with a now non-existent backend. I can grab the traceback if it's needed. -- Scott Paul Robertson http://spr.mahonri5.net GnuPG FingerPrint: 09ab 64b5 edc0 903e 93ce edb9 3bcc f8fb dc5d 7601 pgph5rypM2Kb2.pgp Description: PGP signature
Re: A model_object.is_saved() method
On 8/12/06, Alan Green <[EMAIL PROTECTED]> wrote: > I would have used django.db.models.Model._get_pk_val() method, except > for the leading underscore marking the method as being for private > use. Hence the first option, at the top of this email. > > If exposing the primary key value like that would be undesirable, a > more modest option would be a simple "is_saved()" method. > > Does either of these options sound reasonable? If so, I'm happy to > make up a patch, including changes to db-api.txt. Hey Alan, This is an interesting feature request/idea. If we were to add a default method along the lines of is_saved(), I think it would make the most sense if that method actually *checked* the database rather than just checking that the primary-key value is set. But, if I understand correctly, that would be overkill for your situation, right? By the way, you're right not to use _get_pk_val(). Although I don't suspect that will change, there's no guarantee -- it should be considered off-limits (i.e., there's a reason it's undocumented). Adrian -- Adrian Holovaty holovaty.com | djangoproject.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 -~--~~~~--~~--~--~---
Re: django unicode-conversion, beginning
On 8/8/06, gabor <[EMAIL PROTECTED]> wrote: > i think unicodizing django can be done in 4 easily separated steps/parts: > > 1. request/response > 2. templating-system > 3. database-system > 4. "overall unicode-conversion". this is mostly about replacing > bytestrings with u"bla" in the code, and switching __str__ to __unicode__ > > my biggest problem currently is, that i do not know how to continue... > should i just write more and more patches to increase the > "unicode-coverage" to more parts of django? or maybe a more coordinated > approach would be better? Hey gabor, Sorry for the slow response on this -- I'm just now wading through a couple of weeks' worth of django-users and django-developers messages. This patch is a great step forward! Are you interested in a Subversion branch devoted to Unicoding Django? Let me know... Adrian -- Adrian Holovaty holovaty.com | djangoproject.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 -~--~~~~--~~--~--~---
Re: Proposal: Can custom tag use namespace
On 8/7/06, limodou <[EMAIL PROTECTED]> wrote:
> How to use namespace? For example,
>
> {% load example %}
> {% example.testtag %}
>
> And I think if the namespace can be optional is better. I don't know
> if it's useful, but sometimes I read others projects, and as I reading
> the template, I don't know which tag is in which file. So find the
> correct tag definition file is somewhat diffcult. If I can add
> namespace in the front of a custom tag name, it'll be easy to locate
> the source file.
Hi limodou,
This would be a nice improvement, and it seems like it could be
accomplished in a backwards-compatible fashion, by allowing
non-qualified template tag names. Would you (or anybody else) be
interested in coming up with a solution?
Adrian
--
Adrian Holovaty
holovaty.com | djangoproject.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
-~--~~~~--~~--~--~---
Re: Re: A final post-0.91 release?
On 8/11/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > As long as it's strictly bug fixes, and no feature additions, that > sounds fine by me. The reason I say "no feature additions" is that it > wouldn't be in our best interest to have another competing branch, as > we did with magic-removal vs. 0.91 a while back. Of course. The goal would simply be to provide bugfixes for people who are still supporting legacy installations. > James, assuming you agree with these goals, are you volunteering to > maintain the branch? :-) If that's what it takes, then yeah :) -- "May the forces of evil become confused on the way to your house." -- George Carlin --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Re: A final post-0.91 release?
On 8/12/06, James Bennett <[EMAIL PROTECTED]> wrote: > > James, assuming you agree with these goals, are you volunteering to > > maintain the branch? :-) > > If that's what it takes, then yeah :) OK, I've set up a 0.91-bugfixes branch and given you commit access. Have at it! Adrian -- Adrian Holovaty holovaty.com | djangoproject.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 -~--~~~~--~~--~--~---
Re: Incorrect error message in template.loader.filesystem.py
On 7/30/06, Martin <[EMAIL PROTECTED]> wrote: > if you pass `None` as `template_dirs` to the `load_template_source` > function, settings.TEMPLATE_DIRS will be used as default (this is done > in `get_template_sources`). > > If now, for whatever reason, no template file coud be found, a the > following check at the end of `load_template_source` is kind of wrong: > if template_dirs: > error_msg = "Tried %s" % tried > else: > error_msg = "Your TEMPLATE_DIRS setting is empty. Change it to > point to at least one template directory." > > Since `None` is passed into this function and the `replacement` with > `settings.TEMPLATE_DIRS` hiddin in `get_template_sources` this check > will always evaluated as False and will provide a wrong error message. Hi Martin, Thanks for pointing this out! I don't understand why somebody would call get_template_sources() manually, but I've made the fix nonetheless, in revision 3575. Adrian -- Adrian Holovaty holovaty.com | djangoproject.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 -~--~~~~--~~--~--~---
Re: Proposal: Can custom tag use namespace
On 8/13/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> On 8/7/06, limodou <[EMAIL PROTECTED]> wrote:
> > How to use namespace? For example,
> >
> > {% load example %}
> > {% example.testtag %}
> >
> > And I think if the namespace can be optional is better. I don't know
> > if it's useful, but sometimes I read others projects, and as I reading
> > the template, I don't know which tag is in which file. So find the
> > correct tag definition file is somewhat diffcult. If I can add
> > namespace in the front of a custom tag name, it'll be easy to locate
> > the source file.
>
> Hi limodou,
>
> This would be a nice improvement, and it seems like it could be
> accomplished in a backwards-compatible fashion, by allowing
> non-qualified template tag names. Would you (or anybody else) be
> interested in coming up with a solution?
>
> Adrian
>
Ok, I'll try to implement it.
--
I like python!
My Blog: http://www.donews.net/limodou
My Django Site: http://www.djangocn.org
NewEdit Maillist: http://groups.google.com/group/NewEdit
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: Proposal: make templatetag loading magic a little more invisible
On 8/10/06, James Bennett <[EMAIL PROTECTED]> wrote:
> 1) Document the way templatetag loading works, and advise tag authors
> to wrap any imports they need in try/except and handle the situation
> as appropriate (for example, by returning nothing from their tag, or
> possibly raising ImproperlyConfigured with a message that a given
> third-party module needs to be installed). This is a bit of a wart,
> but at least it would get the issue documented so that people don't
> have to go digging in the source to figure out what causes it.
>
> 2) Tweak django/templatetags/__init__.py to introspect the ImportError
> it gets and figure out whether the exception came from a non-existent
> 'templatetags' module (in which case it can be safely quashed) or from
> something in a tag library failing to import a needed module (in which
> case the exception should keep propagating in some form so it will
> appear in the eventual traceback). Given that we know what the
> exception would look like for a non-existent templatetag library ("No
> module named myapp.templatetags"), this probably wouldn't be terribly
> hard to accomplish.
>
> Obviously I prefer the latter, since it results in more intuitive
> behavior, but I'm interested in hearing what other people think about
> this.
Yeah, I agree that we should improve the templatetag loading magic.
What about doing *both* -- improving the docs to note the ImportError
gotcha, *and* introspecting the ImportError?
How would you introspect the ImportError, anyway? By parsing the
"args" attribute of the Exception object? Slightly hackish...
Adrian
--
Adrian Holovaty
holovaty.com | djangoproject.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
-~--~~~~--~~--~--~---
Re: Proposal: manipulator-aware validators in post-MR
On 8/11/06, Tom Tobin <[EMAIL PROTECTED]> wrote: > On 8/9/06, Tom Tobin <[EMAIL PROTECTED]> wrote: > > I'd like to restore this ability to Django trunk; there are a couple > > of ways I could go about this, and I'd like input as to which would be > > cleaner: > > I came up with a third possible way of handling this (which is nearly > identical to the second): instead of wrapping validators that have a > ``takes_manipulator`` attribute, would there be an issue with > introspecting for the number of arguments to a validator, and wrapping > if there are three (or, for a method, four)? Replying to myself once again . . . :-p I've created ticket #2535, which has an attached patch for implementing my proposal using currying and introspection for the number of arguments. With the patch applied, giving the validator access to the manipulator is as easy as adding an extra parameter:: def my_validator(manipulator, field_data, all_data): model = manipulator.model if manipulator.change: original_object = manipulator.original_object # . . . do stuff . . . --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Re: Proposal: make templatetag loading magic a little more invisible
On 8/12/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > Yeah, I agree that we should improve the templatetag loading magic. > What about doing *both* -- improving the docs to note the ImportError > gotcha, *and* introspecting the ImportError? Sounds good, though if we introspect the ImportError the docs bit becomes somewhat unnecessary. > How would you introspect the ImportError, anyway? By parsing the > "args" attribute of the Exception object? Slightly hackish... That was the first thing that occurred to me. Not sure if there's a better way. -- "May the forces of evil become confused on the way to your house." -- George Carlin --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: translation of content
On 13-Aug-06, at 12:51 AM, Ahmad Alhashemi wrote: > Then, in templates of a certain language site, you would look for > objects that are related to the current object in the translation > tables and link to them through their get_absolute_url preceded by > their site's address. > > Of course, as I said, it all depends on what you are trying to > achieve. I have sites that are in english, but need to be translated into the 22 official indian languages. The interface and django is in the process of getting translated using i18n, but content is the problem ... so just thinking aloud. I need something very like gettext for content, so the translators can have a similar interface - or even use kbabel for it, though it wouldnt be short strings, but long pieces of content. -- regards kg http://lawgon.livejournal.com http://nrcfosshelpline.in/web/ --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: django and LDAP support
Scott Paul Robertson wrote: > Let me know if there's anything else, > Scott You can remove the l.unbind_s() on line 77. It would also be great if the authenticate() method wasn't tied to the contrib.auth.models.User model. I, for one, use my own custom user model. Maybe extracting the parts that try to get and update the user in authenticate() could be extracted to another method so that people using a custom user model could easily override these methods. Maybe the LDAP_BIND_STRING_FUNC should be moved to a class method instead, which would be empty by default? Then you could just inherit LDAPBackend and override this pre_bind() method if you wanted to do something special (like bind with a service account first). This pre_bind() could be called after intialize() and be passed the ldap object and username, just as LDAP_BIND_STRING_FUNC. I have yet to test the patch, but I hope to try it out later this week at work. Gary Wilson --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: modularity of apps
Malcolm Tredinnick wrote: > One point of view (mine!) is that if an application can't play nicely > with other applications and wants to do its own authentication, etc, > then it's not an application, it's a whole other project. The project > developer should have complete control over what the policies are for > things like this. Otherwise it's too hard to understand what each app is > doing when incorporating it. So if am using the admin application with its (contrib.auth) authentication and then the rest of my site using a custom user model with its own authentication, you are saying that I should make them separate projects? That just doesn't seem right. I don't think anyone has answered the OP's question of how plugable are apps supposed to be? Currently, the only way you can achieve full modularity is to make every installed app its own project. Only then can I set the app's TEMPLATE_CONTEXT_PROCESSORS, MIDDLEWARE_CLASSES, AUTHENTICATION_BACKENDS, etc. and be sure that applications won't stomp over each other. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: the template system's whitespace handling
Tim Keating wrote: > I agree. It seems to me people either care about this or they don't. > Ergo the Django way to do this would be to make the whitespace handler > pluggable and set it globally in settings.py. If performance does not suffer, I'm with Malcolm that it should simply be done by default with no extra settings. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
