is_approved
I strongly feel the need for an is_approved field in the User model (django.contrib.auth.models). This field would allow for user systems that require email verification, user systems that require subscriptions/payment, etc... Checking for is_approved at login, should be an option. Some possible solutions, which would both allow for optional approval and backwards compatibility: 1. A modified login_required decorator: @login_required(approval=True) 2. A setting in settings.py: LOGIN_REQUIRES_APPROVAL = True Let me know what you think? --~--~-~--~~~---~--~~ 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: is_approved
Ok, i made a ticket for this (i thought that was probably a better place for this): http://code.djangoproject.com/ticket/2033 Bryan wrote: > I strongly feel the need for an is_approved field in the User model > (django.contrib.auth.models). This field would allow for user systems > that require email verification, user systems that require > subscriptions/payment, etc... > > Checking for is_approved at login, should be an option. Some possible > solutions, which would both allow for optional approval and backwards > compatibility: > > 1. A modified login_required decorator: > @login_required(approval=True) > > 2. A setting in settings.py: > LOGIN_REQUIRES_APPROVAL = True > > Let me know what you think? --~--~-~--~~~---~--~~ 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: Custom manipulators
Ivan Sagalaev wrote:
> You are looking for undocumented "follow":
>
> class MyManipulator(MyModel.ChangeManipulator):
> def __init__(self, id):
> MyModel.ChangeManipulator.__init__(self, id, follow={
> 'my_text_field': False,
> 'my_date_field': False,
> 'my_upload_field': False,
> })
>
> Manipulator will look only for fields in its "follow" dict where their
> values evaluates to "true". A default manipulator has its "follow"
> prefilled with editable fields from a model and a "follow" parameter
> that is passed in the constructor will update those values.
After sending my post, and trawling through the code, I realised I
could use 'follow' to do this, like you say (I had assumed it was only
for related objects), and felt like a bit of an idiot. However, I had
problems. But I've forgotten what they were now - when I get back from
work I'll have another go, and find out if it was just me being stupid
again.
Sorry for the noise,
Luke
--~--~-~--~~~---~--~~
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: Custom manipulators
Luke Plant wrote: > However, I had > problems. But I've forgotten what they were now I remembered what my problem was: Manipulator.get_validation_errors() ignores the 'follow' parameter, so you get validation errors for fields that aren't included. Also, it's not simple to strip them out, since you have things like 'mydate_date' and 'mydate_time' if you have a DateTimeField called mydate. Also, 'follow' is sub-optimal -- you have to calculate (either by hand or automatically) the fields that you want to *exclude*, rather than pass in simply the ones you want to include. Maybe some utility function on AutomaticManipulator might help. My aim in all of this, is that if I add any type of field to MyModel, I shouldn't have to alter MyCustomManipulator at all. Luke --~--~-~--~~~---~--~~ 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: inserting aggregates in one transaction
On 30/05/2006, at 4:43 PM, Shaun Cutts wrote: > > Ian, > > Thanks. Your code looks concise, but a bit mysterious (maybe it's > the time > of night). Is this a way to get extra events triggered in a db > transaction, > or is it just inside a single web request? > just inside a single web request. have a look at models/base.py def save() it does... signal the pre-save's do the actual save call transaction.commit_unless_managed() signals the post_save > As far as I can tell, you don't seem to be insisting on having one > transaction; if you are, are you using psychopg backend? How is it > able to > get the ids of previously created objects (in the same > transaction)? I'd > assumed you needed to pre-increment the sequence to generate a new > id by > hand, then plug this value in on insert. nope.. I'm not caring.. but I could be easily enough by putting my logic where I actually call the save() function. > > Ah -- ok, in your case you may be in one transaction, but you don't > need the > id of the thing created (witness: if instance.id == None: ... :)) i'm doing it pre-save.. and I need to determine if it is a new record or not. if I hooked the function to the post-save I would have got the 'id' field, but I don't think I could determine if it was a new record or not. > > Some background: I'm trying to automate bulk load of data from web- > crawlers. > These loads happen often enough that, if I don't enforce atomicity, > I'll > have a good chance of ending up with a mess in the db when one gets > interrupted for some random reason. > understood... you should try and use the post-save with transactions I'm guessing. regards ian > - Shaun > > > > --~--~-~--~~~---~--~~ 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: Custom manipulators
Luke Plant wrote: >Manipulator.get_validation_errors() ignores the 'follow' parameter, so >you get validation errors for fields that aren't included. > Just tested it and it shows that you don't. I have a required field switched off with "follow" that is not in the form. It doesn't give an error. When I include it in follow with "True" it does give an error. My quick guess (I'm a bit lazy to check :-) ) is that automatic manipulator just don't create field objects based on follow and this is why it works for validation. > Also, it's >not simple to strip them out, since you have things like 'mydate_date' >and 'mydate_time' if you have a DateTimeField called mydate. > > Follow works on model fields, not manipulator field objects. I nonetheless checked it out, this is the beginning of automatic manipulator constructor: def __init__(self, follow=None): self.follow = self.opts.get_follow(follow) self.fields = [] for f in self.opts.fields + self.opts.many_to_many: if self.follow.get(f.name, False): self.fields.extend(f.get_manipulator_fields(self.opts, self, self.change)) # Here's when your date and time fields come into existance >Also, 'follow' is sub-optimal -- you have to calculate (either by hand >or automatically) the fields that you want to *exclude*, rather than >pass in simply the ones you want to include. Maybe some utility >function on AutomaticManipulator might help. > > Yes... But I should say that I needed to exclude fields from manipulators more often. >My aim in all of this, is that if I add any type of field to MyModel, I >shouldn't have to alter MyCustomManipulator at all. > > Hm... But there are cases when you want include a new field in this particular manipulator and there are when you don't. I don't think there can be a default behavior. An example. I have a User model and it has some fields that only an administrator can touch (priveleges, rating) and fields editable by a user (birth_date, location, etc..). I have two manipulators for this model: administrative one with excluded personal fields and a personal one with excluded administrative fields. And I can't predict in which manipulator any new field should go. I will have to decide it for each field anyway. --~--~-~--~~~---~--~~ 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: Custom manipulators
Luke Plant wrote:
> Also, 'follow' is sub-optimal -- you have to calculate (either by hand
> or automatically) the fields that you want to *exclude*, rather than
> pass in simply the ones you want to include. Maybe some utility
> function on AutomaticManipulator might help.
Here's my version ... I also think that this approach has some room left
to improve ;-)
def follow_only(model_cls, field_list):
"""builds the "follow" dict that specifies which fields to take from
the POST data.
Manipulators are passed a dict { fieldname : Boolean } as `follow`.
`follow_only()` builds this dict from the model class and a list of
field names (containing the fields to take from the POST data.
This should really go into a library module or to the django
contributions.
"""
res = dict.fromkeys(model_cls._meta.get_follow().keys(), False)
res.update(dict.fromkeys(field_list,True))
return res
Michael
--~--~-~--~~~---~--~~
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: is_approved
But what if you want to verify someone's e-mailaddress *and* someone's name? Then we need two of those fields. IMHO we should keep the User model as simple as it is right now. If you want to add fields, you should use model inheritance, but that's still on the to-do list, as far as I know. The sub-optimal alternative is using a foreignkey to the User model, use inline editing and set max_num_in_admin to 1. BTW when can we expect model inheritance? (I'm not asking for a date, it's ready when it's done. But is it a high priority or low priority thing?) Rudolph --~--~-~--~~~---~--~~ 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: Custom manipulators
Ivan Sagalaev wrote: > Luke Plant wrote: > > >Manipulator.get_validation_errors() ignores the 'follow' parameter, so > >you get validation errors for fields that aren't included. > > > Just tested it and it shows that you don't. I have a required field > switched off with "follow" that is not in the form. It doesn't give an > error. When I include it in follow with "True" it does give an error. I must have made a typical late night error, or maybe I'm confusing what actually happened with various aborted attempts (that didn't use 'follow'), and another error I was having (upload fields not working correctly -- the example usage in the custom manipulator docs doesn't handle file uploads). Thanks for checking that for me. > My quick guess (I'm a bit lazy to check :-) ) is that automatic > manipulator just don't create field objects based on follow and this is > why it works for validation. Yep, you are right, it does just that. > >My aim in all of this, is that if I add any type of field to MyModel, I > >shouldn't have to alter MyCustomManipulator at all. > > > > > Hm... But there are cases when you want include a new field in this > particular manipulator and there are when you don't. I don't think there > can be a default behavior. > > An example. I have a User model and it has some fields that only an > administrator can touch (priveleges, rating) and fields editable by a > user (birth_date, location, etc..). I have two manipulators for this > model: administrative one with excluded personal fields and a personal > one with excluded administrative fields. And I can't predict in which > manipulator any new field should go. I will have to decide it for each > field anyway. I see your point, but when you decide to add the field to, for example, your administrative fields, it's easy to remember to change that manipulator, because you'll have to change the template anyway (I presume), and you're quite likely to actually test the code. At the moment you have to remember to change all the *other* manipulators -- in your case this is fairly easy to remember, because you happen to have 2 manipulators that cover everything, but in other cases (e.g. 1 manipulator or more than 2) it seems like the current interface is more bug prone that its inverse. I guess my suggestion would be an alternative keyword argument 'limit_to_fields' to AutormaticAdd/ChangeManipulator.__init__(), mutually exclusive with 'follow', that would calculate the 'follow' argument for you. The implementation would be pretty much like the code Michael posted. Luke --~--~-~--~~~---~--~~ 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: is_approved
ASP.NET's built in Membership system, which was I'm sure was thoroughly thought out, has an IsAppproved field in addition to their IsLockedOut (is_active) field. >From a few of the emails I received, I'm not sure you all are seeing the difference between is_active and is_approved. An email verification system works by locking out a user until that user has verified their email address by clicking on a link. If we implement that verification view by having it turn on is_active (is_active = True) instead of using is_approved, then we can never explicitly make our users inactive, because all they would have to do to reactivate their account is click their email verification link. Thus we need to separate the two, having an is_approved field in addition to the is_active field. Rudolph wrote: > But what if you want to verify someone's e-mailaddress *and* someone's > name? Then we need two of those fields. IMHO we should keep the User > model as simple as it is right now. If you want to add fields, you > should use model inheritance, but that's still on the to-do list, as > far as I know. The sub-optimal alternative is using a foreignkey to the > User model, use inline editing and set max_num_in_admin to 1. > > BTW when can we expect model inheritance? (I'm not asking for a date, > it's ready when it's done. But is it a high priority or low priority > thing?) > > Rudolph --~--~-~--~~~---~--~~ 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: is_approved
On 5/30/06, Bryan <[EMAIL PROTECTED]> wrote: > If we implement > that verification view by having it turn on is_active (is_active = > True) instead of using is_approved, then we can never explicitly make > our users inactive, because all they would have to do to reactivate > their account is click their email verification link. Thus we need to > separate the two, having an is_approved field in addition to the > is_active field. Or just set up your "confirm account" link to expire once it's been clicked. -- "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 -~--~~~~--~~--~--~---
multi-auth branch... time to merge?
Has anyone tested out the multi-auth branch yet? I haven't heard anything, so either people aren't using it, or it's working well and the docs are good enough. Personally, I've been using it with both external SQL and LDAP backends for over a month now. No issues, but my apps are internal and don't get much traffic. Thanks, Joseph --~--~-~--~~~---~--~~ 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: is_approved
I mistakenly sent a reply to Bryan instead of the group, and here is my reply to Brian's reply: On Tuesday 30 May 2006 18:43, Bryan, wrote: > And do you use is_active = True in your verification view to give the > user access to his account? If so, please read my new post. If not, > how are you doing it? > > On 5/30/06, Luke Plant <[EMAIL PROTECTED]> wrote: > > Bryan wrote: > > > I strongly feel the need for an is_approved field in the User > > > model (django.contrib.auth.models). This field would allow for > > > user systems that require email verification, user systems that > > > require subscriptions/payment, etc... > > > > For email verification, you can do this without creating a User > > object. I believe Ellington does this, and inspired by that I've > > implemented the same thing for my own system. It isn't hard - you > > just send an e-mail with a URL that contains the e-mail address and > > a hash of the e-mail address that only you could have created. > > > > Luke [Replying to the top] I'm not using User, but a custom Member object, but it makes no odds: the Member object does not exist in the database until *after* the e-mail is verified, so I do not need a 'verified/approved' field. It works like this: The initial sign up prompts for an e-mail address, and that's all. That generates an e-mail with a link in, which contains a hash of (e-mail address + my secret key). Clicking the link takes you to the second stage, which checks the hash and e-mail (and sticks them in a hidden field for later -- I recheck them every time the data is posted back, to ensure no tampering occurs). Once the rest of the details are captured, if required, the Member object is created, and not before. I use a similar process for changing e-mail address and resetting passwords -- all without storing the new data in the model until it is verified. You can also include a timestamp in the hashed string, split it out and check it, thus creating a method for links to expire. Luke -- "The only skills I have the patience to learn are those that have no real application in life." (Calvin and Hobbes) Luke Plant || L.Plant.98 (at) cantab.net || http://lukeplant.me.uk/ --~--~-~--~~~---~--~~ 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: multi-auth branch... time to merge?
On 05/30/06 20:33, Joseph Kocherhans wrote: > Has anyone tested out the multi-auth branch yet? I haven't heard > anything, so either people aren't using it, or it's working well and > the docs are good enough. Personally, I've been using it with both > external SQL and LDAP backends for over a month now. No issues, but my > apps are internal and don't get much traffic. > I use it in an email-account administration app to authenticate against a custom Mailbox model with email/password credentials. Works great, zero problems. cheers Steven --~--~-~--~~~---~--~~ 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: is_approved
I need their email to be verified at sign up and when they change it in their profile. I don't understand how this system would verifiy someone changing their email address. --~--~-~--~~~---~--~~ 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: is_approved
On Tuesday 30 May 2006 19:58, Bryan wrote: > I need their email to be verified at sign up and when they change it > in their profile. I don't understand how this system would verifiy > someone changing their email address. I just implemented this in my system yesterday :-) For an existing user, I have this: def email_and_username_hash(email, username): """Gets a hash of an email address + username""" return md5.new(settings.SECRET_KEY + email + username).hexdigest() (user_name could be replaced with an id here) So you send this hash, plus the username, plus the e-mail address, to the new e-mail address. You extract the email and username, and check: email_and_username_hash(email, user_name) == [the hash in the email] On this evidence you can change the e-mail address of that user. Luke -- "The only skills I have the patience to learn are those that have no real application in life." (Calvin and Hobbes) Luke Plant || L.Plant.98 (at) cantab.net || http://lukeplant.me.uk/ --~--~-~--~~~---~--~~ 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: is_approved
My point is how do you lock the user out until he confirms his changed email address? Luke Plant wrote: > On Tuesday 30 May 2006 19:58, Bryan wrote: > > > I need their email to be verified at sign up and when they change it > > in their profile. I don't understand how this system would verifiy > > someone changing their email address. > > I just implemented this in my system yesterday :-) > > For an existing user, I have this: > > def email_and_username_hash(email, username): > """Gets a hash of an email address + username""" > return md5.new(settings.SECRET_KEY + email + username).hexdigest() > > (user_name could be replaced with an id here) > > So you send this hash, plus the username, plus the e-mail address, to > the new e-mail address. You extract the email and username, and check: > email_and_username_hash(email, user_name) == [the hash in the email] > > On this evidence you can change the e-mail address of that user. > > Luke > > -- > "The only skills I have the patience to learn are those that have no > real application in life." (Calvin and Hobbes) > > Luke Plant || L.Plant.98 (at) cantab.net || http://lukeplant.me.uk/ --~--~-~--~~~---~--~~ 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: is_approved
On 5/30/06, Bryan <[EMAIL PROTECTED]> wrote: > I need their email to be verified at sign up and when they change it in > their profile. I don't understand how this system would verifiy > someone changing their email address. Honestly, now that I've read through this more thoroughly, I think what you want is to define a profile class and take advantage of the built-in features Django offers with respect to that. Here's the executive summary: 1. Define a class which has all the extra attributes you want for users. Maybe you want to add their site URL, a brief bio, etc. 2. Give it a OneToOneField to auth.User. 3. Add the setting 'AUTH_PROFILE_MODULE' in your settings.py and have its value be the name of your profile class (e.g., 'myapp.UserProfile'). Congratulations, you're done. You can now call 'get_profile()' on any User object in your system to fetch the associated profile and run whatever logic you need based on that. Perhaps someday this could be documented so that people won't have to read the auth code to realize you can do this ;) -- "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: is_approved
Ok, this is my last comment on the topic. Now that you've mentioned it, first_name and last_name should not even be in User. They should be in profile. Profile is for personalization, not for user specific login criteria like (is_active, is_staff, is_superuser, IS_APPROVED). I'm certain this is not the last time you all are going to see someone asking for this feature request. --~--~-~--~~~---~--~~ 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: is_approved
On 5/30/06, Bryan <[EMAIL PROTECTED]> wrote: > Now that you've mentioned it, first_name and last_name should not even > be in User. They should be in profile. Profile is for > personalization, not for user specific login criteria like (is_active, > is_staff, is_superuser, IS_APPROVED). My personal opinion on this, which reflects nothing other than that it rattles around inside my head: First name and last name are such overwhelmingly common components of a user that they belong in the User class. Multiple layers of active/approved/etc. are not as common, and belong in a profile tailored to the specific site's needs. -- "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: EVOLUTION - Add Field Schema Evolution Support
Ilias Lazaridis wrote: > After reviewing the relevant source code base a little, I have started > with the implementation of the schema evolution skeleton (which will > contain a functional "Add Field" support). > > http://case.lazaridis.com/multi/wiki/DjangoSchemaEvolution > > With a very small assistance from the team (mostly subjecting constructs > and of course review of resulting code), I estimate to have a working > solution within 3 days. > > My questions to the team is: > > Can I have a branch / or sandbox location for this (within the django > SVN), or do I have to setup an own svn? ... It would be nice if I could have an answer on this, thus I can avoid redundant effort. - The simple "ADD FIELD" functionality is ready (draft version, but functional). To simplify things, I could provide several patches. * 1 patch which decouples some existent functionality into a seperate function * 1 patch which adds some function * 1 patch which refactors an existent function * 1 patch which enlinks the "ADD FIELD" evolution into the syncdb command But working with patches is terribly inconvenient. I prefere to make incremental check-in's, thus the development is trackable for other developers. It would be nice, if a branch location could be opened, something like "evolution-draft". . -- http://lazaridis.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: unicode.. reject?
Ivan Sagalaev wrote:
> gabor wrote:
>
>> i'm also willing to help with this task... but..do i understand this
>> correctly, that it's agreed that django is going to switch to unicode?
>>
>>
> Being one of the proponent of the all-unicode way back when it was
> proposed I should say that the more I think of it the more I'm afraid
> that it can create just as much problems as it will solve.
hi,
a short summary at the beginning:
(to borrow the words of someone from sci.lang.japan):
This is a very hard subject to discuss without creating a personal blog,
by the way.
:))
i understand your point, but i still think it pays off to switch to
unicode. but it needs a confirmation from the django-BDFL's side that
they are willing to make this step. if not, there's no point to work on it.
generally i think, that you must understand the various aspects of
unicode. whether you use unicode-strings or byte-string, you have to
understand them.
below are more&less various rants regarding the topic :) (if it sounds
too agressive, then sorry, wasn't my intent)
> Today there
> is a convention that Django works everywhere with byte strings except
> some rare cases where it is convinient to use Python's built-in unicode
> functions (these cases include counting length in validation code and
> various string conversions in filters like in the unapplied patch in
> ticket http://code.djangoproject.com/ticket/924). Using this convention
> one can write international apps without worries since all messy things
> are made inside the framework.
well, i would replace 'without worries' with 'good enough' :)
>
> If we change this convention to using Python's unicode everywhere we
> will hardly win anything except some feeling of a more "pure" approach.
> At least _I_ can't see any gain :-).
some people would say (maybe including me) that it's already a gain :)
> However there will be some
> disadvantages that I think are serious:
>
> - I heard that many 3rd party libraries don't work with unicode so a
> user will be forced to do some coversions manually
this happens both ways. some libraries work with unicode strings, so you
have to convert back&forth there :)
for example, i was building a very simple web-file-manager. you can ask
python to get you the os.listdir, etc, data in unicode, which i think
the only sensible way, because otherwise you have to watch out for the
filesystem-encoding. but because the querystring and httpresponse is
bytestring, i have .encode('utf8'), .decode('utf8') all the way.
> - byte strings is a default string type in Python and is more widely
> used than unicode, I'm afraid many people in ASCII-world will be
> resistant to switching all their coding to unicode because they can't be
> sure that it works right because they can't test it easily themselves
hmm... is it that hard to get some japanese text and maybe some german
names? :)
anyway, i think it actually might help them at the end, because
converting your app to unicode means to think about all the places where
data enters the system and where data leaves the system.
so this is more explicit, and, as 'import this' says: explicit is
bettern than implicit :))
>
> So may be Django should just wait for Python 3000 when unicode string
> will become default ones and developers would be more widely aware of
> this change.
'aware of this change' is an understatement :) there will not be any
byte-strings in py3000 :)
gabor
--~--~-~--~~~---~--~~
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: is_approved
I would prefer it if the first name and the last name are removed from the User model, but it has no priority to me since you can leave them empty. IMHO these fields are not that common: - sometimes the policy is to save initials + lastname (or any other combination) - in the Netherlands we also have something like an "in between" name part which is officially part of the last name, but often stored in a seperate field. Example: Jan van der Bos. Jan is the first name, "van der Bos" is the last name, but you want to sort it on "Bos". I don't know about other countries. I agree with Bryan that all personal user information should be in the profile model. Rudolph When looking to firstname / lastname from an international point of view --~--~-~--~~~---~--~~ 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: multi-auth branch... time to merge?
On 5/31/06, Joseph Kocherhans <[EMAIL PROTECTED]> wrote: > > Has anyone tested out the multi-auth branch yet? I haven't heard > anything, so either people aren't using it, or it's working well and > the docs are good enough. Personally, I've been using it with both > external SQL and LDAP backends for over a month now. No issues, but my > apps are internal and don't get much traffic. > > Thanks, > Joseph > I've been on leave for 3 weeks but I really want to try it out now I'm back at work. I port my ldap auth stuff to it and let you know how it goes. matthew --~--~-~--~~~---~--~~ 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: EVOLUTION - Add Field Schema Evolution Support
> It would be nice if I could have an answer on this, thus I can avoid > redundant effort. Perhaps there would be more confidence in your efforts if it: a) Wasn't making someone else's work redundant b) Came from some detailed design c) Worked on all databases before being checked in If you posted some designs on your wiki then we can at least critique it. I don't think you've described what the "Field Add" functionality is, or how it works, for example. -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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: EVOLUTION - Add Field Schema Evolution Support
oggie rob wrote: >> It would be nice if I could have an answer on this, >> thus I can avoid redundant effort. > > Perhaps there would be more confidence in your efforts if it: > a) Wasn't making someone else's work redundant > b) Came from some detailed design > c) Worked on all databases before being checked in > > If you posted some designs on your wiki then we can at least critique > it. I don't think you've described what the "Field Add" functionality > is, or how it works, for example. ... I do not invest time to design and document something, where the code is already available and selfdocumenting. The question was: " Can I have a branch / or sandbox location for this (within the django SVN), or do I have to setup an own svn? " From the SVN _branch_, you can review the code, I can ask the team for some constructs etc. and complete the skeleton. As, said, I can alternatively post the patches, but such a development methodology is not very efficient. I mean, for what are svn's there? . -- http://lazaridis.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: introduction
Thanks everyone for the ideas, I've updated the wiki page. Please take a look if you have a moment and let me know. Thanks, Chris --~--~-~--~~~---~--~~ 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: multi-auth branch... time to merge?
Joseph, On 5/30/06, Joseph Kocherhans <[EMAIL PROTECTED]> wrote: > > Has anyone tested out the multi-auth branch yet? I haven't heard > anything, so either people aren't using it, or it's working well and > the docs are good enough. Personally, I've been using it with both > external SQL and LDAP backends for over a month now. No issues, but my > apps are internal and don't get much traffic. > Last night I put together a PAMBackend that uses pyPAM to authenticate users against Linux PAM. With this I achieved something that could be the key for deploying the (first :-) Django based app at work (because, paradojically enough, every M$ based web apps already installed there force us [users] to remeber a different set of username/password, there isn´t single sign on). This is the scenario: django+multi-auth - PAMBackend - PAM - winbind - Old WinNT4 domain controller It´s working ok so far. It is simply a plain mixin of your setting-based backend multi-auth sample and the example program shipped with PyPAM but I will post it to the wiki page for review tomorrow after refactoring it a little bit. I understand that by modifiying the relevant /etc/pam.d/ file other auth backends could be used (unix password, ...) Thanks for your work. -- Ramiro Morales --~--~-~--~~~---~--~~ 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: EVOLUTION - Add Field Schema Evolution Support
Ilias Lazaridis wrote: > After reviewing the relevant source code base a little, I have started > with the implementation of the schema evolution skeleton (which will > contain a functional "Add Field" support). > > http://case.lazaridis.com/multi/wiki/DjangoSchemaEvolution > > With a very small assistance from the team (mostly subjecting constructs > and of course review of resulting code), I estimate to have a working > solution within 3 days. ... you can find the full modifications (only within one file) here: http://code.djangoproject.com/attachment/ticket/2043/simple_evolution_support.diff Only the patch 2043 must be applied (as it contains all the other 3 patches) http://code.djangoproject.com/ticket/2040 http://code.djangoproject.com/ticket/2041 http://code.djangoproject.com/ticket/2042 http://code.djangoproject.com/ticket/2043 In order to stabelize/generalize this and to create a basic skeleton, I would need an SVN location (which I will most possibly provide myself) and a few answers from the team. The SoC Project can pickup the results as a starting point (we all know how difficult it is to _start_ a work) or as a comparison point. - Some Remarks: The most difficult part was to understand the existent source-code. The source-code would need some refactoring prior to going into deeper work. The refactoring affects source-code OO, source-code structure/modularity and the terminology (which is not aligned to existent OO terminology). The refactoring would allow e.g. the student of the "SoC Evolution Project" to produce more and better results in the same timeframe, as he would spend less time to understand the existent code-base. There is a possibility that such a refactoring could happen in paralell with the SoC Schema Evolution Project. If the team is intrested in further elaborations, please let me know. - > My questions to the team is: > > Can I have a branch / or sandbox location for this (within the django > SVN), or do I have to setup an own svn? > > If it is possible to create a branch, please assign me the username > "lazaridis_com". > > Basicly I would prefere to place the code in an own SVN, but there are > several organizational problems (synchronization etc.), which I have not > solved yet. Additionally, the django core developers should have access > to the code, thus they can directly apply the neccessary corrections / > additions. > > . > -- http://lazaridis.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: unicode.. reject?
gabor wrote:
>>Using this convention
>>one can write international apps without worries since all messy things
>>are made inside the framework.
>>
>>
>
>well, i would replace 'without worries' with 'good enough' :)
>
>
Ok :-)
>for example, i was building a very simple web-file-manager. you can ask
>python to get you the os.listdir, etc, data in unicode, which i think
>the only sensible way, because otherwise you have to watch out for the
>filesystem-encoding. but because the querystring and httpresponse is
>bytestring, i have .encode('utf8'), .decode('utf8') all the way.
>
>
Not at all. You can talk to file system in utf-8 and do no conversions
at all. I'm doing it in my app and it works just fine.
I don't know exactly how Python handles encoding of data that it
receives from the OS and I think there can be problems with
misconfigured OS giving out those characters in a non-UTF8 byte
encoding. But unicode here won't help either since Python would try to
convert some arbitrary stream to unicode and will throw an exception.
With byte string I suppose you will get the string without errors but
with the garbage in it. All this anyway just requires configuring
locales properly.
And as a sidenote: HttpResponse can happily accept unicode with
convertion to DEFAULT_CHARSET on actual output.
>hmm... is it that hard to get some japanese text and maybe some german
>names? :)
>
>
I meant that it's hard when you should install some weird fonts and look
at symbols you don't understand :-). But you are right. I think every
developer in ASCII world can work with, say, accented latin characters
and test if they are uppercased or counted properly.
On the other hand people working closely with non-ASCII characters are
working out some useful debugging habits that one just can't know only
by theory. For example I can very quickly distinguish string that is in
utf-8 shown in windows-1251 locale from string in windows-1251 shown in
utf-8 locale by just looking at it. For a person not working with
cyrillic they all will look equaly weird I think... Which is kinda
supports the idea of all-unicode since Python represents byte-strings
differently than unciode ones.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
