Re: Final Multi-DB status Update
On Mon, Sep 14, 2009 at 12:16 PM, Alex Gaynor wrote: > > FWIW, Russ, Joseph Kocherhans, and I discussed this at the DjangoCon > sprints and our conclusion was to have syncdb only sync a single table > at a time, and to take a --exclude flag (or was it --include?) to > specify what models should be syncd. Did you mean to say "sync a single db" instead of "sync a single table"? Russ was talking about an --exclude flag at the sprints, but it doesn't really matter either way to me. 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: 1.2 Feature freeze
On Wed, Dec 23, 2009 at 2:34 AM, James Bennett wrote: > Technically, the major feature freeze for Django 1.2 was to have > happened sometime yesterday, US Central time. As of this moment, we're > not actually frozen, but will be as soon as I hear status reports on > the following (high-priority features which have not yet listed a > commit on the 1.2 features page): > [snip] > * GSoC-4 (model validation) I'd like to get this in. I have a current diff on my laptop that I'm going to review again on the plane this afternoon, but I don't think there's any development work that it needs. Merging the changes from multidb into the branch might take some effort, but I think Honza is willing to do that if we commit the branch to trunk. I'm going to have questionable internet connectivity until Monday, but if I can get online I'd like to check this in in the next couple of days. (I will have access to email on my phone though, so I'll watch this thread.) I don't want to break the schedule, but it'd be a shame to let this slip to 1.3. 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-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Finalizing model-validation: ComplexValidator
Model validation is just about ready to go. I have one small issue
with it, namely with ComplexValidator, which I'll describe below, but
I think we can resolve it fairly easily. Here's a bit of background.
Sorry if you're already familiar with the branch.
Validators are functions that are tied to fields. They take the
field's value, and raise a ValidationError if the value doesn't match
the validator's criteria. For example:
def validate_integer(value):
try:
int(value)
except (ValueError, TypeError), e:
raise ValidationError('')
Regular validators only have access to their field's own value, but
there's a second type of validator that is *also* tied to a field, but
has access to *all* of the cleaned form data, or the model instance,
depending on the context. When it raises ValidationError, the errors
are tied to that particular field instead of going into
non-field-errors like the form.clean() hook. It's this second type of
validator that I have a problem with, or rather, its implementation.
Right now, ComplexValidator's __call__ method perfoms the validation.
It takes obj, and all_values as arguments. Only one of them should be
provided. obj should be a model instance, all_values should be a
dictionary of cleaned data from a form. Here's the current
implementation:
class ComplexValidator(object):
def get_value(self, name, all_values, obj):
assert all_values or obj, "Either all_values or obj must
be supplied"
if all_values:
return all_values.get(name, None)
if obj:
return getattr(obj, name, None)
def __call__(self, value, all_values=None, obj=None):
raise NotImplementedError()
class RequiredIfOtherFieldBlank(ComplexValidator):
def __init__(self, other_field):
self.other_field = other_field
def __call__(self, value, all_values=None, obj=None):
if all_values is None:
all_values = {}
if self.get_value(self.other_field, all_values, obj) in
EMPTY_VALUES:
if value in EMPTY_VALUES:
raise ValidationError('This field is required if
%s is blank.' % self.other_field)
I have two reservations about this implementation:
The ComplexValidator doesn't know in advance if it's going to be used
for model validation or form validation. ComplexValidator's get_value
method is meant to help with this situation, but it needs to take
*both* the dict and obj values to get the value, and as such, it's a
little clunky.
The other problem I have with ComplexValidator is that your validators
must subclass it since we use isinstance checks to find them. It's
mostly a knee-jerk reaction. I can live with it, but it smells.
I know there was some discussion at EuroDjangoCon, and people seemed
OK with the current situation, but I'm -0 on leaving ComplexValidator
as-is. Here are a few options:
1) Drop ComplexValidator support for 1.2.
I think we could come up with a more elegant solution given some
usage and time. The branch is still incredibly useful even without
ComplexValidator.
2) Convert a model to a dict before passing it to ComplexValidator
so they always just deal with dicts.
This wouldn't address my discomfort with isinstance checks, but it
would make writing ComplexValidators a lot less clunky.
3) Leave ComplexValidator in as-is.
I don't need a whole lot of convincing that this is the way to go.
If we come up with a better solution later, ComplexValidator itself
would be fairly easy to deprecate.
4) You're awesome idea that has escaped me so far.
This will probably start with option 1, then we'd add the feature
after the branch is merged, or in the 1.3 timeline.
Does anyone have strong feelings about the way to go here?
Thank you Honza for all of your work on this code. It's a pretty
tricky problem, but we're almost there.
Joseph
Here are a few relevant parts of the code in case anyone wants to dig
in further.
ComplexValidator implementation:
http://code.djangoproject.com/browser/django/branches/soc2009/model-validation/django/core/validators.py#L139
ComplexValidator usage in model validation:
http://code.djangoproject.com/browser/django/branches/soc2009/model-validation/django/db/models/base.py#L810
ComplexValidator usage in form validation:
http://code.djangoproject.com/browser/django/branches/soc2009/model-validation/django/forms/forms.py#L293
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Finalizing model-validation: ComplexValidator
On Sat, Jan 2, 2010 at 4:34 PM, Sean Bleier wrote: > > As for the timeline, I think that if complex validators are left as-is > then of course it isn't a deal breaker for inclusion to trunk before > the major feature freeze on January 5th. However, If complex > validators need to be reworked a little, then I think we can exclude > them from the merge since you can do model wide validations through > the validate method on the model. Then maybe we can add the complex > validators before the complete feature freeze? Yeah, I think excluding ComplexValidators from the merge is the route I'm going to take. I have a couple more ideas about how they could work, but I need to focus on getting the branch merged. I'm planning on doing that Monday night. After it's in, I'll work on those ideas a little more and bring them up here. 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-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Finalizing model-validation: ComplexValidator
On Sun, Jan 3, 2010 at 7:34 PM, Alex Gaynor wrote: > > What if we had some sort of wrapper class for objs, it could overide > __getattribute__ to return either an attr if it's an obj, or a > subscript if it's a datadict. it seems to me this would solve both > concerns? I was thinking along similar lines, but with __getitem__ instead, basically just using a dict interface wrapping a model object, but that hides the model's methods. Honza makes a good point that those would be good to have access to. I feel a lot more comfortable treating a model like a dict than vice-versa, although that's admittedly rather arbitrary. 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-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Model validation incompatibility with existing Django idioms
On Wed, Jan 6, 2010 at 12:49 PM, Simon Willison wrote:
> A couple of related tickets filed today about model validation:
>
> http://code.djangoproject.com/ticket/12513
> http://code.djangoproject.com/ticket/12521
>
> The first one describes the issue best - the new model validation code
> breaks the following common Django convention:
>
> form = SecretQuestionForm( {"secret_question":"foo", "answer":"bar"} )
> if form.is_valid():
> p = form.save(commit=False)
> p.user = request.user
> p.primary_contact = somecontact
> p.save()
>
> The problem is that is_valid() notices that some of the required
> fields in SecretQuestionForm (a ModelForm) have not been provided,
> even if those fields are excluded from validation using the excludes=
> or fields= properties. The exception raised is a
> UnresolvableValidationError.
I'll start off with the reasoning behind the implementation, but I
agree that the current implementation is going to bite too many people
to just call the old implementation a bug.
Form.is_valid() now triggers model validation, and the model isn't
valid. It's missing a couple of required fields. Presenting those
errors to the user filling out the form is unacceptable because there
is nothing the user can do to correct the error, and the developer
will never get a notification about a problem that can only be solved
with code.
> This definitely needs to be fixed as it presumably breaks backwards
> compatibility with lots of existing code (it breaks a common
> ModelAdmin subclass convention as well, see #12521). Can we just
> change the is_valid() logic to ignore model validation errors raised
> against fields which aren't part of the ModelForm, or is it more
> complicated than that?
It shouldn't be much more complicated than that. Model.full_validate()
takes an exclude parameter that we can use to provide a list of fields
that aren't on the form. Or we can catch those errors and just throw
them away. However, this means that part of the problem that
model-validation was meant to solve will no longer be solved.
ModelForm.is_valid() will only mean that your *form* is valid, not
your *model* (which is the pre-merge semantics anyhow).
Once again, that means ModelForm won't really validate your model,
only your form. form.save() might still throw a database error just
like before the merge. We can slap a big warning in the ModelForm docs
though.
One (probably unhelpful) way to make ModelForm validate your whole
model would be to add a Meta flag to ModelForm:
class UserForm(ModelForm):
class Meta:
# Defaults to False
validate_model = True
That would make it easy to trigger model validation, but it doesn't
really help with the convention you're talking about. I don't know. Do
people think triggering model validation in a ModelForm is something
they need to do in a practical sense? Or is validating your form
enough?
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-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Model validation incompatibility with existing Django idioms
On Wed, Jan 6, 2010 at 3:26 PM, Waylan Limberg wrote:
> I've only scanned the docs the other day and haven't actually used the
> new model validation stuff, so my impressions may be a little off,
> but...
>
> On Wed, Jan 6, 2010 at 2:54 PM, Joseph Kocherhans
> wrote:
>> On Wed, Jan 6, 2010 at 12:49 PM, Simon Willison
>> wrote:
>>> A couple of related tickets filed today about model validation:
>>>
>>> http://code.djangoproject.com/ticket/12513
>>> http://code.djangoproject.com/ticket/12521
>>>
>>> The first one describes the issue best - the new model validation code
>>> breaks the following common Django convention:
>>>
>>> form = SecretQuestionForm( {"secret_question":"foo", "answer":"bar"} )
>>> if form.is_valid():
>>> p = form.save(commit=False)
>>> p.user = request.user
>>> p.primary_contact = somecontact
>>> p.save()
>>>
>
> My initial reaction to this snippet was to wonder why the model was
> not being validated after the additional data was added/altered.
> Shouldn't you be doing:
>
> form = SecretQuestionForm( {"secret_question":"foo", "answer":"bar"} )
> if form.is_valid():
> p = form.save(commit=False)
> p.user = request.user
> p.primary_contact = somecontact
> if p.full_validate(): # <<<<< note this line
> p.save()
>
> [snip]
There are a couple of problems with p.full_validate() there. First, it
would run validation a second time. Honza went to a bunch of trouble
in the design to make sure that each field would only need to be
validated once. Second, p.full_validate() would raise
ValidationErrors, not return True or False.
>> Once again, that means ModelForm won't really validate your model,
>> only your form. form.save() might still throw a database error just
>> like before the merge. We can slap a big warning in the ModelForm docs
>> though.
>
> Well, that's why I expected the extra validation check on the model
> itself. I understand the desire to have the ModelForm actually
> validate the model and work in one step, but sometimes we need the
> other way too (as you acknowledge).
>
>> One (probably unhelpful) way to make ModelForm validate your whole
>> model would be to add a Meta flag to ModelForm:
>>
>> class UserForm(ModelForm):
>> class Meta:
>> # Defaults to False
>> validate_model = True
>
> Well, what if one view uses that ModelForm one way and another view
> uses the same ModelForm the other way? What about
> ``form.is_valid(validate_model=True)``?
That's a possibility, but I think it suffers from the same problems
that the Meta option does. It just pushes the decision closer to
runtime than coding time. That's helpful in some cases, but it doesn't
solve the main part of the problem for me, which is that I don't think
model validation should be an opt-in-only thing. Maybe it needs to be
for a couple of releases though.
I had another idea that I think might work out. What if
ModelForm.validate() only validated fields on the form, like it worked
before the merge, and ModelForm.save() would automatically validate
the excluded fields, raising ValidationError if there was a problem?
Validation for each field would only happen once, it would accommodate
the commit=False idiom, and it would still ensure that the model
itself is validated in common usage.
I think this *might* also lead to a workable solution for ticket
#12507 [1], but I need to dig into the code a little more.
Joseph
[1] http://code.djangoproject.com/ticket/12507
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Model validation incompatibility with existing Django idioms
On Wed, Jan 6, 2010 at 4:46 PM, Jeremy Dunck wrote:
> On Wed, Jan 6, 2010 at 3:56 PM, Joseph Kocherhans
> wrote:
> ...
>>>> On Wed, Jan 6, 2010 at 12:49 PM, Simon Willison
>>>> wrote:
> ...
>>>>> form = SecretQuestionForm( {"secret_question":"foo", "answer":"bar"} )
>>>>> if form.is_valid():
>>>>> p = form.save(commit=False)
>>>>> p.user = request.user
>>>>> p.primary_contact = somecontact
>>>>> p.save()
> ...
>> I had another idea that I think might work out. What if
>> ModelForm.validate() only validated fields on the form, like it worked
>> before the merge, and ModelForm.save() would automatically validate
>> the excluded fields, raising ValidationError if there was a problem?
>> Validation for each field would only happen once, it would accommodate
>> the commit=False idiom, and it would still ensure that the model
>> itself is validated in common usage.
>
> Note that p in the example above is the unsaved model instance, not
> the ModelForm. So to fix the idiom, the excluded field validation
> would need to be done on Model.save, not ModelForm.save, right?
Ugh. Yes it would. I did mean ModelForm.save(), but as you've pointed
out, that won't work (at least for the idiom). One of the early
decisions was that Model.save() would never trigger validation for
backwards compatibility purposes. Maybe something from the idea is
salvageable, but it won't work as I presented it. I think having the
model track which validators have been run and which haven't is a
non-starter. That's something Honza actively avoided in the design.
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-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Model validation incompatibility with existing Django idioms
On Wed, Jan 6, 2010 at 12:49 PM, Simon Willison wrote:
> A couple of related tickets filed today about model validation:
>
> http://code.djangoproject.com/ticket/12513
> http://code.djangoproject.com/ticket/12521
>
> The first one describes the issue best - the new model validation code
> breaks the following common Django convention:
>
> form = SecretQuestionForm( {"secret_question":"foo", "answer":"bar"} )
> if form.is_valid():
>p = form.save(commit=False)
>p.user = request.user
>p.primary_contact = somecontact
>p.save()
>
> The problem is that is_valid() notices that some of the required
> fields in SecretQuestionForm (a ModelForm) have not been provided,
> even if those fields are excluded from validation using the excludes=
> or fields= properties. The exception raised is a
> UnresolvableValidationError.
OK. I've attached a patch for another shot at this to #12521 [1].
form.is_valid *should* act like it did before the model-validation
merge. This is trickier than it sounds though, and there are probably
a few more corner cases. ModelForm validation uses validation from
model fields and validators, not just the form fields, so simply
skipping validation for excluded fields isn't enough.
model.full_validate() is *only* for validating an entire model. It
calls validate_fields, validate_unique, the the validate hook in
order.
model.validate_fields(fields=None)
Validate the fields specified, or all fields if fields is None. fields
should be a list of field names.
model.validate_unique(fields=None)
Validate the uniqueness of the specified fields, or all fields if
fields is None. fields should be a list of field names.
form = SecretQuestionForm( {"secret_question":"foo", "answer":"bar"} )
if form.is_valid():
p = form.save(commit=False)
p.user = request.user
p.primary_contact = somecontact
# You probably won't actually want to run model validation this
# way, but hopefully this shows what ModelForm isn't doing.
try:
# Run validation that was missed by the form.
p.validate_fields(fields=['user', 'primary_contact'])
p.validate_unique(fields=['user', 'primary_contact'])
p.validate()
# Or run *all* validation again.
p.full_validate()
except ValidationError, e:
pass
# I don't know how you'd even really recover from error here.
# it's too late to show any form errors. At least you
# know your model is valid before saving though.
p.save()
Thoughts?
Joseph
[1] http://code.djangoproject.com/ticket/12521
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Model validation incompatibility with existing Django idioms
On Sat, Jan 9, 2010 at 6:25 PM, Ivan Sagalaev wrote: > Joseph Kocherhans wrote: >> >> # Run validation that was missed by the form. >> p.validate_fields(fields=['user', 'primary_contact']) >> p.validate_unique(fields=['user', 'primary_contact']) >> p.validate() > > Can this be shortcut to > > p.full_validate(fields=['user', 'primary_contact']) > > ? > > If not, why not? :-) Hmm... I guess I'm -0. The caveats with that validate_unique method are such that I'd rather not abstract it behind something else. I don't think you'd want to pass the same fields to validate_fields and validate_unique in most cases. Also, it doesn't make a whole lot of sense to call validate unless you're validating everything, so we'd have to document that as well. In practice, I don't think people will do this a whole lot, so 3 method calls shouldn't be a big deal. We can always add it later if people really need it in practice. 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-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Model validation incompatibility with existing Django idioms
On Wed, Jan 6, 2010 at 12:49 PM, Simon Willison wrote: > A couple of related tickets filed today about model validation: > > http://code.djangoproject.com/ticket/12513 > http://code.djangoproject.com/ticket/12521 This has been fixed in r12206 [1]. Could people who had issues please check things out again and let me (or trac) know if you find any regressions? I think Honza and I managed to hit most of the ones that had tickets, but there were quite a few corner cases that had to be fixed in this changeset. I specifically added a test for the commit=False idiom, but I'm sure people have more complicated scenarios out there. Joseph [1] http://code.djangoproject.com/changeset/12206 -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Backwards-incompatible change for model validation
I just committed r12206 [1] which contains a few backwards-incompatible changes to model validation. First off, ModelForm used to validate your entire model and raise UnresolvableValidationError for any model fields that had errors, but were excluded from the form. Now, ModelForm will only validate the fields present on the form. This should mimic the pre-merge behavior. Also, to be more consistent with forms, model.full_validate() was renamed to model.full_clean() and model.validate() was renamed to model.clean(). You'll have to rename those methods and calls if you've already started using them. model.clean() is still called as part of ModelForm validation, but it now does nothing by default. It used to call model.validate_unique(), but that call has been moved up to the model.full_clean() method. This means that you can still start using at least part of model validation without having to tell your ModelForm about it, or alter your views. Sorry for the problems, folks. Thanks, Joseph [1] http://code.djangoproject.com/changeset/12206 -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Model validation incompatibility with existing Django idioms
On Tue, Jan 19, 2010 at 1:04 AM, Raffaele Salmaso wrote: > Raffaele Salmaso wrote: >> Joseph Kocherhans wrote: >>> regressions? >> http://code.djangoproject.com/ticket/12577 > Hello, is anybody out there? > Sorry if I seem rude, but there is a severe regression an no one care to > say at least 'ok I see it', even when there is an *explicit* request for > regressions... > I've resolved with an horrible monkeypatch, but at least I've now a > working copy of django Ok. I see it. ;) Sorry, I've been out of town for a while with no internet access. 12577 is near the top of my list to look at. 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-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Ticket disposal
On Mar 2, 2010, at 4:28 PM, Peter Sagerson wrote: > Hello, > > I submitted a patch[1] for 1.2 which was not accepted and almost certainly > won't be in the future. This is perfectly fine, but it would be nice to get > the bug closed wontfix so we have some closure (people are still adding > themselves to the cc field). I just moved it to the 1.2 milestone with the > intention that it would get swept up in a 1.2 cleanup, but that was > apparently not the correct approach, as it was immediately reverted. The > documentation is clear that I can't close it myself. As it stands, this > ticket threatens to linger indefinitely. Can anyone advise on the correct > procedure here? Hey Peter. Did you ever end up making an external project for your LDAP patch? If you did, it would be cool to have a link to it in the ticket. I think a third party project is the best place for it. Feel free to close the ticket and point to this thread or say "because jkocherhans said so" in the comments. Pinging django-dev is probably the best way to handle stuff like this. I hope you have created or do create a project for it since there is obviously interest. but since it can live outside of Django itself just fine, it probably should. Sorry I didn't reply to you message awhile back [1]. Thanks, Joseph [1] http://groups.google.com/group/django-developers/msg/8b354ab4e5d4724b -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: What about union() and intersection()
On 5/5/06, Michael Radziej <[EMAIL PROTECTED]> wrote: > > what about providing class functions QuerySet.union(cls, qset_list), > QuerySet.intersection(cls, qset_list), both returning cls, such as: > > def union(cls, qset_list): > """Returns the union of a list of QuerySets, a QuerySet.""" > return reduce(cls.__or__, qset_list) > > union = classmethod(union) > > A class method, since you might want to subclass QuerySet (I do). > > I found myself needing this a lot, and I think this might be nice for > everyone. If you like the idea, I'll provide the patch. That would be pretty cool. You might want to include a way to do union all as well as just union. I generally use the latter as it's supposed to be faster for most (probably all) databases... that and I'm not expecting duplicates for most union queries in the first place. 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: Patch to make unit testing applications easier/faster
On 5/5/06, Victor Ng <[EMAIL PROTECTED]> wrote: > > I've never submitted code to Django before - what can I do to help > make this patch go in to the trunk? I've run the Django testsuite > with all passes, but I'm not sure if I should do anything else. That's pretty much it. Now it's just waiting time until one of the core devs has a chance to review it. (Everyone is pretty busy trying to get a new release out right now.) They'll comment on and/or close your ticket if soemthing's wrong. In the meantime you may find this interesting: http://www.djangoproject.com/documentation/contributing/ 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 -~--~~~~--~~--~--~---
branch request: new-auth
I'd like to get a branch started for the new authentication stuff I've been working on. A current patch is attatched to ticket #1428. This will make a easier for people to test this out, and give more feedback so I can get the docs up to speed. 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 -~--~~~~--~~--~--~---
#1767 validator_list silently deleted for BooleanFields
If this ticket could get some quick love I'd much appreciate it. Something is definitely wrong, but is the patch acceptable? http://code.djangoproject.com/ticket/1767 I brought it up on the list last week, but no one seemed to have an opinion, or it just got missed. http://groups.google.com/group/django-developers/browse_frm/thread/ec0a5a8585c2ee3a/58c264ec3a34d349?q=BooleanField&rnum=6#58c264ec3a34d349 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 -~--~~~~--~~--~--~---
svn merge problem
I'm trying to merge changes from the trunk into the multi-auth branch. svn merge --dry-run -r 2892:HEAD http://code.djangoproject.org/svn/django/trunk works fine, but when I try to do it for real: svn merge -r 2892:HEAD http://code.djangoproject.org/svn/django/trunk svn barfs with the following: svn: Copyfrom-url 'http://code.djangoproject.org/svn/django/trunk/django/conf/locale/el/LC_MESSAGES/django.mo' has different repository root than 'http://code.djangoproject.com/svn' Anyone seen this before? A google search seems to suggest that it's a problem adding new files, the merges seem to work fine. Do I need to manually copy new files from the trunk before merging? Joseph P.S. svn merge --ignore-ancestry --dry-run http://code.djangoproject.org/svn/django/branches/[EMAIL PROTECTED] http://code.djangoproject.org/svn/django/[EMAIL PROTECTED] Seems to do the wrong thing entirely. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
ANN: multi-auth branch ready for testing
Anyone interested in mutiple authentication backends should check out http://code.djangoproject.com/wiki/MultipleAuthBackends I've updated the authentication docs to cover the new changes, and the code is ready to go. A self proclaimed newbie has already posted an example LDAP backend to the wiki, so it shouldn't be too hard to get things up and running. Please ask if you have any questions. I'll do my best to answer them quickly. At this point only 2 backends are included, one that checks django.contrib.auth.models.User, and one that checks against a username and hashed password variable in your settings.py file. The latter might not make it into the trunk... I'll leave that call to Adrian and Jacob. As far as other backends go, please post them to the wiki for now. I'm not sure whether or not LDAP, OpenID support, etc. will be included in Django proper, but it would be nice to have them available. 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: ANN: multi-auth branch ready for testing
On 5/16/06, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: > perhaps the settings.py auth > backend might make better example code (perhaps in the "writing auth > backends" doc?) since it's actually pretty insecure :) Good call. Done in [2924] 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: [AUDIT] Enable Django Quick Start / Database Evolution Support
On 5/25/06, lazaridis_com <[EMAIL PROTECTED]> wrote: > > At this point, Django's persistency layer seems intresting, but the > evaluation uncovered a few weaknesses, most importantly the lack of > schema evolution support: > > http://case.lazaridis.com/multi/wiki/DjangoProductEvaluation Schema evolution support has already been discussed at length. See: http://code.djangoproject.com/wiki/SchemaEvolution but it's not implemented yet. You also may want to add SqlAlchemy to your list. It's pretty cool, although in the early stages of development. There's a Google Summer of Code project just starting to add schema evolution support to SqlAlchemy as well. > Overview of resulting simplification issues: > > * Replace command "django-admin.py" by "django-admin" or "django" > * Replace command "manage.py" by "django" These are kind of appealing to me, but my inner skeptic just screams "name churn". Adrian Holovaty is the final word on things like this though. > * Enable sqlite3 database / filename by default I personally wouldn't want this. Where do you propose putting the database file? I *always* use absolute paths for sqlite db's. If you use relative paths, it's relative to your current directory, not relative to the location of the settings file. This could get really confusing for newbies if they execute manage.py from a different working directory. > * Externalize database settings (e.g. dbdefault.py) You can do this already... that's the beauty of using python for settings. Just import * or whatever from the appropritate module in your main settings file. > * Enable Admin application by default This has been discussed and dismissed serveral times already. > * Create a superuser by default (e.g. user:admin / pass:django) -1. The slight convenience doesn't make up for the security implications IMO. > * Rename "startapp" to "createapp" Once again, name churn. > Solving those Issues would allow to produce a Django-Quick-Start which > could be taken within 5 minutes (+ Installation Effort), which would > allow intrested parties to come quickly in contact with Django. You could provide your own project skeleton that would take care of all of this. There's no real need to change Django to accomplish any of the items above. I'd argue that splitting out the database config makes things *more* complicated. Part of the beauty of django is that it doesn't (in the paraphrased words of someone else, I forget who) "shit all over your filesystem like rails" > I would be intrested to creat a skeleton for the "Database Schema > Evolution" (I have implemente a very simply one for a Ruby ORM). See the link above. > To do so, I would need some feedback from the developers list. > > Can I rely on this? People are generally pretty helpful, but skeptical here. You generally need code and use cases to back up your ideas. Like any open source project though, we all work for free, so no promises. Thanks for taking the time to write all of this up. Everyone here pretty much has the current way things work engrained in our brains at this point and it's nice to see other perspectives. Your quick start looks promising. I hope you keep working on it. 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 -~--~~~~--~~--~--~---
SoC 2006: Generic Authorization
I've posted an intial revised version of my summer of code proposal at: http://code.djangoproject.com/wiki/GenericAuthorization This should go hand in hand with Chris Long's RowLevelPermissions project: http://code.djangoproject.com/wiki/RowLevelPermissions Also, for the curious, you can see the other accepted proposals for Django at: http://code.google.com/soc/django/about.html Please post any comments to the list. I'm really excited... we're going to see some cool things in django-land in the next few months (not like there hasn't already been lots of cools stuff though ;) 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 -~--~~~~--~~--~--~---
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 -~--~~~~--~~--~--~---
branch request: generic-auth
I'd like to get a branch started for my summer of code project. It's not urgent, but something in the next couple of days would be great. http://code.djangoproject.com/wiki/GenericAuthorization 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: Merging multi-auth to trunk?
On 6/23/06, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: > > Time for yays or nays to merging the mutli-auth branch into trunk... > I've been running it for a few weeks without any problems, so I'd say > it's pretty much stable. +1 (for merging that is) I still want to refator the config code to match the config changes in [2927], but it's fine if that happens after the merge. 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: ANN: multi-auth merged to trunk
On 6/28/06, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: > > Just a quick note that I've merged Joseph's multi-auth branch to > trunk. As far as I've seen over the past few weeks this doesn't > break anything, but if it does let me/him know. > > Thanks, Joseph. No problem. Now I get to move my projects back to the trunk, or more likely over to the generic-auth branch ;) 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 -~--~~~~--~~--~--~---
Proposal: app-specific index pages
I finally wanted it bad enough to code it. Here's the patch. The template tags could use a little cleanup which I'll finish off if Jacob and Adrian give this the green light. I copied and pasted some code :( http://code.djangoproject.com/ticket/2292 A couple of issues: - Should the app names on the admin index page be links? It seems a little goofy, but it's the most obvious place. A small css adjustment is in order if they do change to links. - What should the table caption be on the app-specific index pages? Using the app name is redundant, and using "Models" seems wrong as well. Most users of the admin system don't care/know what "models" are. Leaving the caption out entirely looks wrong to me. Maybe Wilson has some ideas? I can post a few screenshots if people want to see what I'm talking about w/o having to apply that patch. 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: Enabling Row Level Permissions
Sorry it took so long to respond. Busy week.
On 7/8/06, Chris L <[EMAIL PROTECTED]> wrote:
>
> I've currently set up enabling row level permissions using the meta
> class, e.g. to enable row level permissions for the Mineral model you
> would have:
>
> class Mineral(models.Model):
> name = models.CharField(maxlength=150)
> hardness = models.PositiveSmallIntegerField()
>
> class Admin:
> pass
>
> class Meta:
> unique_together = (('name', 'hardness'),)
> row_lvl_perms = True
I was actually thinking of having a Meta attribute like 'checker' or something.
from django.contrib.auth.checkers import RowLevel, ModelLevel
class Mineral(models.Model):
name = models.CharField(maxlength=150)
hardness = models.PositiveSmallIntegerField()
class Meta:
checker = RowLevel
# or use ModelLevel
This should allow for other types of permission checking to be
registered without adding a new attribute for each one. For now, the 2
options for checker could just be basically flags to check... I forget
what this is called at the moment, but something like:
ModelLevel, RowLevel = 1, 2
Later on, the checker attribute would actually cause something to get
registered a la the generic authorization stuff I'm working on. If
checker is not specified, it would default to ModelLevel.
My ideas regarding this are pretty half-baked at this point, but it's
something to consider.
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: Re: Enabling Row Level Permissions
On 7/14/06, Chris Long <[EMAIL PROTECTED]> wrote: > > How would you handle multiple checkers? I'm designing RLP to work on > top of model level checking. Would it be: I actually hadn't thought of that. I thought there would be one and only one type of checking for each model. I can't think of a use case for multiple checkers, but then again it's Friday and my brain is a little fried :) > One thing that will need to be done if it is decided to go this way, > is that RLP needs a relation to be generated in the ModelBase __new__ > method, it would have to changedfrom what I currently have. > > I think we need to have a conversation about this (on the mailing list > or IRC channel, to get more input). I'm at the point now where I need > to work on integrating checking of row level permissions and into the > admin interface. I'd prefer making any changes to have our two systems > work together now rather then redoing it after I've integrated it. I think this part could be pretty simple. I'm planning on changing all the permission checks in the admin system from (for example) if not request.user.has_perm(app_label + '.' + opts.get_change_permission()): raise PermissionDenied to something like: from django.contrib.auth import has_permission permission_name = app_label + '.' + opts.get_change_permission() if not has_permission(request.user, permission_name, obj): # feel free to exclude obj arg for add perms, obj doesn't make sense in that case raise PermissionDenied I think if you wrote a has_permission function that only dealt with model level and row level permissions, and then changed the admin system to use it, integration later on with the generic auth stuff would be almost trivial (at least as far as actual permission checks are concerned.) You could exclude the obj argument for things like add permissions where obj really doesn't make sense. This will only work for checking individual objects however. For the change lists, a custom manager is a better option than checking permissions on each individual object after it has been returned. You would have to explicity pass the user or the user's id into that manager method though. There won't be any kind of implicit security, which is really how django works now anyhow and is fine with me. Hmm... (random thought here) what if managers all grew a resrtict method that took a user object and a permission? (The admin system would only need to worry about 'change', but arbitrary permissions should be possible) Row level resrictions on QuerySets could be localized there. Later on other types of restrictions could be added via registration (similar to the generic has_permission function I'm working on.) 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: Generic Authorization Questions
On 8/3/06, Chris Long <[EMAIL PROTECTED]> wrote: > 1) Will there be any support for the previous method of checking > permissions? (e.g. will users.has_permission work?) I was planning on keeping the User.has_perm method around for now, but I think it ought to go away before 1.0. It won't be called anymore in any of Django's code by the time I'm finished. > 2) How are the two of us going to integrate our two systems? I mostly > have final testing and making the admin interface for editing row level > permissions left and then it's integrating them into the > permission/auth system. I have a few ideas, but we should really have a > long conversation about this and decide who si doing what and how so we > can maximize both our features. Sooner rather then later. :D Agreed. I'll hang out on #django for awhile tonight if you're available. I'll plan on being there from 7-11pm MDT off and on. If I'm not there I won't be gone for long. my nick is jkocherhans > 3) More a little mistake, in your patch you have in the main admin > views file: > > if not has_perm(request.user, app_label + '.' + > opts.get_delete_permission(), obj): > > probably meant has_permission. Yep. On top of that, all of those permissions strings that get passed in will need to change to actual permission objects. I wrote a bunch of the admin code last night, but didn't get around to testing it. Probably tonight. Thanks for pointing it out. 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: Re: Generic Authorization Questions
On 8/3/06, Chris Long <[EMAIL PROTECTED]> wrote: > > I'll try to be on tonight between 7 and 11 MT, I just finished off a 4 > hour meeting and need to finish off some work then head home. I might > be too tired to make it on tonight, but I'll certainly try. No problem. I'll be around tomorrow morning if tonight doesn't work for you. No sense in forcing a tired brain to deal with this. I've made a bunch of updates to the patch now if you want to check it out again. I've got everything working in the admin system now but cascading deletes. 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: Re: Model inheritance redux
On 8/4/06, Bjørn Stabell <[EMAIL PROTECTED]> wrote: > > Just a question; how does this compare pros and cons with single-table > inheritance, used in Rails? See: > > http://twelvelabs.com/singletable/index.html http://www.objectmatter.com/vbsf/docs/maptool/ormapping.html Check out the section on Horizontal Mapping vs. the one on Filtered Mapping. Also, there's a good explanation in Martin Fowler's Patterns of Enterprise Application Architecture. In short: STI is theoretically faster, but you can't really enforce db-level integrity constraints. The proposed implementation is theoretically slower (can involve a lot of joins for deep class hierarchies), but not null and foreign key contraints can actually be enforced at the db level. Those are the main points I remember, but there are many more. 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: Re: Row Level Permissions Update
On 8/17/06, Joe <[EMAIL PROTECTED]> wrote: > > I'm not sure if this is more relevant to the Generic Authorization > branch, but has anyone looked at implementing the owner permissions > (the user who creates the object automatically has delete/modify > permissions)? This is something that should be possible after generic-auth is done, but I don't think anyone is currently working on it. 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 -~--~~~~--~~--~--~---
generic-auth and per-object-permission integration
So I should probably get started on the generic-auth and per-object-permissions (hereafter pop) integration soon. I've had problems trying to merge changes from the trunk into the generic-auth branch, so I'd just assume call that branch dead. The actual generic-auth code is just a patch to the trunk [1] The easiest way integrate the two would probably be for me to patch the per-object-permissions branch. I suppose the other option, for the anal-rentively inclined, (which very often includes me ;) would be to start a new-auth branch, merge the pop changes to it (or even copy the existing pop branch, yeah, ick.), and apply the generic-auth patch to it. This sounds like a total pain in the ass to me. /me grumbles something about his love/hate relationship with svn, specifically merge I am presupposing that gen-auth and pop should be merged together before they get merged to the trunk. If you disagree, let me know. So there's the logistics. Here are the rest of the plans for getting this into the trunk. After the two codebases (gen-auth/pop) are integrated, I plan to refactor out a couple of functions from the django.contrib.models.User.has_perm method in the pop branch. After that, the has_perm method should die. (Some other User methods may suffer a similar fate) I'll put in some backwards compatibility code (that *doesn't* support pop), but I think it should be gone by 1.0. I also want to take a look at how the Meta attributes work for activating this stuff. I'd like to make it a little more generic, but I'll bring it up again after I've taken a look at the code. Thoughts, comments? Joseph [1] http://code.djangoproject.org/attachment/wiki/GenericAuthorization/generic-auth.diff --~--~-~--~~~---~--~~ 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: generic-auth and per-object-permission integration
On 9/1/06, Linicks <[EMAIL PROTECTED]> wrote: > > Once (gen-auth/pop) are merged, what are the major barriers in getting > that branch merged into trunk? Probably just review by Jacob and Adrian. There are several branches from summer of code that will be competing for their attention over the next few months. The best thing people can do to speed up the process is test the branches and report your successes and problems. 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: Re: generic-auth and per-object-permission integration
On 9/6/06, Linicks <[EMAIL PROTECTED]> wrote: > > I'm planning to move my development work to the pop/gen_auth branch > once they are merged. Hopefully I will be able to give some good > feedback at that point. When the merge is complete, would it be > possible to have you guys merge with trunk fairly regularly? As long as svn behaves iteself I plan on merging at least once a week. At least unless there are a huge set of changes that need to be merged manually. 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: Re: authentication data
On 9/11/06, Gary Wilson <[EMAIL PROTECTED]> wrote: > > Are you guys also planning on > removing the admin application's dependence on > contrib.auth.models.User? That's my long-term goal, but generic-auth isn't enough to get there. is_staff, is_superuser, is_active, get_and_create_messages, and probably other things need to be changed for that to happen. generic_auth just takes care of user.has_perm. That said, I don't see all of this happening for at least a couple of months. Getting the per-object-permissions and generic-auth branch merged together, then merged to the trunk will come first, and I expect that will take at least a month. 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: Why request.user is a class attribute
On 9/11/06, Ivan Sagalaev <[EMAIL PROTECTED]> wrote: > > I've just found out that request.user is an attribute of request's class > not of an instance. Which means that in the environment with multiple > requests (threaded or not) every request.user always points to a single > LazyUser instance which is obviously a bad thing. What was the reason > for this decision? It may look like a class attribute, but it's not. LazyUser has overridden __get__, so request.user is a descriptor, not a plain old attibute. It *must* be assigned to the class, and not an instance, or __get__ will not be called. You can google python descriptors for more info. 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: Re: Why request.user is a class attribute
On 9/11/06, Joseph Kocherhans <[EMAIL PROTECTED]> wrote: > On 9/11/06, Ivan Sagalaev <[EMAIL PROTECTED]> wrote: > > > > I've just found out that request.user is an attribute of request's class > > not of an instance. Which means that in the environment with multiple > > requests (threaded or not) every request.user always points to a single > > LazyUser instance which is obviously a bad thing. What was the reason > > for this decision? > > It may look like a class attribute, but it's not. LazyUser has > overridden __get__, so request.user is a descriptor, not a plain old > attibute. It *must* be assigned to the class, and not an instance, or > __get__ will not be called. You can google python descriptors for more > info. Hmm... looking into this more, Ivan was right... kind of (and maybe this is what he meant, but it's not how I read it, sorry if I misunderstood). I did a simplified descriptor test and found that the current code *does* act more or less like a class attribute. I've created a new ticket with a patch that fixes the problem. The cached user is currently stored as an attribute of LazyUser, but should be stored as an attribute of the request. http://code.djangoproject.org/ticket/2702 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: Proposal: Forms and BoundForms
I've been working on the same thing, but my ideas differ slightly from
Adrian's. In a lot of way we're on the same page though, so that much
is encouraging :) I've liberally stolen ideas from both FormEncode and
a version of Zope 3's formlib.
There are four main classes the mostly correspond to Adrian's
proposal. I've spelled out some of the details below.
=Field (unboud field)=
Field classes are just validator/converters similar to FormEncode.
They have a from_python(python_data) and a to_python(raw_data) method,
and their state consists only of configuration (i.e. they are not
bound). Validation and conversion happens in one step any time
from_python or to_python are called. If validation fails, a
ValidationError is raised. Extra validation will probably be setup by
a validator_list argument in the Field constructor. validator_list is
just a list of validator functions like we already have. I think we
could create a validator that delegates to the appropriate
django.db.fields class to avoid duplication of logic with validation
aware models.
=Fields (unbound form)=
Rather than a Form class, I've come up with a Fields class (or maybe
FieldCollection, but that sounds javaish) that is similar to a
FormEncode Schema class. I think Fields or something similar is a lot
more clear than Form, since this is really just a collection of fields
that do validation and conversion. Form seems like something that gets
displayed, but there is *no* display logic here at all. It has
from_python and to_python methods as well so it can be nested like
FormEncode Schema classes can. from_python and to_python just take and
return a dict of name value pairs.
=Widget (bound field)=
Widgets actually hold the data that was submitted from a form, and
probably the errors (if any) as well. It has an associated unbound
Field instance. It can display itself as html (via render() or
__str__()) It also knows what POST var name it corresponds to, so it
can get the raw value from the post data, and pass it to it's field's
to_python method. (I'll talk about the importance of this later.) It
also knows what it's verbose name is.
=Form (bound form)=
This is the part I'm least clear about. It should be able to render
itself, or present attributes for use in a template to do totally
custom html. At any rate, we'd need some sort of widget setup
function/method that takes a model, a collection of fields, and the
POST data, and returns an ordered dict (or something similar) of
widgets. This class/method would be the only point where this whole
library would necessarily be coupled to Django, and it should be
possible to write a similar setup function for SQLAlchemy Mappers,
etc.
You should also be able to set a prefix on the form. It would be
prepended to every html variable name. That way we could support
multiple instances of the same type of form on one page. (Extending
this idea might also get us to generic edit_inline behavior.) This is
where widgets knowing their html var name comes in handy.
=Creating Forms=
Well it should be possible to do it declaratively or imperatively. I'm
thinking that field collections or widget collections should act kind
of like query sets in that we could do something like
fields.exclude('name') and get a field collection back that has the
'name' field excluded. This behavior could also be extended to work
with Forms declaratively.
=Errors/Exceptions=
I would also like to see some of the validation ideas that have been
floating around implemented. All this is kind of pie-in-the-sky, but I
want it anyhow :)
I see 3 types of validation exceptions: ValidationWarning,
ValidationError, and FatalValidationError. Keep in mind that I'm
talking about the default behavior when I talk about aggregating
catching and re-raising errors.
ValidationWarning would be used to trigger additional fields/messages
to appear in a BoundForm (or equivalent) and would not be raised if
certain criteria are met (most likely a specifically named boolean
value was present in the data we're converting/validating) Haven't
thought about how to actually configure the messages, etc. however.
ValidationError is pretty much what we have now. Validation continues
even if this is raised. They are aggregated into some sort or dict
like wrapper, and re-raised in each Field collection's to_python
method. The (bound) form can then catch and store it as an attribute.
FatalValidationError - this one should short-circuit all other
validation by default.
=What else?=
There should be a way to specify a custom widget class for a particular field.
There's also the question of validation that is not tied to a
particular field. This could be useful, but does it need to be
included?
Anyhow, I hate to make the discussion more convoluted, but I'd really
like to see most of this implemented. Sorry if some of it is a little
vague or poorly worded... the ideas are still a work in progress, but
seeing Adrian's proposal helped support some of my de
Re: Proposal: Forms and BoundForms
On 9/12/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> Hence, with this new API, the above view code would be written like this:
>
> form = ContactForm()
> if request.method == 'POST' and form.is_valid(**request.POST):
> send_email_and_redirect()
> return render_to_response('email_form.html', {'form':
> form.bind(**request.POST)})
Hmm... taking some ideas from Russ Magee, what about this:
form = ContactForm()
if request.method == POST and form.bind(request.POST):
send_email_and_redirect()
return render_to_response('email_form.html', {'form':form})
Assumptions: form.bind(data) does *not* return a BoundForm. bind does
the validation and probably populates form.errors or .errors() or
whatever. bind returns True or False depending on whether validation
succeeded or not. bind does not short circuit on the first error.
Validation happens only once, in the bind call. It's not entirely
obvious that a method called bind would return a boolean depending on
the success of validation, but examples and docs should clear that up
that I think. Maybe this is being too clever to save a couple of lines
or a few milliseconds though.
Just for good measure, here's what it would look like to use a change form:
address = Address.objects.get(address_id)
form = AddressChangeForm(address)
if request.method == POST and form.bind(request.POST):
# save the object and return a redirect
return render_to_response('email_form.html', {'form':form})
You pass the original object into the form constructor. The form
values are then initialized with values from the original object. When
you call bind, it overwrites the form values with the data passed to
bind.
Let me know if this doesn't make any sense. I may have forgotten to
write down some essential assumptions.
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: Re: Proposal: Forms and BoundForms
On 9/13/06, Ivan Sagalaev <[EMAIL PROTECTED]> wrote: > > Joseph Kocherhans wrote: > > Assumptions: form.bind(data) does *not* return a BoundForm. bind does > > the validation and probably populates form.errors or .errors() or > > whatever. bind returns True or False depending on whether validation > > succeeded or not. bind does not short circuit on the first error. > > > > Validation happens only once, in the bind call. It's not entirely > > obvious that a method called bind would return a boolean depending on > > the success of validation, but examples and docs should clear that up > > that I think. > > It shouldn't be called 'bind' then. Agreed. Your suggestion of 'process_data' makes more sense in fact, I like that, but I'd shorten it to just 'process'. It would do both binding and validation. > Binding makes sense for the original > Adrian's proposal with two kinds of forms. Bind still makes sense with only one kind of form, it just works differently. Rob Husdon's recent post is a good example of why. It may be something as simple as this though: def bind(data): self.bound_data = data 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: Re: Proposal: Forms and BoundForms
On 9/13/06, Rob Hudson <[EMAIL PROTECTED]> wrote: > > (I'm not an official "dev" so I hope it's not considered inappropriate > of me to provide my feedback.) It's not inappropriate at all. :) > Instead of the assumption that bind() validates, why not have an > is_valid() method that assumes binding of the Form. To me this is a > more appropriate assumption since you have to bind the form to validate > it. And it leaves some flexibility open so you can bind forms and not > yet validate -- say if you want to bind and do some other form actions > and then validate. [snip] > form = ShoppingForm() > if request.method == POST: > form.bind(request.POST) > if form.billing_same_as_shipping == True: > # Copy billing info to shipping > form.shipping = form.billing > if form.is_valid(): > ... You make a good point. I was focusing on the simplest case in my example, but we might as well spell out how more complex cases would work. I think having separate mehods - 'is_valid', 'bind', and probably 'process' as well (that does both, see my response to Ivan Sagalaev) - would be a good idea. 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: app name in admin breadcrumbs
On 9/18/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Is there a reason why the app name doesn't appear in the admin > breadcrumbs? I have an app with a model called 'Groups', and the > breadcrumb for it is the same as that for the auth model 'Groups'. The > URL is right, of course, I just thought it might be sensible to stick > the app name in there, so I'd have home -> deptinfo -> Groups and home > -> auth -> Groups. There's a patch to do this if you want to try it out. It works with revision 3534, and probably with later versions as well, although I can't promise anything. I haven't updated or tested it since 3534. http://code.djangoproject.org/ticket/2292 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: Re: Why doesn't models.Manager implement __iter__?
On 10/10/06, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > > So now I'm just confused as to what might be "best". Certainly two sides > to this. I probably prefer the current consistency a little more, but > then there's iterator(). So I'm going to do the professional thing here: > hope that Adrian or Jacob has a strong opinion. There was a big argument about this, and IIRC Adrian settled it by deciding on the .all(). This is one of the main threads regarding the issue: http://groups.google.com/group/django-developers/browse_frm/thread/f64127c9b63e2ae5/e1876a953c1a1da3?lnk=gst&q=QuerySet+objects.all()&rnum=3#e1876a953c1a1da3 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: Re: Why doesn't models.Manager implement __iter__?
On 10/11/06, Gábor Farkas <[EMAIL PROTECTED]> wrote: > > (i'm not sure i understand what you mean by "iterator protocol") The "iterator protocol" basically refers to __iter__() and next(). Its the stuff that python calls behind the scenes when you iterate over something. http://docs.python.org/lib/typeiter.html 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: Call for testing: New setup.py
On 10/16/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > > But I have only tested this on Linux, so I'd appreciate it if folks > could test out the command "python setup.py install" on various > different platforms. Just grab the SVN version of Django and try > installing it using "python setup.py install". Works fine with OS X 10.4.8 (PPC) + python 2.4.3 via darwinports. 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: Re: Django - Oracle status?
On 10/16/06, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > > The good news here is that in "from" clauses, MySQL, PostgreSQL and > SQLite all allow "as" to be optional, so we can omit it across the > board. No need for a case-by-case analysis (and now somebody will say > that MS-SQL requires it). MS-SQL does *not* require AS for table aliases :) (At least for 2000 and 2005, not sure about 7 and before, but I can't image that's something that would have changed between releases.) 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: Re: handlers.modpython.is_secure -- why not use self._req.is_https() ?
On 10/24/06, Jeremy Dunck <[EMAIL PROTECTED]> wrote: > > On 10/24/06, Jeremy Dunck <[EMAIL PROTECTED]> wrote: > > In other words, I hope I haven't talked you into breaking trunk. :-/ > > > > Relevant (or so I thought) doc: > http://www.modpython.org/live/current/doc-html/pyapi-mprequest-meth.html Hmm... this appears to be new in mod_python 3.2.10. I don't see it in the 3.2.8 docs. http://www.modpython.org/live/mod_python-3.2.10/doc-html/pyapi-mprequest-meth.html http://www.modpython.org/live/mod_python-3.2.8/doc-html/pyapi-mprequest-meth.html 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: Re: DecimalField
On 10/25/06, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: > > On 10/24/06 5:25 PM, Jason Davies wrote: > > I think we should just distribute decimal.py to maintain Python 2.3 > > compatibility. > > I'm +1 on the patch if someone can resolve two things: > > * Is the license for decimal.py compatible with Django's BSD license? The file itself doesn't specify a different license, so it's presumably under the PSF license. > * Are the developers of decimal.py (is that the PSF now?) OK with us > distributing it? Here's the first part of the header from decimal.py in python 2.5. The authors are listed if anyone wants to contact them. # Copyright (c) 2004 Python Software Foundation. # All rights reserved. # Written by Eric Price #and Facundo Batista #and Raymond Hettinger #and Aahz #and Tim Peters 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: 3rd party auth backend access to session object
On 11/1/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > I need to add session keys to the session right from my LDAP > authenication backend. I think it is as simple as passing the session > object to the backend during authentication. Has anyone else needed > this kind of functionality? maybe there is a simpler way of accessing > the session in a 3rd party auth backend? There's not a simpler way to access the session in the authenticate function of a backend. If you provide some details about what you're trying to do, people may have some suggestions though. 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?hl=en -~--~~~~--~~--~--~---
Re: Re: Re: Branch Merges?
On 11/6/06, James Bennett <[EMAIL PROTECTED]> wrote: > > On 11/6/06, Gábor Farkas <[EMAIL PROTECTED]> wrote: > > so, in short, the only testable branches seems to be fullHistory and > > rowLevelPermissions, and even there it's not clear if they are now > > considered done, or still in progress. > > Yeah, it's a bit confusing. Could we get status reports from branch > authors who are reading this? Or, better, could you update the info > for your branches on the wiki page? I'm actually working on the generic-auth branch again. It works fine for checking permissions on single objects, but I'm still adding more convenience functions and refactoring some stuff. The API is probably stable though. I've updated the GenericAuthorization wiki page, so if anything is out of date, bug me. 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?hl=en -~--~~~~--~~--~--~---
generic-auth and extensible QuerySet filtering
As of now generic-auth is missing part of the functionality that would make it truly useful. You can check permissions on a single object using the extensible has_permission function, but often times you need to get a list of objects for which a user has a specified permission. Getting all possible objects, looping thorough them, and calling has_permission on each object to filter the list is possible, but suboptimal at best. The fastest way to get a filtered list of object would be to utilize features of SQL, or even better, QuerySets. Starting at line 146 [1] of the generic-auth tests, I've created an initial implementation of an extensible QuerySet filtering function. It is similar to has_permission, except it takes a user, permission, and QuerySet as arguments. Instead of returning True or False, it returns a new QuerySet that has the disallowed objects filtered out. Like with has_permission, you can register implementations of this function to deal with different types of users, permissions, and models. I'm not sure that this should be a function however. It may also make sense as a Manager and/or QuerySet method. Does anyone have ideas for what to name this function/method? I haven't been able to come up with anything I've been happy with. Also, comments on the api/implementation are welcome. The code found in [1] is more or less what would go into the actual django code base. Joseph [1] http://code.djangoproject.com/browser/django/branches/generic-auth/tests/regressiontests/generic_auth/tests.py#L146 --~--~-~--~~~---~--~~ 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: Re: generic-auth and extensible QuerySet filtering
On 11/30/06, James Bennett <[EMAIL PROTECTED]> wrote: > > On 11/27/06, Joseph Kocherhans <[EMAIL PROTECTED]> wrote: > > I'm not sure that this should be a function however. It may also make > > sense as a Manager and/or QuerySet method. > > It *feels* like something that'd make sense as a manager method; maybe > call 'QuerySetFilter' to 'AuthorizationManager' or some > shortened/similar version, and just override its 'filter' method to do > the magical extensible auth filtering. > > That would fit in well, I think, with the precedent of the CurrentSiteManager. I hadn't thought of that. This is probably something we want to make sure to call, so I wonder if it would even make sense to have this custom Manager's filter method take user and permission as required positional arguments. I'll take a closer look at that angle. > Also, am I just up too late or is there a bug at line 186 of the > generic-auth test suite? That feels like it should be 'func = > self.registry.get(types, None)'... Yep, it should. It should probably raise an exception as well if it can't find match in the registry. No match means that something wasn't registered properly, not that there shouldn't be any security. 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?hl=en -~--~~~~--~~--~--~---
Re: DB to Django Models
On 12/15/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Hello, i was thinking of developing some modules that did the > transalation from any DataBase supported by Django to the Django > Models. For example, i have a db in production but would like to use it > with Django, then i would have to rewrite all the Data Base Abstraction > but in the Django Models, i would like a script to do this for me, is > just reverse engeniering. > > I would like to know if anyone is working on this so i dont reinvent > the wheel... http://www.djangoproject.com/documentation/django_admin/#inspectdb 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?hl=en -~--~~~~--~~--~--~---
Re: Has anyone looked at ticket #1476?
On 12/28/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: I did look at making them edit inline but I think it would be much easier to show them in a non-editable way and then allow them to edit if they need to. Not sure what it would take to create a different type of edit inline. Hey Jim. Sorry it took so long to reply. I've been recovering and catctching up from the holidays. I've updated ticket 1476 for posterity, but here's what I did to implement what you see in the screenshot: I overrode admin templates and wrote a few template tags to get the related objects given the original object in the template context. It's kind of a hack, but if you really need this, it's not a messy hack. For the add links you need to add something like ?myobj_id=12 to the end or the url. That will cause the related object's ForeignKey fields to be prefilled with the correct value. There's info about overriding admin templates someplace on the lists, but I'm not sure that it's in the official docs. 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?hl=en -~--~~~~--~~--~--~---
Proposal: Named auth backends and backend specific profiles
1. Named auth backends
Right now, user logins are coupled to the actual location of an auth
backend. The python dotted path of the backend is stored in the user's
session when they login. If you were to move the backend to a
different module, any user who was logged in via that backend would
get a 500 the next time they tried to view a page because the class
corresponding to the dotted path in their session would no longer
exist. I propose to register and lookup backends by name to fix this
problem. Here's a configuration sample:
# a tuple of (name, path) tuples
AUTHENTICATION_BACKENDS = (
('default', 'django.contrib.auth.backends.ModelBackend'),
('ldap', 'mypkg.backends.LDAPBackend'),
)
This will allow you to change to a different backend class, or move it
to a different module or package without breaking your existing logins
since they will be looked up by name rather than by path.
2. Link users to their backends
Adding a 'backend_name' field to django.contrib.auth.models.User would
allow us to tie a user object to a specific backend when it is
created. This would be a choice field with the choices populated from
AUTHENTICATION_BACKENDS. It would allow us to use default django users
and look them up by the type of backend they are tied to. (i.e. give
me all OpenID users, give me all ldap users, etc.) This depends on
point one, and makes the next proposal possible.
3. Store backend specific user profiles
I also propose to extend the AUTH_PROFILE_MODULES pattern to support
backend specific profiles. This would depend on both of the previous
points. Here's a configuration example:
BACKEND_PROFILE_MODULES = {
'ldap': 'mypkg.models.LDAPProfile',
}
And to get the backend specific profile for a user:
user.get_backend_profile()
get_backend_profile() would user user.backend_name and
BACKEND_PROFILE_MODULES to return the appropriate profile model.
4. Dealing with username
Things like OpenID don't require a username, but the default
django.contrib.auth User model does. We could hack something together
in an OpenID backend to make up a unique username, but that seems kind
of silly since we just don't need it. To fix this, the required=True
attribute of the username field should be removed and a custom
validator should take it's place. This validator should look at the
new user.backend_name field to determine if the *backend* requires a
username field. If backend_name is not available in the validators
all_data argument, the validator will assume that username is
required. My initial thinking is that an attribute named
username_required or something similar could be checked on the backend
object. To indicate that username is *not* required, you'd just set
that attribute on your backend class. For instance:
class OpenIDBackend(object):
username_required = False
def authenticate(request=None):
# validate the openid server response and return a user
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?hl=en
-~--~~~~--~~--~--~---
Re: Proposal: Named auth backends and backend specific profiles
On 1/11/07, James Bennett <[EMAIL PROTECTED]> wrote:
>
> On 1/10/07, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
> > I propose to register and lookup backends by name to fix this
> > problem. Here's a configuration sample:
> >
> > # a tuple of (name, path) tuples
> > AUTHENTICATION_BACKENDS = (
> > ('default', 'django.contrib.auth.backends.ModelBackend'),
> > ('ldap', 'mypkg.backends.LDAPBackend'),
> > )
>
> Other than the fact that it's currently a tuple, is there any reason
> not to change this to a dictionary? That'd feel cleaner and make it
> much easier to do lookups against it (no more iterating through tuples
> of tuples):
>
> # a dictionary of name/path pairs
> AUTHENTICATION_BACKENDS = {
> 'default': 'django.contrib.auth.backends.ModelBackend',
> 'ldap': 'mypkg.backends.LDAPBackend',
> }
I'd love to use a dictionary, but the order of backends matters. I
wish python had a decent syntax for what basically amounts to an
ordered dict.
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?hl=en
-~--~~~~--~~--~--~---
Re: Proposal: Named auth backends and backend specific profiles
On 1/11/07, Nicola Larosa (tekNico) <[EMAIL PROTECTED]> wrote: > > Every middle-to-big project has its own version, and Django is no > exception, look in django.utils.datastructures. I have a patch ready to go for named backends, and it uses django.utils.datastructures.SortedDict from django purely for convenice sake, but it seems like bad form to me to import it in a settings file, so I'm just lazily converting the tuple of tuples into a SortedDict and loading the backends into that structure. It's more of an aesthetic issue than a technical one to me. from django.utils.datastructures import SortedDict AUTHENTICATION_BACKENDS = SortedDict() AUTHENTICATION_BACKENDS['default'] = 'django.contrib.auth.backends.ModelBackend' AUTHENTICATION_BACKENDS['ldap'] = 'mypkg.backends.LDAPBackend' I'm sort of ok with that in source code, but in configuration code? Yuck. ;) 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?hl=en -~--~~~~--~~--~--~---
Re: Proposal: Named auth backends and backend specific profiles
On 1/16/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
Sorry this has taken a while to look at - hopefully I'm not too late
to make a meaningful contribution...
Not a problem. I still haven't finished a patch yet and am certainly
still open to suggestions.
I would make another suggestion - why not keep this in line with
INSTALLED_APPS, and use the last dotted section as the identifying
name; i.e,
AUTHENTICATION_BACKENDS = (
'django.contrib.auth.backedns.ModelBackend',
'mypkg.backends.LDAPBackend'
)
would result in 'ModelBackend' and 'LDAPBackend' being available as
identifying names for backends.
As well as maintaining parity with INSTALLED_APPS, this gets around
Jacob's problem of breakage on update, while breaking full path
dependence.
It fits well with how django currently works, but I don't think that's
how INSTALLED_APPS *should* work. We've discussed named apps before,
and even reached consensus, even though the thread is a year old :D
http://groups.google.com/group/django-developers/tree/browse_frm/thread/7197d27127494ee2/df18ee9b91ba383c?rnum=1&q=app+name&_done=%2Fgroup%2Fdjango-developers%2Fbrowse_frm%2Fthread%2F7197d27127494ee2%3Ftvc%3D1%26q%3Dapp+name%26#doc_df18ee9b91ba383c
IIRC Adrian also posted something to the effect of "let's do that" in
a separate thread within the last few months, although I can't find it
now.
If Adrian and Jacob are still on board for allowing the optional
('path.to.my.app', 'app_name') syntax for an entry in INSTALLED_APPS,
I'll work up a patch that fixes INSTALLED_APPS, and let's
AUTHENTICATION_BACKENDS use the same syntax.
On the other hand, I'm also open to implementing auth backend
configuration exactly as you proposed, and leaving the naming part
until after 1.0. Allowing a tuple in place of a string won't be a
backwards-incompatible change.
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?hl=en
-~--~~~~--~~--~--~---
newforms-admin and list_display, etc.
I'd like to see a way to customize the list_display, search_fields, and list_filter (and possibly list_display_links?) attributes of ModelAdmin in the same way as change_list_queryset, etc. The use case is to hide fields in the change list depending on who is accesing the page. This should be a pretty simple and non-invasive change to make. ModelAdmin would need a few new methods following this pattern: def get_list_display(self, request): return self.list_display and ModelAdmin.changelist_view would need to be modified to call the new methods rather than accessing their corresponding attributes. I'm volunteering to put together a patch if this sounds worthwhile. 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?hl=en -~--~~~~--~~--~--~---
Re: New branch: newforms-admin
On 1/16/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > > I'd like to take the clean route and move the admin definitions into a > separate file, or at least still in the models.py but not within the > models themselves. Of course, that's not as convenient as defining the > admin stuff directly within the model, but another solution would > require more typing and possible repetition. I think I've figured out how we might decouple things while still keeping convenience intact. If nothing else, maybe this will spark some more ideas. First, let's introduce a new class, let's call it ViewRegistry. It can return urlpatterns by calling its get_urlpatterns method. The include function in django.conf.urls.defaults should be updated to accept an instance of this class, or a string path to an instance. ViewRegistry will also have a register method that takes a model class and a subclass of ModelAdmin. That much gives us a way to setup multiple admin systems (loosely speaking). It's coupling views and urls, but IMHO this is an instance of controlled coupling for convenience a la django.shortcuts Now for convenience. Somewhere in django.contrib.admin we should instantiate ViewRegistry as a module global. When a model class is being setup and it has an inner Admin class, automatically register it with this ViewRegistry instance. The inner Admin class would not be an explicit sublass of ModelAdmin, nor would we do any magic to make it so. Instead, we could treat it simply as configuration data and pass it into ModelAdmin's constructor as a second arugment. (The model class itself still being the first. I really like how that works right now.) I haven't figured out how to specify a custom ModelAdmin subclass inside the model defentition yet. Adding a new admin_view attribute to the inner Admin class immediately pops out at me, but if we're passing that Admin class into the ModelAdmin's constructor, well... there's a weird circularity there that hurts my head. Joseph For bonus points maybe we could add the other admin views, password_change, logout, and maybe even the login_required decorator as methods of ViewRegistry. --~--~-~--~~~---~--~~ 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: UserManger Class question
On 2/17/07, voltron <[EMAIL PROTECTED]> wrote: > > class UserManager(models.Manager): > def create_user(self, username, email, password): > "Creates and saves a User with the given username, e-mail and > password." > now = datetime.datetime.now() > user = self.model(None, username, '', '', > email.strip().lower(), 'placeholder', False, True, False, now, now) > ... > ... > #SNIP > > I do not understand this line: > user = self.model(None, username, '', '', email.strip().lower(), > 'placeholder', False, True, False, now, now) > > I looked in the class definition of Manager and I found no > model.__init__ function that would take the arguments listed above, I > dug deeper and looked at the definition of "Model", no luck. A custom manager can access the model it is bound to via self.model. It is referring to django.contrib.auth.model.User in this case. The line you are pointing out is just calling the User model's constructor. http://www.djangoproject.com/documentation/model_api/#custom-managers 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?hl=en -~--~~~~--~~--~--~---
Re: Creating an independent auth/permission-framework, separate the models (Was: Adding support for replacing the auth User model to fit custom needs)
On 2/19/07, David Danier <[EMAIL PROTECTED]> wrote: > I would like to contribute creating this, if someone is interested. > Perhaps the best place to start (or even work if Joseph Kocherhans likes > my plans?) is the generic-auth-branch. I believe such a system should be > ready with Django 1.0. Otherwise the whole auth-System (and with it the > admin) is not as usable as it could be. And even better, it would > simplify managing the auth-system as a whole (only small apps, that > implement, provide or use some API). I'm much more of the opinion nowadays that Django doesn't necessarily need an overreaching and generic authentication/authorization framework. The newforms-admin branch [1] is moving towards getting rid of the admin system's dependency on django.contrib.auth for authorization, and I'm hoping we can eventually get there for authentication as well. I haven't thought much about exactly *how* to do so yet. [1] http://code.djangoproject.com/wiki/NewformsAdminBranch Specifically has_add_permission(), has_change_permission() and has_delete_permission() --~--~-~--~~~---~--~~ 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: Google Summer of Code 2007
On 2/26/07, Matthew Flanagan <[EMAIL PROTECTED]> wrote: > > Specifically, I was referring to the has_*_permission() stuff in the > new ModelAdmin class. Which is new functionality aside from the > oldforms to newforms port. A lot of the generic-auth and RLP code is nasty stuff to try to integrate with the admin system. The new methods are very much welcome by me both as someone very familiar with the per-object-permission branch, and as the author of the generic-auth branch. The design is much cleaner. 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?hl=en -~--~~~~--~~--~--~---
Re: Google Summer of Code 2007
On 2/26/07, Matthew Flanagan <[EMAIL PROTECTED]> wrote: > > On 2/27/07, Joseph Kocherhans <[EMAIL PROTECTED]> wrote: > > > > On 2/26/07, Matthew Flanagan <[EMAIL PROTECTED]> wrote: > > > > > > Specifically, I was referring to the has_*_permission() stuff in the > > > new ModelAdmin class. Which is new functionality aside from the > > > oldforms to newforms port. > > > > A lot of the generic-auth and RLP code is nasty stuff to try to > > integrate with the admin system. The new methods are very much welcome > > by me both as someone very familiar with the per-object-permission > > branch, and as the author of the generic-auth branch. The design is > > much cleaner. > > > > I agree that it is cleaner but it still limited to the admin system > with no generic means available to other applications. I seems [1] > that interest in doing this is also waning. I'm sorry you have the impression that it would be limited to the admin system. It's certainly not something I meant to convey. When RLP is integrated, it will be available to more that just the admin system. My personal opinion is that most of the code in there is good and will probably be used as is. The admin integration is a little nasty, but that isn't Chris's fault. The admin system just wasn't designed with extensibility in mind. At PyCon, we came up with a plan to change that. After the new admin stuff done, I will probably end up working on RLP myself if no one beats me to the punch. > I for one am very keen to see RLP branch integrated and I tested it > months ago to my satisfaction. I understand that the branch works well for a lot of people, and if it works for you, by all means continue using it. If you want to see new features added to it from the trunk, speak up and ask for commit access. The branch could probably use a maintainer. 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?hl=en -~--~~~~--~~--~--~---
Re: Creating an independent auth/permission-framework, separate the models (Was: Adding support for replacing the auth User model to fit custom needs)
On 2/27/07, David Danier <[EMAIL PROTECTED]> wrote: > > As an enhancement it would be nice to get the generic-auth-branch into > the trunk (slightly changed perhaps). So not only authorization can be > done on an abstract way, but permission-checks, too. I'll probably work on this once the newforms-admin stuff is finished. Even if it isn't accepted into django or django.contrib, the newforms-admin branch would allow the generic-auth stuff to be provided as a 3rd party app. > I think Django would benefit from this in the long term (third-party > applications get more usable). As the modules are not that big, fairly > simple and should be easy to separate (this is somehow already done in > the auth-app, while keeping it together in one app) I don't see any > reason to not do this. I agree. I don't have the bandwidth to work on this at the moment, but it's on my radar. Joseph [1] http://groups.google.com/group/django-hotclub --~--~-~--~~~---~--~~ 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: Upcoming changes to the Django admin
On 3/3/07, Ivan Sagalaev <[EMAIL PROTECTED]> wrote: > > Jacob Kaplan-Moss wrote: > > Edit-inline is also going to be moved out into the admin declaration, > > Edit-inline was also useful outside of the admin, in manipulators. Are > there any plans to have newforms handling this or this will become a > purely admin functionality? I'm working on it at the moment and barring any objections from Adrian, yes, something similar to edit-inline will be available outside of the admin. 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?hl=en -~--~~~~--~~--~--~---
Re: Edit inline in newforms-admin branch (ATTN: Joseph Kocherans)
On 3/25/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > > Now that we have 0.96 out the door, I'd love to wrap up the > newforms-admin branch, which is mostly missing edit-inline support but > works well for other cases. > > Joseph Kocherans was working on edit-inline support, but I haven't > seen anything checked in or heard from him about any developments. > Joseph, are you around, and what's the status? I can happily take over > if you're not in a position to do the implementation. Oh, I didn't know that you had it in a stable state yet. I'm sorry, I totally missed the checkin where you got most of this done. :) I have non model-specifc edit-inline stuff working, but there are a couple of tests for corner cases I need to write for it. It has hooks for handling deletion and ordering as well. I'll get it checked in tomorrow anyhow so you can take a look. 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?hl=en -~--~~~~--~~--~--~---
Re: Edit inline in newforms-admin branch (ATTN: Joseph Kocherans)
On 3/25/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > > Now that we have 0.96 out the door, I'd love to wrap up the > newforms-admin branch, which is mostly missing edit-inline support but > works well for other cases. > > Joseph Kocherans was working on edit-inline support, but I haven't > seen anything checked in or heard from him about any developments. > Joseph, are you around, and what's the status? I can happily take over > if you're not in a position to do the implementation. Hey Adrian. Looking at the newforms-admin branch tonight, I can't seem to get some things working. I was wondering if you would clarify the scope of what is finished at this point. Is the AdminSite stuff we discussed at PyCon supposed to be the main way of doing things now? After about 5 minutes I haven't been able to figure out what to put in my urlconfs to get it called, and for some reason, the existing admin index view (django.contrib.admin.views.main.index) is not finding any models (the actual change list add and edit pages all work fine if I type in the url) Not asking for debug advice here, just trying to figure out what *should* be working. 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?hl=en -~--~~~~--~~--~--~---
Re: Edit inline in newforms-admin branch (ATTN: Joseph Kocherans)
On 3/26/07, Joseph Kocherhans <[EMAIL PROTECTED]> wrote: > > Hey Adrian. Looking at the newforms-admin branch tonight, I can't seem > to get some things working. Gah. Nevermind. Only the index page is working of AdminSite, and it's root method acts like a view that takes url as a param. Doesn't explain my problems with django.contrib.admin.views.main.index, but that's a different issue. Anyhow, it seems like kind of a waste of time to implement edit_inline using the soon to be extinct syntax. Any reason not to try to finish up the AdminSite stuff on the newforms-admin branch other than the fact that the branch should have been merged a couple of months ago? Maybe I'm missing a 3rd option? 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?hl=en -~--~~~~--~~--~--~---
Re: Edit inline in newforms-admin branch (ATTN: Joseph Kocherans)
On 4/6/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> As of [4944], the newforms-admin admin site should be working properly
> -- you're right that I hadn't finished the AdminSite stuff. (Sorry for
> the miscommunication!) It's working pretty well now. To activate the
> admin site, do this:
>
> """
> from django.conf.urls.defaults import *
> from django.contrib import admin
>
> urlpatterns = patterns('',
> ('^admin/(.*)', admin.site.root),
> )
> """
Yay!
> The next step is to get edit_inline working, with the new syntax we've
> talked about. Joseph -- I saw you checked in a
> django.newforms.formsets module in the newforms-admin branch. How do
> you envision that interacting with edit_inline?
Here's an incredibly high-level and naive overview of how the views will work:
Create 1 form for the parent object, and a FormSet (with deletion
enabled) to manage the child objects.
If the forms are all valid, create/save the parent object, loop
thorugh formset.clean_data (and formset.deleted_data) creating,
updating, or deleting child objects as necessary using the id from the
parent object we already saved. Bye-bye core!
I'm sure there's some nastiness there that will become apparent when I
get down to the actual code, but I doubt it will be anything
impossible to deal with.
I've got some much better code/tests for FormSet on the way, including
code that deals with displaying more than one extra blank form. I've
just been busy as hell trying to get marketplace launched, and then
fighting a fever for the past few days. I've already covered a lot of
ground tonight though, and planning on more tomorrow.
I'm obviously glossing over a lot of details. If there are any you're
particularly worried about, let me know.
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?hl=en
-~--~~~~--~~--~--~---
Re: Two field-related suggestions for newforms.models
On 4/29/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: > > 1) Is there room for a 'fields' argument on form_for_instance and > form_for_model - a list of field names that you want included on the > form (defaulting to None, meaning the full list), so that it is simple > to create a form with a subset of a model's full field list? > > I realize that you can subclass the form class returned by the > form_for_ methods and delete the fields you don't want, but 'form from > field subset' seems like a fairly common use case that can be very > easily accommodated. +1. I'm planning on adding a similar argument to edit-inline. Writing a one-off formfield_callback seems like an awful lot of work for such a common task. I'm sure the same thing could be implemented as a wrapper around the form_for_ functions using formfield_callback, but I don't see any particular reason to do it that way as long as the behavior of the 'fields' argument was documented as Malcolm said. > 2) I realize that there are historical (i.e., > manipulator/pre-magic-removal related) reasons why reverse ForeignKey > and M2M relations are not contained on forms, but is there any reason > that newforms should continue the tradition? > > We probably don't want to include reverse fields on forms by default > (if only for backwards compatibility), but providing an optional > argument (say, reverse_fields=(...), containing a list of reverse > descriptor names) on form_for_model and form_for_instance would allow > users to easily include reverse relations on a form. +1 for optionally doing this for ManyToManyField at least. Would the reverse ForeignKey interface be similar to edit_inline? I think once I finish the formset-model integration code, that should be pretty simple to pull off. 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?hl=en -~--~~~~--~~--~--~---
Re: Edit inline in newforms-admin branch (ATTN: Joseph Kocherans)
On 5/5/07, Jari Pennanen <[EMAIL PROTECTED]> wrote: > > Modularity of edit inline? Any better? > > Currently: > models.ForeignKey(Other, edit_inline=models.TABULAR, parameters...) > obiviously is a big waste of OO abilities, > > instead something like, the OO way: > models.ForeignKey(Other, edit_inline=models.TabularInline(parameters)) > were much better. (I know it is defined elsewhere in upcoming > implementation, but the example I saw did not implement subclassing > which I think is neccessity to create it customizable, and also the > parameters is way more clear this way) > > One could implement own edit inlines just by subclassing from > TabularInline/StackedInline, or from where TabularInline subclassed > itself. Currently I see no easy or sensible way to create own edit > inlines. That's the general idea of what we came up with at PyCon. I'm still working on the underlying machinery (basically formset_for_model and formset_for_instances) though. TabularInline/StackedInline (or whatever they end up being) will be mostly configuration, however, they are an incredibly small part of the overall implementation and will be one of the last things I work on. I imagine they will have some methods to customize them a little via subclassing, but I'm not going to speculate further until I get there. 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?hl=en -~--~~~~--~~--~--~---
Re: Edit inline in newforms-admin branch (ATTN: Joseph Kocherans)
On 5/10/07, Joseph Kocherhans <[EMAIL PROTECTED]> wrote: > On 5/5/07, Jari Pennanen <[EMAIL PROTECTED]> wrote: > > > > Modularity of edit inline? Any better? > > > > Currently: > > models.ForeignKey(Other, edit_inline=models.TABULAR, parameters...) > > obiviously is a big waste of OO abilities, > > > > instead something like, the OO way: > > models.ForeignKey(Other, edit_inline=models.TabularInline(parameters)) > > were much better. (I know it is defined elsewhere in upcoming > > implementation, but the example I saw did not implement subclassing > > which I think is neccessity to create it customizable, and also the > > parameters is way more clear this way) > > > > One could implement own edit inlines just by subclassing from > > TabularInline/StackedInline, or from where TabularInline subclassed > > itself. Currently I see no easy or sensible way to create own edit > > inlines. > > That's the general idea of what we came up with at PyCon. I'm still > working on the underlying machinery (basically formset_for_model and > formset_for_instances) though. TabularInline/StackedInline (or > whatever they end up being) will be mostly configuration, however, > they are an incredibly small part of the overall implementation and > will be one of the last things I work on. I imagine they will have > some methods to customize them a little via subclassing, but I'm not > going to speculate further until I get there. Oops. Actually let me clarify that a bit. The edit_inline definition will definitely *not* be an argument to ForeignKey, but rather an argument to either AdminSite.register or ModelAdmin (most likely the latter). Passing configuration data into ModelAdmin still hasn't been finalized, so I can't really tell you exactly what it will look like, but the main point is that edit_inline definitions will happen completely *outside* of the model. 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?hl=en -~--~~~~--~~--~--~---
Re: Two field-related suggestions for newforms.models
On 5/10/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: > > On 5/11/07, Joseph Kocherhans <[EMAIL PROTECTED]> wrote: > > > > On 4/29/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: > > > > > > I realize that you can subclass the form class returned by the > > > form_for_ methods and delete the fields you don't want, but 'form from > > > field subset' seems like a fairly common use case that can be very > > > easily accommodated. > > > > +1. I'm planning on adding a similar argument to edit-inline. Writing > > a one-off formfield_callback seems like an awful lot of work for such > > a common task. I'm sure the same thing could be implemented as a > > wrapper around the form_for_ functions using formfield_callback, but I > > don't see any particular reason to do it that way as long as the > > behavior of the 'fields' argument was documented as Malcolm said. > > I've got a working implementation and some proof-of-concept tests; > would you like me to clean this up and push it into the trunk, or do > you want to handle it yourself? If you want to add it to the trunk that would be awesome. I can just merge the changes into the newforms-admin branch. It's overdue for a merge anyhow. > > > 2) I realize that there are historical (i.e., > > > manipulator/pre-magic-removal related) reasons why reverse ForeignKey > > > and M2M relations are not contained on forms, but is there any reason > > > that newforms should continue the tradition? > > > > > +1 for optionally doing this for ManyToManyField at least. Would the > > reverse ForeignKey interface be similar to edit_inline? I think once I > > finish the formset-model integration code, that should be pretty > > simple to pull off. > > I would have thought reverse foreign key would have be more like m2m > than edit inline. The reverse case is more like 'which of these > objects are have FK relations pointing to this one?', so a 'select > multiple' widget would be appropriate. Ahh. I'll echo Malcolm's +0 on that then. I haven't found a need for it, but it seems like I'd find a use for it if it were there. 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?hl=en -~--~~~~--~~--~--~---
Re: Edit inline in newforms-admin branch (ATTN: Joseph Kocherans)
On 5/13/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > > What's your ETA on these changes? I finally have some free time this > week, and I'd like to work toward getting this branch finalized. If > you don't have time to hack on this, let me know where you left off. I'm still working on the formset-model integration stuff. After that it's mostly configuration classes and template changes. I'll have time to work on it this week, but I don't expect I'd be able to finish it. There's also still some ugliness in the FormSet constructor, but it works. If you think you'll have a lot of time, and you want to take over, my feelings won't be hurt, but I'll keep working on it until I hear otherwise. Joseph P.S. What's your status on the other stuff in that branch? I know that site.register doesn't handle kwargs for ModelAdmin yet, and I think there are a couple of other loose ends, but I figured you just hadn't gotten that far yet. I can file tickets as I come across stuff like that if you like, but I don't want to harass you with unneccessary info. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
runtest.py slowdowns?
Has anyone noticed a fairly recent order of magnitude slowdown in how long it takes to run the django test suite? I used to get times of about 14 seconds around March (at PyCon) but it's taking ~150 seconds now. It's quite possibly something that's changed in my setup, but I figured I'd see if anyone else has noticed the same thing. It doesn't seem like there have been *that* many tests added to django in the last couple of months. 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?hl=en -~--~~~~--~~--~--~---
Re: runtest.py slowdowns?
On 5/14/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: > > On 5/15/07, Joseph Kocherhans <[EMAIL PROTECTED]> wrote: > > > > Has anyone noticed a fairly recent order of magnitude slowdown in how > > long it takes to run the django test suite? I used to get times of > > about 14 seconds around March (at PyCon) but it's taking ~150 seconds > > now. It's quite possibly something that's changed in my setup, but I > > figured I'd see if anyone else has noticed the same thing. It doesn't > > seem like there have been *that* many tests added to django in the > > last couple of months. > > Yes Virginia, there has been a test slowdown :-) > > It happened around mid January, as a result of the tests that use > fixtures. Every time a fixture test is executed, it flushes the > contents of the database. Flushing is a slow operation. Unfortunately, > it's also a necessary operation for those tests. Hmm... I guess I'm just remembering the times before I merged changes from trunk into newforms-admin. > I agree that the slowdown is less that ideal. I have a chat with > Malcolm recently about possible ways to speed things up, and we didn't > come up with any ideas that would yield any sort of significant > speedup. Any suggestions on how to improve the situation are welcome. Such is the price of testing :) I just wanted to make sure I wasn't the only one seeing slowdowns. I'm surprised I didn't notice it before. Unfortuantely I haven't really read the fixtures code, so I definitely don't have any suggestions forthcoming. I've just treated it as fabulous magic until I have time/a reason to look. 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?hl=en -~--~~~~--~~--~--~---
OneToOneField and generic views
The generic view django.views.create_update.update_object requires the
object to have an id in line 99.
manipulator = mod.ChangeManipulator(object.id)
Objects with OneToOneFields don't have an id attribute. Instead they
have something like "relatedobject_id" I'm not sure where this should
be fixed. In the generic view code (test for OneToOneField and do the
right thing(tm)" or if models with OneToOneField should actually have
an id (probably just return the "relatedobject_id"). Any preferences?
I can work on a patch. I'd much rather fix this than put workarounds
in my app code or write a custom view.
There is also another issue under the same circumstances.
mod.Klass._meta.pk.name returns "relatedobject" rather than
"relatedobject_id", and get_object("relatedobject__exact") results in
a KewordError... get_object("relatedobject__id__exact") works fine.
Unfortunately, the update_object view uses the former. I think the
model syntax changes broke some things where OneToOneFields are
involved.
Joseph
Re: Get rid of model modules?
On 9/15/05, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > > On 9/15/05, Simon Willison <[EMAIL PROTECTED]> wrote: > > from django.models.blog import Blog, Entry > > > > Blog.get_list() > > Blog.get_object() > > Entry.get_iterator() > > I have a natural aversion to class methods like that. To me, it makes > more sense for a *module* to contain functions that return instances, > than for a *class* to have methods that return instances of that same > class. It's one of the things I don't like about SQLObject (which, of > course, has things that I do like -- but class-method use isn't one of > 'em). > > In the above example, Blog.get_object() returns a Blog instance, and > each Blog instance has a get_object() method. That feels awkward, > messy and ugly, in my opinion. It does to me as well, but I think the benefits might outweight the costs in this case. It occured to me that it's not necessarily the module/class distiction that bothers me, but the naming: MyObj.get_object() vs. myobjs.get_object(). If this change goes through I might try something like from django.models.myapp import MyObj as myobjs I've never really used aliases though... I suspect there might be some gotchas there. Also, I don't know if the proposed change would help, but being able to use properties in my classes would be great. Joseph
Re: model docstrings/doctest
On 10/10/05, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > > On 10/10/05, Joseph Kocherhans <[EMAIL PROTECTED]> wrote: > > I'd like to use doctest for testing my model classes, but the model > > metaclass overwrites my classes docstrings. Is there any reason why it > > MUST override __doc__? I think the model metaclass should leave > > __doc__ alone if it exists. Thoughts? > > Nope, there's no reason that it must override. Were you thinking the > docstring for a model class would become the docstring of the object > instances? Probably so. The only other choice I can think of is the model's module. Intuitively, the former makes more sense to me. I honestly don't care as long as I can run the doctests in my model classes docstrings though. :) Joseph
Re: model docstrings/doctest
On 10/10/05, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > > On 10/10/05, Joseph Kocherhans <[EMAIL PROTECTED]> wrote: > > I'd like to use doctest for testing my model classes, but the model > > metaclass overwrites my classes docstrings. Is there any reason why it > > MUST override __doc__? I think the model metaclass should leave > > __doc__ alone if it exists. Thoughts? > > Nope, there's no reason that it must override. Were you thinking the > docstring for a model class would become the docstring of the object > instances? Just submitted a patch that does exactly that. http://code.djangoproject.com/ticket/628 Joseph
custom field attributes
I was just considering how I might add custom attributes to fields in my models. I need to render forms that have a hierarchy of sorts, fields need to have subfields. Of course I'll need some custom code to generate forms. I'd like to include a 'parent' attribute on all of my fields so I don't have to define a field hierarchy outside of my models. A 'parent' attribute is way too application specific to consider adding it to django.core.meta.fields.Field, but I imagine app specific extentions of both models and fields would be very useful to a lot of people. (I'm not sure if you can add arbitrary class attributes to META or not... I'm guessing no though.) In formencode, Ian Bicking allows a 'state' argument in validator constructors for app specific uses. I'm not sure that this would be the *best* way to enable extensions to fields, but it would probably work. Does anyone have any ideas on how else this might be implemented? Does anyone else need it? I'm willing to write the patches. Thanks, Joseph
Re: Moving auth and core models to contrib -- and dependencies
On 12/21/05, Daniel Poelzleithner <[EMAIL PROTECTED]> wrote:
Apps sould define a __version__ in __init__.py wich sould be checked onthe dependencies check.maybe a syntax like:__dependencies__ = (('django.contrib.auth',">=0.1,!=0.2"),('my.app.bla', "==
0.3"))would require a version of contrib.auth that is greater as 0.1 but not0.2 and version 0.3 of bla :)kindly regards danielI knew this would come up. :) Packaging and versioning and dependencies are hard. I'm -1 for django doing any type of dependencies/versioning by itself. Writing yet another package manager shouldn't be on django's todo list. Including half-assed package management will probably just cause headaches. I'm not all that familiar with setuptools/easyinstall, but could it help out here?
Joseph
Improving Admin Metasystem Extensibility
I think the metasystem is one of Django's greatest strengths. Django's admin system has literally cut my development time down by weeks for most projects. The admin system does 90% of what I need, but getting the other few features requires a lot more work than it should. I think this should be relatively simple to fix though. rjwittams did a great job in refactoring the metasystem. I think it can be taken a little further. Here's a list of a few places I think the admin system could be more extensible. I think all of these are reasonable and generic enough to be included in django.contrib.admin, please comment if you think otherwise. 1. Allow overrides of the H1 at the top of the content div. A new template block surrounding the H1 tag would allow for this. I've added a patch in ticket #1090 [1] 2. The admin system already allows you to override admin/change_form, admin/change_list, either for an app, or for a specific model. It should allow overriding of delete_confirmation and object_history in the same fashion. I've added a patch for this in ticket #1089 [2] 3. The RelatedObjectLookup javascript should be applied to OneToOneField. It isn't. I see no reason why it shouldn't be. I've added a solution (just copy a file) in ticket #1100 [3] 4. Application pages in the metasystem. Currently, /admin/myapp/ returns a 404. There should be template (maybe called app_index) that simply displays the models for myapp. The renderer should of course look in admin/myapp/app_index first so users can override the default. I know Jacob mentioned something similar [4] on the dev list. I already have a hack that does this. I still need to take a look at the code in the magic-removal branch to do it right though. 5. Allow overrides of the save-row div in admin/change_form by extending the template. Once again, a template block should allow for this. 6. In addition to 5, The redirect url should be customizable without having to override the default admin urls. There are several possibilities I can think of here. I think the most promising ones won't become apparent until the magic-removal stuff is done. Here are the options I've thought of though. 1. Add a get_add_redirect(request, new_object) to the inner META (or ADMIN class if that ends up happening.) 2. Do something similar to the TEMPLATE_CONTENT_PROCESSORS framework. 3. Events. The first or second option seem the most "djangonic" to me, but that's probably because the event system hasn't landed yet. I don't have strong preferences for any of them yet though. Some of the changes to the way the inner Meta class works in the magic-removal branch may provide some other options here. 7. Allow custom auditing methods ''without'' having to create a custom view. I've seen a lot of people ask for this, and I have yet to see an explanation of how to do it ''without creating a custom view''. I've tried quite a few things, and can't get it to work. People seem to initially want access to the request object in _pre_save(), but of course it doesn't work because the user object isn't available in _pre_save/_post_save. rjwittams has talked about using events in the new magic-removal branch to customize the audit functionality. (I think anyhow, sorry if I'm putting words in your mouth.) This may be the way to go. The crucial thing for auditing is that the request (or at least the user) is accessible in the event object. The request isn't (and IMHO shouldn't be) in current pre-save/post-save signals. Maybe a pre-web-save and post-web-save signal? I know Adrian is concerned about requiring a request object for when you are doing things programmatically and there *is* no request. These could also be added to generic create/add views. Any other places where you think the admin system should allow for customization? Joseph [1] http://code.djangoproject.com/ticket/1090 [2] http://code.djangoproject.com/ticket/1089 [3] http://code.djangoproject.com/ticket/1100 [4] http://groups.google.com/group/django-developers/tree/browse_frm/thread/92729d4f3176b656/3e5aa32ec4d748fc?rnum=1&_done=%2Fgroup%2Fdjango-developers%2Fbrowse_frm%2Fthread%2F92729d4f3176b656%2F3e5aa32ec4d748fc%3Ftvc%3D1%26#doc_cad7102bec5a651f
Re: Improving Admin Metasystem Extensibility
On 12/27/05, Joseph Kocherhans <[EMAIL PROTECTED]> wrote: > 7. Allow custom auditing methods ''without'' having to create a custom view. > > I've seen a lot of people ask for this, and I have yet to see an > explanation of how to do it ''without creating a custom view''. I've > tried quite a few things, and can't get it to work. People seem to > initially want access to the request object in _pre_save(), but of > course it doesn't work because the user object isn't available in > _pre_save/_post_save. > I've got an initial try at a patch put together for this now. I'm not entirely happy with it, but it works. Comments are appreciated. Here's the ticket: http://code.djangoproject.com/ticket/1132 Joseph
Proposal: django.models.core/auth should be regular apps
Treating django.models.core and django.models.auth as special cases is kind of confusing. They should be regular apps, but we don't want to have to add 2 extra steps (installing the 2 apps) to get a django project up and running. Here's a few ideas for fixing the problems. Create 2 new apps, django.contrib.core and django.contrib.auth. Move the models from django.models.core and django.models.auth into these new apps. Change the settings.py template to include core, auth, and admin in INSTALLED_APPS. Change django-admin.py init. It should install core, auth, and admin. Add a django-admin.py init-minimal command. It will just initialize the django tables, not install any apps. People who want the minimal setup can just delete the apps from INSTALLED_APPS. They're going to edit the file anyhow. We might want to add one more django-admin.py command or flag to install just core and auth, but I can't think of what to call it. I don't want to go too far here though, we don't want the number of django-admin.py commands to explode arbitrarily. Subproposal: Dependencies Add pre and post install hooks (or possibly signals). An app's install hooks can check to see if all dependencies are installed already, and generate nice error messages if they are not (or maybe even try to install the dependency automatically). Some convenience functions should probably be added as well to make the basic case pretty painless. This has the added benefit of allowing things like the undocumented loading of files in your app's 'sql' directory to be added to an app without having to change django. All of this should be done on the magic-removal branch since a lot of things are being broken there anyhow. Comments? Joseph
Re: Proposal: django.models.core/auth should be regular apps
On 1/6/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > > On 1/6/06, Joseph Kocherhans <[EMAIL PROTECTED]> wrote: > > Treating django.models.core and django.models.auth as special cases is > > kind of confusing. They should be regular apps, but we don't want to > > have to add 2 extra steps (installing the 2 apps) to get a django > > project up and running. Here's a few ideas for fixing the problems. > > I did a double-take on this e-mail, because it's almost exactly the > same proposal as one I wrote a couple of weeks ago! :) > > http://groups.google.com/group/django-developers/browse_thread/thread/dc86e876af62a4cd/3413fb5e4ec2ed6c > > That thread died out due to discussion of the problems of a dependency > system -- which seemed like reasonable pushback to me. Let's avoid the > dependency thing for now. I was actually one who argued against a dependency system, but that was in reference to some some sort of "blessed" dependency system that does version checking and everything declaratively. What I'm proposing here is allowing for doing it procedurally. It would require a lot less up front design, and wouldn't generate as many "can you make it do X, Y and Z too!?" type of requests. Those are what I was worried about. I think the pre-post install stuff would be useful regradless of using it for dependencies, but it's certainly a separate issue from splitting up core/auth into apps. Maybe I'll just bring it up in another thread later. > I really like your idea of "init" and "init-minimal" -- that > accomplishes the clean split of auth/core into regular apps while > keeping it just as easy to install the basics. Let's do it! I'll start working on a patch for the magic-removal branch. This should fix #1171 as well. > One more idea, though, would be to split "core" into > django.contrib.sessions, django.contrib.contenttypes and > django.contrib.sites. Packages would go away, because they're not > really necessary (we used them heavily about 1.5 years ago, but > they're no longer useful). Thoughts on that? I always thought sites were something useful for a few special cases, but certainly not for everyone. Splitting out sessions might be useful as well since I can see people wanting to replace it. I've never even really noticied packages, so no comment there. Joseph
Re: Proposal: django.models.core/auth should be regular apps
On 1/6/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > > One more idea, though, would be to split "core" into > django.contrib.sessions, django.contrib.contenttypes and > django.contrib.sites. Packages would go away, because they're not > really necessary (we used them heavily about 1.5 years ago, but > they're no longer useful). Thoughts on that? Now that I think about it a little more I agree that core should be split into: django.contrib.sessions django.contrib.sites If no one is using packages I'll just drop it. contenttypes feels pretty core to me. I guess django doesn't really depend on it though. (although many apps do.) I think contenttypes should it go in django.contrib.core? Any preferences? Also, should the table names stay the same? My vote is for changing them, and updating BackwardsIncompatibleChanges with insructions on how to rename them. Joseph
Re: Proposal: django.models.core/auth should be regular apps
On 1/6/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > > > If no one is using packages I'll just drop it. > > This is a bit easier said than done...The content-types table depends > on it. How about splitting this patch into several stages -- > > * Move sessions from core to django.contrib.sessions (and change dependencies) > * Remove Package model (and dependencies on it) > * Move sites from core to django.contrib.sites (and change dependencies) > * Move auth to django.contrib.admin (and change dependencies) > * Move contenttypes to django.contrib.contenttypes (and change dependencies) > * Change django-admin init to install sites, auth, sessions, contenttypes > * Add django-admin init-minimal Should sites be installed by init? I think it's used rarely enough that it shouldn't. Also, I think init should install admin as well, but maybe there should be something like an init-noadmin command as well in that case. It'd be nice to remove a couple of steps from the tutorials (django-admin.py install admin, add django.contrib.admin to INSTALLED_APPS), but it's at the expense of people who don't want the admin, but *do* want sessions, auth, etc. > What did I miss? Just updating the settings template so sessions, contenttypes, etc are in INSTALLED_APPS by default. That's sort of implied in each individual model move though. > Because this is a multi-step change, and it's much more manageable > (and more easily understood) for commits to be as narrowly-focused as > possible, would you be interested in commit access on the > magic-removal branch? Let me know, and I can send you information > privately. Sounds good. > > contenttypes feels pretty core to me. I guess django doesn't really > > depend on it though. (although many apps do.) I think contenttypes > > should it go in django.contrib.core? Any preferences? > > Let's do django.contrib.contenttypes. The only parts that depend on it > are the admin log and any bits that relate an object to another object > + content type (such as django.contrib.comments, in which a comment is > related to a content_type_id and object_id). Ok. > > Also, should the table names stay the same? My vote is for changing > > them, and updating BackwardsIncompatibleChanges with insructions on > > how to rename them. > > I agree -- the table names should be changed. > I guess the final step is adding to BackwardsIncompatibleChanges then. Joseph
magic-removal table name pluralization
In the magic-removal branch most traces of automatic pluralization have been removed, but the table names are still pluralized by default. I don't think they should be. Is this just a change that's meant to happen, but hasn't yet? I seem to remember a thread where people wanted to get rid of all auto-pluralization. Joseph
Re: Proposal: django.models.core/auth should be regular apps
On 1/6/06, Ian Holsman <[EMAIL PROTECTED]> wrote: > > Hi. > I'm using packages. > I think it is a good place to put stuff like package-specific preferences. I'm going to leave them as is for now. There's actually quite a bit that depends on them that I need to take a closer look at. I'm starting to think they might be useful for other things as well. Once I figure out what I think should be done, I'll bring it up here before I make any changes. Joseph
Re: Proposal: django.models.core/auth should be regular apps
On 1/6/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > > * Move auth to django.contrib.admin (and change dependencies) Did you mean move auth to django.contrib.auth here? Or do you really want it moved into admin? Joseph
Re: Proposal: django.models.core/auth should be regular apps
Here's a status update on moving dango.contib.core/auth into django.contirb: * Move sessions from core to django.contrib.sessions (and change dependencies) Done. * Move sites from core to django.contrib.sites (and change dependencies) Done. * Move auth to django.contrib.admin (and change dependencies) Done. Earlier in this thread, Ian Holsman requested that auth should be further split into authentication and authorization. Personally, I don't see a need to do this until support for LDAP, ACL's, or whatever is added. Comments? * Remove Package model (and dependencies on it) Ian Holsman still uses this. I'm things we may want to just change this to App or Application instead of Package. I can see how it *would* be useful, although I haven't used it myself. I'll defer to Adrian and Jacob on this. * Move contenttypes to django.contrib.contenttypes (and change dependencies) If Package stays, then should packages and contenttypes both go into separate apps? * Change django-admin init to install sites, auth, sessions, contenttypes init now installs sessions, sites, auth. It also installs the old django.models.core for now (this will of course be changed once that module is moved to django.contrib) * Add django-admin init-minimal Done. init-minimal still installs django.models.core for now. * Add sessions, sites, auth, and contenttypes to the default settings template I'll do this once the issues with packages and contenttypes are straightened out. Joseph
Re: Proposal: Django namespace simplification
On 1/8/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > > > django.core.extensions -> django.shortcuts > > - includes render_to_string > > +1. "django.shortcuts" is a *perfect* name for this module. I like this idea, but I think that shortcuts of whatever should use explicit imports such as from django.core.extensions import DjangoContext, render_to_response, etc rather than from django.core.extensions import * This makes it a lot easier to tell what exactly you'll get if you import django.shortcuts. I've worked with a bunch of projects that had something like myproject.api that had a bunch of from X import *. It's a lot more convenient to be able to read the code than to have to use dir(module) or track down what's in all those modules. > Let's get some more feedback quickly and move forward with this. Also, > is anybody interested in implementing this code in magic-removal? > Kieran? I'm willing to help if needed. Joseph
Re: Proposal: django.models.core/auth should be regular apps
On 1/9/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > > On 1/8/06, Joseph Kocherhans <[EMAIL PROTECTED]> wrote: > > Here's a status update on moving dango.contib.core/auth into django.contirb: > >> > > * Remove Package model (and dependencies on it) > > Ian Holsman still uses this. I'm things we may want to just change > > this to App or Application instead of Package. I can see how it > > *would* be useful, although I haven't used it myself. I'll defer to > > Adrian and Jacob on this. > > > > * Move contenttypes to django.contrib.contenttypes (and change dependencies) > > If Package stays, then should packages and contenttypes both go into > > separate apps? > > The package model is messy, and I see no reason for it to stick around > in the long term, but fixing that is also messy. :-( So, let's move > packages and contenttypes into a single "django.contrib.contenttypes" > app, and plan to remove packages down the road. Done. The settings.py template has also been updated now. I think it should be (almost) safe to completely remove django.models now. I think there's still some code in the comments framework that uses the old (pre-magic-removal) module syntax. I'll fix it later today. Joseph
Re: CurrentUser, Owner permission, and so forth ...
On 1/10/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > 1132 and 1164 both provides solutions for the CurrentUser issue), but > as > of now, these solutions have been (in my own opinion rightly) deemed > too > hackish to get committed. This thread is aimed at finding a clean > implementation of those two concepts. > Obviously, the solution _will_ introduce some coupling between the data > layer and the request layer (well, who knows ?). The point is mainly to > make it as light as possible. I wrote both patches. Please just ignore #1132. It sucks. I was pretty much just trying to start a conversation there with the simplest (in this case least amount of code) thing I could get to work. (I probably should have done so on the list) #1164 is better IMHO, but I still don't like it too much. I got the context processor ideas from rjwittams. I think he's still on vacation, but I'd love to hear how close I came to what he was imagining. What do people think about the context processor idea? Not necessarily this implementation, but just the idea of a generic context (just a dict in the simplest case) that gets passed in to the manipulator for access by fields. AFAICT this is where the "coupling" is happening. Any other ideas on how a field might get access to the current user? Joseph
Proposal: Allow custom redirects in the admin system
I hate to request more changes to magic-removal... but that's where
this should happen. Maybe it should wait until after it's been merged
though.
Currently the redirects after add_stage and change_stage in the admin
system are hardcoded. One of the most frequent requests I get in my
projects is to allow people to go to some other related object after
they save, not back to the list of objects. The redirect should be
customizable. Here's how I propose it should be done.
Add a template block {% block submitrow %} around the submit_row in
the admin/change_form.html. This would allow people to override the
save buttons. It would be cool to do this with a combination of
template tags, and attributes in the inner Admin class, but a block
would still be useful to have. If anyone has suggestions on how
attributes+template tags might work, I'd like to hear them. I haven't
thought about it too much yet.
By default, the inner Admin class should have a couple of new methods
(or attributes that are assigned to a callable) One callable returns
an HttpResponseRedirect for adding, and the other, after changing.
These callables would take the request and the new (or updated) object
as arguments. So the default for change_stage would look like:
def after_change_action(request, new_object):
pk_value = getattr(new_object, opts.pk.attname)
if request.POST.has_key("_continue"):
request.user.add_message(msg + ' ' + _("You may edit it again below."))
if request.REQUEST.has_key('_popup'):
return HttpResponseRedirect(request.path + "?_popup=1")
else:
return HttpResponseRedirect(request.path)
elif request.POST.has_key("_saveasnew"):
request.user.add_message(_('The %(name)s "%(obj)s" was added
successfully. You may edit it again below.') % {'name':
opts.verbose_name, 'obj': new_object})
return HttpResponseRedirect("../../%s/" % pk_value)
elif request.POST.has_key("_addanother"):
request.user.add_message(msg + ' ' + (_("You may add another
%s below.") % opts.verbose_name))
return HttpResponseRedirect("../../add/")
else:
request.user.add_message(msg)
return HttpResponseRedirect("../../")
Another option would be to have the callable return a (url, message)
tuple, and let the view handle HttpResponseRedirect and
request.user.add_message. I think it depends on whether people think
it would be useful to do anything but a redirect on successful
adding/editing of an object using the admin system.
It would be nice to be able to override log_change_message in a
similar way as well, but I think rjwittams has something event based
in mind for that. I could be wrong.
At any rate, I think the new inner Admin class is a clean place to put
this kind of stuff.
Joseph
