Re: Lazy registration with django.contrib.auth
On Feb 2, 5:29 pm, "Daniel" <[EMAIL PROTECTED]> wrote: > I would like to implement this as an extension of the existing auth > code. Is there any interest in a trunk patch to achieve this? If so, > any suggestions on best practices? I would suggest taking a look at ticket #3011 (and its attached patch), which deals with allowing extension of the contrib.auth User model. 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 -~--~~~~--~~--~--~---
Re: unicode issues in multiple tickets (#952, #1356, #3370) and thread about Euro sign in django-users
On Jan 27, 2007, at 6:44 PM, ak wrote: > And another thing I still don't understand is: let's pretend I use > MySQL 4.0 with national charset and my templates are in the same > charset too. How would work: It should not work. -- Julian 'Julik' Tarkhanov please send all personal mail to me at julik.nl --~--~-~--~~~---~--~~ 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: unicode issues in multiple tickets (#952, #1356, #3370) and thread about Euro sign in django-users
On Jan 27, 2007, at 6:44 PM, ak wrote: > 1. newforms are with unicode inside > 2. ORM is with str inside 3. welcome to the world of pain -- Julian 'Julik' Tarkhanov please send all personal mail to me at julik.nl --~--~-~--~~~---~--~~ 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, "reverse inline" editing, fieldsets
On Feb 2, 1:17 pm, "Frankie Robertson" <[EMAIL PROTECTED]> wrote: > Sorry, I had some trouble understanding your situation. So I'm not > sure, but isn't this what prefixes are for? I suppose they're a bit > tedious to use (what with having to inject the id of the child row > into the clean_data of the parent row and shoving the whole thing into > a transaction) but not that bad. I've got some somewhat non-trivial > code involving four interrelated objects being added that isn't really > open but I could possibly share if you're having problems. I haven't come across prefixes yet, so I don't know. I guess I'll check it out. My situation really is just that I have relationships that point in the opposite direction than Django expects: they're not going from child to parent, but parent to child. The is preventing me from getting a form object that automatically has the fields I want and saving correctly. > Or is it to do with the scaffolding and things not appearing in the > right order? No, I'm not using the form.as_table(), etc. methods. I'm placing the fields into my template directly. > The point in scaffolding is that it was only made to be knocked down. True, but the more cases that Django can automatically deal with, the better. I feel like it's almost able to handle what I'm doing, with the exception of these few relationships, and it's seems like a bit of a pain to graft on a few things to the scaffolding. Thanks for the reply. I'll look into prefixes, but they're not in the docs yet. I'll ask on the user list. --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 -~--~~~~--~~--~--~---
Re: Status update on newforms-admin branch
Adrian Holovaty wrote: > > I've > also taken the opportunity to refactor some admin-specific options -- > raw_id_admin and prepopulate_from -- so that they're defined in the > "class Admin" rather than in the model fields themselves. with this change to the raw_id_admin, what is the recommended approach, when i want to use a ChangeManipulator (the automatic one generated from the model), but i want to do it the raw_id_admin way, otherwise the Manipulator loads in every possibly-related object, when doing the validation. up to now i simply added raw_id_admin = True to the model's field, but now i do not know how it should be handled...i realize that the new-admin is probably using the newforms... and i do not know how raw_id_admin is handled there 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?hl=en -~--~~~~--~~--~--~---
Re: Status update on newforms-admin branch
> I agree this approach is a huge improvement over the current syntax,
> but I wonder whether it can be expanded even more. Instead of
> dictionaries, let's use objects:
Woah... inline that is specified by objects that can be subclasses?
I'll have to wrap my head around that one.
Would it be possible to nest inlines? This is one limitation we
sometimes bump up against since our data model spans more than a few
relationships sometimes, and it would be nice to have greater inline
depth.
For example, if you have:
class Kingdom(models.Model):
#
class Admin:
inlines = (
StackedInline('Phylum')
)
class Phylum(models.Model):
kingdom = models.ForeignKey(Kingdom)
class Admin:
inlines = (
StackedInline('Class')
)
class Class(models.Model): # ignore the reserved word :)
phylum = models.ForeignKey(Phylum)
class Admin:
inlines = (
StackedInline('Order')
)
etc...
Could that work and span all those relationships, following the
relationships as it goes.
-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?hl=en
-~--~~~~--~~--~--~---
Ticket #3002 Admin app bug when using order_by with a FK. Reopen?
Hi, I've just added in a comment to that ticket: * A test case that tries to demonstrate it isn't a dupe of #2076 and trying to justify a reopen. * A tentative patch that would solve the issue but it depends on the proposed fix for ticket #2076 being applied first. Regards, -- 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?hl=en -~--~~~~--~~--~--~---
Re: Status update on newforms-admin branch
On Feb 2, 12:01 pm, "Adrian Holovaty" <[EMAIL PROTECTED]> wrote:
> The Jan. 31 deadline for merging the newforms-admin has passed, so I
> thought I'd give a status update:
Kudos on these changes (& newforms, of course). I really like that
admin is now as "legit" as regular forms for public views - very
efficient & flexible. Very DRY!
> from django.contrib.admin import TabularInline, StackedInline
>
> # ...
>
> class Admin:
> inlines = (
> TabularInline('Child', min=3, max=20, extra=3,
> fields=('name', 'age')),
> StackedInline('Job', min=1, max=3,
> fields=('company', 'salary')),
> )
>
Adrian, that is a phenomenal idea. Succinct and powerful.
Just one q: How would you specify the ordering of these displayed
fields vs. others? e.g. can you say 'field1', 'field2', inline[0],
'field3', inline[1] etc.
-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?hl=en
-~--~~~~--~~--~--~---
Status update on newforms-admin branch
The Jan. 31 deadline for merging the newforms-admin has passed, so I
thought I'd give a status update:
I'm really excited about the changes made so far in this branch. In a
nutshell, the way admin options are specified has gotten *much* more
flexible, resulting in easier and more powerful customization of the
Django admin site. A model's "class Admin" now has new hooks, such as
has_add_permission(), that let you define arbitrary behavior. I've
also taken the opportunity to refactor some admin-specific options --
raw_id_admin and prepopulate_from -- so that they're defined in the
"class Admin" rather than in the model fields themselves. To see which
hooks have been implemented, see the class ModelAdmin in
django/contrib/admin/options.py in the newforms-admin branch.
The admin site, using this branch, should be completely functional
according to my tests -- except for "edit inline" fields. If you're
not using "edit_inline" in your models, I encourage you to check out
the branch and take it for a spin, reporting any bugs. Information on
getting the branch is here:
http://code.djangoproject.com/wiki/NewformsAdminBranch
Regarding "edit inline," a couple of decisions need to be made. Ticket
#2248 (http://code.djangoproject.com/ticket/2248) has an interesting
suggestion: you define the inline stuff within the admin class. I'll
copy and paste from that ticket:
class Admin:
inline_models = (
{'model':'Child',
'type':models.TABULAR,
'min_num_in_admin':3,
'max_num_in_admin':20,
'num_extra_on_change':3,
'fields':('name','age',)
},
{'model':'Job',
'type':models.STACKED,
'min_num_in_admin':1,
'max_num_in_admin':3,
'fields':('company','salary',)
}
)
I agree this approach is a huge improvement over the current syntax,
but I wonder whether it can be expanded even more. Instead of
dictionaries, let's use objects:
from django.contrib.admin import TabularInline, StackedInline
# ...
class Admin:
inlines = (
TabularInline('Child', min=3, max=20, extra=3,
fields=('name', 'age')),
StackedInline('Job', min=1, max=3,
fields=('company', 'salary')),
)
This infastructure would let you create your own inline types by
implementing an Inline subclass.
What sort of hooks would an Inline class need? And are there any
thoughts or other ideas/proposals while we're focusing on this?
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?hl=en
-~--~~~~--~~--~--~---
Ticket #1541. Could someone please take a look.
Hi all, Could a core developer please take a look and see if this ticket http://code.djangoproject.com/ticket/1541 can be closed? This has been discussed here http://groups.google.com/group/django- developers/browse_thread/thread/9f9f1ff61e9314a5/4a8229f580711c96 and another attempt to initiate a discussion elicited no response http://groups.google.com/group/django-developers/browse_thread/thread/ 16fb112334a4792c/7d7581663ec90fb1 The patch is more than a month old (yeah, I know there was Christmas and New Year in between :). I think it is good to be accepted. Please keep a user and minor contributor happy :) Thanks, Suriya --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Field labels and i18n in newforms
When specifying labels for fields in a newforms Form, I use _() gettext to provide localized versions of the field label. The problem is the language may change midway, and the label binding is done at Form initialization when the class is defined. The following code is what sets the actually printer label: from newforms/forms.py: Form.__init__(): if self.field.label is None: self.label = pretty_name(name) else: self.label = self.field.label The solution would be to make the translation later. Likely, when the form is initialized. So I am suggesting somehow making the above read: self.label = _(self.field.label) When this is appropriate. Anyone have other suggestion? Has the same problem? Wants to commit a patch? Dan --~--~-~--~~~---~--~~ 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: form.clean conundrum
I actually just ran into this problem. I was assuming that if my form's clean() hook were called, that clean_data would have at the very least empty entries for the already-validated fields. In my case, I don't need to do complex validation (database hits) unless the previous fields are valid, and testing for self.is_valid() or using bool(self.errors) in turn re-calls clean(), e.g., infinite recursion. I can see having access to the ErrorDict as being useful. Particularly since you can do your validation based on individual field errors. On Jan 26, 11:16 am, "Gary Doades" <[EMAIL PROTECTED]> wrote: > I've just got to write my first form.clean method. I need to to do some > complex validation of different combinations of fields depending on the > setting of one other field. > > This works great until one or more of the individual field validations > fail. > > In my form.clean method I'm using the self.clean_data dict as already > filled in by the individual field.clean methods. This seems like the > way to go so as not to repeat the field validations. However, if a fild > validation fails an entry for that field is not made in the clean_data > dict, but an entry is added to the local var errors dict. > > Without testing for the presence of each value within clean_data, I see > no way of telling whether any individual field has failed it own > validation or not. As far as I am concerned, if any individual field > fails validation then there is no point in doing any more validation > for combinations of fields. There may be people who do want to do this > though. I see two solutions: > > 1) don't call form.clean() if any individual field validation fails > > 2) pass in the local errors[] dict populated from the field.clean() > calls into form.clean() so we can see if there were indeed any failed > fields and decide if we want to carry on validation in form.clean() or > not. > > Regards, > Gary. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
