Re: Ticket disposal

[Joseph Kocherhans]

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: Model validation incompatibility with existing Django idioms

[Joseph Kocherhans]

On Tue, Jan 19, 2010 at 1:04 AM, Raffaele Salmaso
<raffaele.salm...@gmail.com> 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.

Backwards-incompatible change for model validation

[Joseph Kocherhans]

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

[Joseph Kocherhans]

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.

Re: Model validation incompatibility with existing Django idioms

[Joseph Kocherhans]

On Sat, Jan 9, 2010 at 6:25 PM, Ivan Sagalaev
<man...@softwaremaniacs.org> 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

[Joseph Kocherhans]

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

[Joseph Kocherhans]

On Wed, Jan 6, 2010 at 4:46 PM, Jeremy Dunck <jdu...@gmail.com> wrote:
> On Wed, Jan 6, 2010 at 3:56 PM, Joseph Kocherhans <jkocherh...@gmail.com> 
> wrote:
> ...
>>>> On Wed, Jan 6, 2010 at 12:49 PM, Simon Willison <si...@simonwillison.net> 
>>>> 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

[Joseph Kocherhans]

On Wed, Jan 6, 2010 at 3:26 PM, Waylan Limberg <way...@gmail.com> 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 <jkocherh...@gmail.com> 
> wrote:
>> On Wed, Jan 6, 2010 at 12:49 PM, Simon Willison <si...@simonwillison.net> 
>> 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

[Joseph Kocherhans]

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: Finalizing model-validation: ComplexValidator

[Joseph Kocherhans]

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: Finalizing model-validation: ComplexValidator

[Joseph Kocherhans]

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.

Finalizing model-validation: ComplexValidator

[Joseph Kocherhans]

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: 1.2 Feature freeze

[Joseph Kocherhans]

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.

Re: Final Multi-DB status Update

[Joseph Kocherhans]

On Mon, Sep 14, 2009 at 12:16 PM, Alex Gaynor <alex.gay...@gmail.com> 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: For QuerySet qs, list(qs)[k] does not always equal qs[k]

[Joseph Kocherhans]

On Fri, Apr 24, 2009 at 4:49 PM, Karen Tracey  wrote:

>
> Note if we go with this approach (if I'm understanding it correctly) we are
> slightly changing the way in which we expect model formsets to be used.  We
> currently document that the same QuerySet should be passed in during POST as
> GET:
>
>
> http://docs.djangoproject.com/en/dev/topics/forms/modelforms/#using-a-custom-queryset
>
> Switching to an approach that uses the pk ids in the POST data for lookup
> means we'd:
>
> - silently ignore a queryset argument when we're given a data dictionary?
> - issue some sort of deprecation warning about the now-unnecessary and
> unused parameter?
>
> Also, it would be nice if we could accomplish the lookup in one DB call
> rather than looking up each individual item in a separate query.  Having a
> model formset with hundreds of entries suddenly require hundreds of DB hits
> during POST processing instead of one isn't too nice.  Not sure if you were
> planning that?
>
> These two concerns pushed me more towards thinking that leaving the DB
> lookup as-is and adding some validation sanity checks for when the passed
> queryset doesn't match up with the POST data might be a "good enough"
> approach.
>

My thought on this was to continue to use the queryset argument and do
something like qs.filter(pk__in=(list_of_pks)) for access restriction in
case someone decided it would be fun to play with the POST data and try to
change objects they shouldn't be allowed to.

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: For QuerySet qs, list(qs)[k] does not always equal qs[k]

[Joseph Kocherhans]

On Fri, Apr 24, 2009 at 2:01 PM, Karen Tracey  wrote:

>
> I don't see how to solve the general problem at the framework level, but
> there may be some additional sanity checks we could add to help out here.
> For instance we could make the formset validation return False if the number
> of items in the passed QuerySet is not what we expect based on the data
> dictionary, and/or check (during validation?) that the pk values in the post
> data match up to the instance pk values after we've matched them up, etc.
> To anyone with a better knowledge of model fomsets than me: does this sort
> of additional validation sound reasonable?
>

I might as well put this out there in case someone crazy like Alex wants to
try it. :) My thought for the hard way to fix the issue for formsets is to
use the primary key as part of the form prefix and/or put the primary keys
into hidden fields then use the data from the form to look up the objects.
It's obviously going to be more complicated than that (was the object
already deleted? is it allowed to be changed?), but it's an approach that
could work I think.

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: Search for the ORM and Haystack

[Joseph Kocherhans]

On Thu, Apr 23, 2009 at 6:50 PM, Ben Firshman  wrote:

>
> On 19 Apr 2009, at 11:42, mrts wrote:
> >
> > The feature is much needed, thanks for dealing with this!
> >
> > However, as for the API, I'd say coupling search to models is
> > inadvisable, Django has moved away from that design.
> >
> > A registry-based approach could be implemented:
>
> I agree this approach is better for external engines, but when just
> using SQL indexes, it makes a whole load of sense for it to be
> included in the ORM. I see "search_index" as just an extension of
> "db_index" and "unique".
>

Not to mention GeoDjango's spatial_index argument. There's certainly prior
art here. I agree that this approach would be entirely inappropriate for
solr, xapian, whoosh, etc. but it makes sense for SQL. Ben and I have
discussed this stuff at length over the last year, and I'm behind him 100%
on the design.


> # search in all registered models
>  search.all().query('alpha')
> > [,  > released>]
> >
>  search.model(Article, Book).query('alpha')
> > [,  > released>]
>
> Using SQL, there's no straight forward way of searching over multiple
> models. It could be done with another generic "document" model updated
> by signals, but this depends entirely on what fields you want to
> search over or filter by, so is quite site specific. I suppose some
> sort of magic abstract model could be provided if there is a need.


Not surprisingly, I agree with Ben on this too. Taking the registry +
post_save signals approach might make a useful third party app, but I don't
think it really needs to go into django proper. It really isn't that hard to
do on your own either.

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: Using form validation to prevent deletion no longer works (after rev 10206/ticket #9587)

[Joseph Kocherhans]

On Mon, Apr 6, 2009 at 3:09 AM, Dan Tallis  wrote:

>
> It's not clear to me from the thread so far whether there has been a
> decision to back out 10206


There hasn't been a decision. I'm still thinking about it.


> but, to add some more evidence, I would
> point out that it has also made it rather more awkward to process
> formsets: You can no longer iterate over form.formsets (e.g. in a save
> method) and consider cleaned_data, since it might not be present.
> Unless I've missed something, there's deleted_forms, but no analogous
> non_deleted_forms (which would help, but may still require quite a lot
> of applications to change their approach).


It was never possible to iterate over every form and blindly check
form.cleaned_data because it has never existed for invalid forms. The only
difference is that you can no longer expect cleaned_data to exist for every
form if formset.is_valid() returns True. You can still iterate over every
form, check form.is_valid(), and decide not to check form.cleaned_data
there. The change hasn't deleted form errors, they just don't prevent the
entire formset from being valid anymore.


> Also the documentation [1] includes code that will no longer work in
> general:
>
> >>> [form.cleaned_data for form in formset.deleted_forms]
>
> (may fail because form.cleaned_data will not be present if the form
> had 'delete' set but other field-level validation errors).
>

Ah. I'll need to change that at some point. Thank you for pointing it out.


> Thinking about possible ways forward, one observation that occurs to
> me is that I think there's a significant semantic distinction between
> field validation and form-level (non-field) validation that applies in
> this case:  Field validation errors on forms with delete should not
> cause formset is_valid to return False but perhaps form-level errors
> should...?
>

Ugh. Please no. This is the kind of subtlety that has been so terrible to
deal with in other languages. What Malcolm said still applies. Deleted data
is not data. Form validation is the wrong place to veto deletion. It is an
entirely separate thing. The only reason I'm considering rolling this back
instead of adding hook for deletion is because there likely won't be another
beta release, and we're very close to releasing 1.1. The fix probably
deserves a little more time and eyeballs than it would get. Rolling back is
just delaying the 3 lines of code you'll probably have to add once there's a
proper way to veto deletion.

I'll post to this thread if and when I decide to roll back the change. It's
spread across at least 4 different commits on different days. Rolling it
back is more than a 5 minute job.

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: Using form validation to prevent deletion no longer works (after rev 10206/ticket #9587)

[Joseph Kocherhans]

On Sun, Apr 5, 2009 at 11:33 AM, Dan Tallis  wrote:

>
> Prior to 10206, the formset is_valid returned False and the user saw
> the error messages as I intended.  From 10206 on, the formset is_valid
> returns True (because validation errors on forms marked for deletion
> "don't count") and so my view goes on to try to save the forms.
>
> So, is this an unintended consequence?  If so, please can it be backed
> out pending further design discussion?
>

We can't really have it both ways. Either validation errors on a form stop
deletion, or they don't. (Or there's a way to choose one or the other per
formset, but I'd like to avoid that.) The new behavior is more correct in my
view, and there should be a more specific way to veto deletion, but there's
no way to do that without making people who rely on the pre-10206
implementation write more code. That said, I'm inclined to back it out for
the 1.1 release. This has bitten at least one other person that I know of,
and it wasn't in the beta, so it will likely bite others who aren't tracking
trunk.

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: Changeset 10219 does not fix #9587

[Joseph Kocherhans]

On Tue, Mar 31, 2009 at 1:57 PM, Vinicius Mendes | meiocodigo.com <
vbmen...@gmail.com> wrote:


> On Mar 31, 3:35 pm, Joseph Kocherhans <jkocherh...@gmail.com> wrote:
> > On Tue, Mar 31, 2009 at 12:32 PM, Vinicius Mendes <vbmen...@gmail.com
> >wrote:
> >
> > > What do you think about reopening the ticket?
> >
> > You're right. The changeset only fixes plain formsets, not model formsets
> or
> > inline formsets. Normally, I'd say open a new ticket since it's a
> different
> > problem, but I'll work on a patch right now. A new ticket would just be
> > extra bookkeeping.
>
> I didn't understand, you think is better reopen the ticket, open a new
> ticket or don't do anything?
>

Alex is right. I was saying not to do anything. I just checked in a fix [1].
Please open a new ticket if you are still having problems.

Joseph

[1] http://code.djangoproject.com/changeset/10283

--~--~-~--~~~---~--~~
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: Changeset 10219 does not fix #9587

[Joseph Kocherhans]

On Tue, Mar 31, 2009 at 12:32 PM, Vinicius Mendes wrote:

> In the ticket description, the user says that he is using
> inlineformset_factory, so do I. The changeset only fixes the FormSet.
> ModelFormSet and InlineFormSet are still bugged. In the methods
> save_new_objects and save_existing_objects, you have to check if the form is
> marked for deletion, if so, delete the object or don't save it (in case of
> saving new objects).
>
> The framework is checking if the form is marked for deletion in
> cleaned_data, but the cleaned_data isn't created for invalid forms. I wrote
> a patch to solve this problem and was thinking about reopening the ticket,
> but always, when somebody reopens a ticket in the TRAC, commiters ask him to
> send an e-mail to de developers list.
>
> What do you think about reopening the ticket?


You're right. The changeset only fixes plain formsets, not model formsets or
inline formsets. Normally, I'd say open a new ticket since it's a different
problem, but I'll work on a patch right now. A new ticket would just be
extra bookkeeping.

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: DDN on #9284

[Joseph Kocherhans]

On Mon, Mar 23, 2009 at 7:17 PM, Malcolm Tredinnick <
malc...@pointy-stick.com> wrote:

>
> The approach looks better. I'd be tempted to lift a couple of those
> leading-underscore methods up to just being normal methods. Found myself
> having to override a few of those things lately when wanting to use the
> formset infrastructure in other ways. It won't kill us to allow inital-,
> total- and management-forms getters to be overridden, I don't think.
>

I'll probably make those methods public and check this in sometime during
the next few days at the PyCon sprint, maybe with some docs to the effect of
"you don't need to override these unless you're Malcolm". If anyone wants to
convince me to table this for 1.2, please speak up.

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
-~--~~~~--~~--~--~---

DDN on #9284

[Joseph Kocherhans]

#9284 [1] Has a patch to make BaseModelFormSet call ModelForm.save() when
saving objects rather than using completely custom code as it does now. I
think this is the "right thing (tm)" to do, but it will break people's code
who have overridden the formset's __init__ method and mucked around with the
"initial" argument. I don't really feel bad about said breakage, because
hey, you're messing with internals, you should know what you're doing.
Joseph

[1] http://code.djangoproject.com/ticket/9284

--~--~-~--~~~---~--~~
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: Recursive inlines in admin?

[Joseph Kocherhans]

On Thu, Sep 4, 2008 at 2:08 PM, Jeff Forcier <[EMAIL PROTECTED]> wrote:
>
> I'm imagining the ability to have recursive inline editing: e.g. in a
> simple hierarchy of Model C has FK to Model B has FK to Model A, when
> viewing the admin form for Model A, to not only have Model B as an
> inline, but to have Model C inlined inside the fieldset for Model B,
> allowing you to set up a slice of that entire hierarchy in one go.
>
> First: is this currently possible? It doesn't appear to be, based on
> poking around the API for the ModelAdmin hierarchy, nor does it seem
> possible to achieve it via forms/formsets (as there's no easy way to
> have a single form/formset represent >1 model at a time, AFAICT).

You're not missing anything. It isn't possible.

> Second: if not possible, is it desirable? I recognize that with any
> nontrivial hierarchy/number of extra objects per inline, the visual
> representation could become ghastly. But assuming its usage is limited
> to semi-trivial scenarios, it seems like the existing admin API could
> be very easily extended to support this. I haven't done serious
> investigation, but am thinking something like simply allowing/
> interpreting the 'inline' attribute on InlineModelAdmin (i.e. making
> InlineModelAdmin more closely resemble a subclass of ModelAdmin, which
> is probably the logical conclusion of this line of thought).

I'm pretty convinced that it isn't appropriate for the admin, but I'm
not convinced that something like that absolutely shouldn't be in
Django. It turns out that recursive inlines are hard. I tried pretty
hard to make it work in the early days of FormSets, but I couldn't get
all of the pieces moving in the right direction at the same time.

That said, I'm pretty stupid, and the fact that I couldn't figure
something out doesn't mean a whole lot. My suggestion to anyone who
wants to try this is to completely start over. Don't use the FormSet
code. It probably won't help you. Also, maybe take a look at
FormEncode. If I remember correctly, it can do such things.

I'd wager that none of the core devs are going to spend any time
implementing it, I certainly won't, but it would work just fine as a
third-party thing, and maybe with enough support could make it into
Django someday.

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: I want a pony: Django Cheeseshop

[Joseph Kocherhans]

On Wed, Sep 10, 2008 at 8:57 AM, James Bennett <[EMAIL PROTECTED]> wrote:
>
> On Wed, Sep 10, 2008 at 9:31 AM, mrts <[EMAIL PROTECTED]> wrote:
>>  * create a central app index à la Cheeseshop
>
> Doesn't the Cheese Shop already exist?
>
>>  * create an automated system similar to easy_install for installing
>> apps from
>>   o that central repository
>
> "easy_install django-registration" works fine for me right now. Why
> not encourage people to use standard Python practices for packaging
> and distribution?

So, if TurboGears hasn't rewritten setuptools, I think there's
probably a reason. They aren't idiots, and they're much better at this
packaging and dependency stuff than we are.

>>   o either globally to Python packages -- *but under django namespace!
>> *
>>   o or locally into a concrete project
>
> Does anybody else actually do this? Last I checked, Pylons, TurboGears
> and Zope apps didn't install or need to be installed into
> framework-specific locations. Django applications are just Python
> modules, and that's a *strength* from where I sit.

100% with James here. I had a discussion about namespace packages [1]
with Mark Ramm at PyCon, and hist short answer was "don't do it, it
isn't worth it". Seeing as he's the maintainer of TurboGears and
probably knows setuptools about as well as anyone, I'd tend to trust
him on that one. I understand the appeal, but the consequences aren't
worth it.

Joseph

[1] http://peak.telecommunity.com/DevCenter/setuptools#namespace-packages

--~--~-~--~~~---~--~~
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: Altering data uploaded to FileField before save is called

[Joseph Kocherhans]

On Wed, Sep 10, 2008 at 7:38 AM, Brian Rosner <[EMAIL PROTECTED]> wrote:
>
> On Wed, Sep 10, 2008 at 8:13 AM, shadfc <[EMAIL PROTECTED]> wrote:
>> The problem is that FieldFiles get saved to the storage backend even
>> on a save(commit=False), and (according to a more knowledgeable SeanL-
>> on #django), the FieldFile will only get saved once, the first time
>> through.  So the only way I can accomplish what I want is to do two
>> saves to my backend -- one when the formset is saved with commit=False
>> and then I must call the storage backend's save() directly in order to
>> upload the changes I've made to the mp3 file in memory.
>
> Ouch. In a formset sounds like you could be calling save up to N*2 times.
>
>> I think that the commit=False (or save=False in FieldFile.save() )
>> should not do the save to the storage backend.
>
> Agreed. I have been considering treating FileFields the same as
> many-to-many fields when commit=False in a ModelForm. In the event
> that commit=False a new method is available to perform the file saving
> explicitly. This would help in the event of wanting to name the file
> the same as the primary key for instance.

That sounds like a promising idea to me, but I'd want to see the
details. I was writing some code the other day that was trying to poke
the username into part of the upload_to path. I made it work with a
custom ModelForm __init__ method, but commit=False seems like it would
have been a lot cleaner, or at least that was my first instinct about
what to try.

To address Karen's backwards-incompatibility concern, perhaps a new
'commit_files' argument would be in order.

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 for dynamic form choices

[Joseph Kocherhans]

Dynamic choices become an argument to the form constructor. The
argument is a dictionary of fieldname, choices pairs where choices is
either the choices structure we currently use, or a queryset.

Define your model and form just like you normally would.

class Task(Model):
owner = models.ForeignKey(User)
status = models.IntegerField(choices=STATUS_CHOICES)

class TaskForm(ModelForm):
class Meta:
model = Task

Then in your view, create your choices and pass them to the form constructor.

choices = {
'owner': User.objects.filter(is_active=True),
'status': STATUS_CHOICES[1]
}
form = SomeForm(choices=choices)

Now your form *instance* has restricted choices, but your form *class*
is untouched, which is exactly what we want.

So that takes care of dynamic choices for forms, but what about
generic views and admin views? For the admin, use the same approach
discussed in #3987 [1]. We can do the same thing for generic views
once they are class based [2].

class SomeAdmin(ModelAdmin):
def choices_for_owner(self, request):
return User.objects.filter(is_active=True)

If we do the above, I think we can go ahead and close #2445 [3]. Are
there any other related tickets that I missed?

Joseph

[1] http://code.djangoproject.com/ticket/3987
[2] http://code.djangoproject.com/ticket/6735
[3] http://code.djangoproject.com/ticket/2445

--~--~-~--~~~---~--~~
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: Shared declarative syntax in both ModelAdmin and ModelForms.

[Joseph Kocherhans]

On Sun, Jul 6, 2008 at 9:01 AM, Yuri Baburov <[EMAIL PROTECTED]> wrote:
>
> Hi all,
>
> I'd like to propose the same declarative syntax for ModelAdmin as Ivan
> suggested for ModelForms below.
>
> ModelAdmin and ModelForms both are quite similar already in NFA, and I
> think it would be The Right Thing if 90% of their features to be the
> same and they will have only one implementation of the shared
> features.

Could you give an example? I'm not quite sure what you are proposing.

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: more DDN Tickets

[Joseph Kocherhans]

On Wed, Jun 25, 2008 at 5:03 AM, Russell Keith-Magee
<[EMAIL PROTECTED]> wrote:
>
> On Wed, Jun 25, 2008 at 1:18 PM, Jeff Anderson <[EMAIL PROTECTED]> wrote:
>> Here is another list:
>>
>> #6003 (from nfa-blocker)
>> #6450
>> #4148
>
> Done. #6003 needs a little more discussion; I'd like to hear the
> opinions of Brian and Joseph on that one; it's possible they have
> already given the idea some thought, particularly in the context of
> #6776.

We've discussed this on #django-dev before, and I don't have anything
very useful to contribute. I think we want to adopt a convention of
putting admin classes in admin.py, that part is pretty
uncontroversial, the problem is where to put the "imports for side
effects" code, and where to put an auto-discovery function, because
the only other alternative is throwing all your admin registrations
into your settings somehow.

More discussion is needed, but it seems like we're at a point where we
should be discussing a list of possible options. I forget what all of
them are, but maybe someone can write them up and post them 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-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: Django 1.0 roadmap

[Joseph Kocherhans]

On Mon, Jun 16, 2008 at 10:40 AM, Karen Tracey <[EMAIL PROTECTED]> wrote:
>
> Cool.  One question I have regarding dates is: is there a target date for
> merging newforms-admin back to trunk?  There's an nfa-sprint set for July
> 10-12th which makes it sound like it's still on a branch at that point, but
> an alpha release set for the 20th...by which point I expect nfa will have to
> be in trunk?  So is the merge targeted for somewhere between those two
> dates?  Personally I think earlier would be better, even if it introduces
> some trunk instability.  It is the remaining big thing for 1.0, I think
> wider community use/feedback than it gets on a branch would be valuable as
> soon as possible.

I'd like to merge it about a week before the sprint. (Hopefully I can
free up some time soon to help make that happen.) I think that would
give the sprinters a whole lot more to do. Most of the existing nfa
stuff is non-trivial right now, but I'd imagine there will be some
easier bugs discovered once more eyeballs are on the code.

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: #5731

[Joseph Kocherhans]

On Wed, Jun 11, 2008 at 11:55 AM, Jeff Anderson
<[EMAIL PROTECTED]> wrote:
> Hello.
>
> I'm interested in helping out with getting newforms-admin rolling (with 1.0
> in mind)
>
> Last night I went through some of the tickets and I'm comfortable re-working
> the patch for #5731.
>
> I'm contacting the list because the comments say to contact Joseph about the
> proposal to remove the legacy radio_admin code. I'm guessing it is
> appropriate to include discussion of development on the list instead of
> contacting him directly.
>
> Joseph, are you out there?

Commented. http://code.djangoproject.com/ticket/5731#comment:7

You might want to hop on #django-dev on irc.freenode.net to ask Brian
(brosner) if he's looked at it recently since the ticket is still
assigned to him.

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: Form rendering with filters

[Joseph Kocherhans]

On Wed, May 21, 2008 at 4:30 AM, Aral Balkan <[EMAIL PROTECTED]> wrote:
>
> Just a quick bump: has there been any progress on this?

Not really. I started the implementation on the plane ride back from
PyCon, realized that it wouldn't work *quite* the way I'd proposed
(widgets don't have access to form data, only BoundFields do), and
haven't gotten back to it yet.

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: newforms-admin FormSet API

[Joseph Kocherhans]

On Wed, May 21, 2008 at 8:44 AM, Russell Keith-Magee
<[EMAIL PROTECTED]> wrote:
>
> However, that said: I might be missing something here, but we've just
> gone through the process of deprecating form_for_model and
> form_for_instance based upon the reasoning that a class based form
> definition is more flexible than trying to shoehorn everything into a
> factory method. Is there a reason that we are introducing a new set of
> factory methods rather than using a definition analogous to ModelForm?
> To that end, isn't modelform_factory an analog of form_for_model?

Brian and I both tried to come up with a class based syntax to take
care of formsets, but everything we came up with felt forced... like
we were *just* doing it as an attempt at consistency. Our attempts
actually made the implementation worse. This is one of the reasons
Brian wrote the email though. If someone wants to propose a class
based syntax, please do so. I'd love to see something better, and I
have a hunch that there *is* a better way. I've been sitting on it for
a few months now, and nothing has come to me. I'm probably too close
to the problem though.

For the record, it was just form_for_instance that I really wanted to
see destroyed... form_for_model is actually pretty useful in some
cases. You'll notice that there's no _for_instance analogues in the
API ;)

> Regarding the docs - I'm sure Adrian will apply his magic pencil, but
> as a first draft, it looks pretty good to me. One suggestion - the
> 'can_order' option needs a little more elaboration on how the order
> field can actually be used - i.e., how do I use the order field to
> effect organization in my children?

Indeed. That might be a "not ready for primetime" feature right now.
It doesn't work with models yet, and it might be better to provide a
field class, or a widget for ordering and deletion.

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: GSoC proposition - djangosearch backend

[Joseph Kocherhans]

On Mon, Mar 31, 2008 at 11:39 AM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
>  Hi,
>
>  My name is Grzegorz Swierad and I am interested in participating in
>  Google Summer of Code for Django. I study in University of Zielona
>  Gora in Poland. I have more than one year experience with Django. I
>  create sites: http://mines20.com or http://plom.pl .
>
>  I wish to create a Xapian backend for djangosearch. Eventually, it can
>  be other search engine, but Xapian is more important for me, becouse I
>  use it in my new project.
>
>  What do you thing about this, and who is interested in mentoring it?

I know someone else is also putting together a proposal to work on
djangosearch backends, but please submit your proposal anyhow. I would
love to see a good xapian backend. A single backend might not be a big
enough project for SoC, so you might want to specify what else you'll
do in your proposal if you finish early.

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: TextIndexingAbstractionLayer and FullHistory branches for GSoC

[Joseph Kocherhans]

On Mar 27, 2:46 pm, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]>
wrote:
> On Thu, Mar 27, 2008 at 2:26 PM, Ben Firshman <[EMAIL PROTECTED]> wrote:
> >  What's the status on both of them? Do they still need to be finished?
>
> They are both defunct.
>
> >  Do you think they would be good GSoC projects?
>
> Starting from those branches? No. The state-of-the-art has moved on,
> and we've gotten wiser about how we maintain open projects.Search,
> for example, has a couple of third-party apps out there; working on
> any of 'em would make a good proposal. Full history isn't actually all
> that much work; look for Marty's AuditTrail (on the wiki) and you can
> see he's 80% of the way there in a few hundred LOC. Still, the last
> 20% is enough work that a project making AuditTrail into a bonafide
> extension might be good.

So this is kinda of late, and the deadline is coming up soon, but if
someone wants to add some new full text search backends to
djangosearch [1], I'll try to mentor you if you put together a good
proposal. :) Feel free to mail me off-list if you have any questions.

Joseph

[1] http://code.google.com/p/djangosearch/


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Custom management commands with django-admin.py (again)

[Joseph Kocherhans]

So, I've worked up a new patch that works for me with manage.py and
django-admin.py both with the settings flag and the environment
variable. The only real difference from the original is that now in
setup_environ, DJANGO_SETTINGS_MODULE is only set if it hasn't been
already. If the DJANGO_SETTINGS_MODULE was set to 'localsettings',
setup_environ was munging it to 'myproject.localsettings' I don't
really use setup_eviron, ever, so I'm not sure if this will have any
unintended consequences, but it seems reasonable to me. Anyone care to
test this or comment before I check it in?

http://code.djangoproject.com/ticket/5943

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: Class based generic views

[Joseph Kocherhans]

On Sat, Mar 8, 2008 at 2:57 PM, Gary Wilson Jr. <[EMAIL PROTECTED]> wrote:
>
>  Joseph Kocherhans wrote:
>  > I just uploaded a patch [1] for class based generic views that use
>  > ModelForm internally. Personally, I think this makes the generic views
>  > a lot more flexible, and gives us a great argument against
>  > adding-yet-another-config-argument-to-generic-views (even though I
>  > haven't heard that particular demand come up for awhile.) Just
>  > subclass the generic view, and do what you need.
>
>  I like the flexibility that the class-based approach brings.  I think a
>  similar idea could be used to clean up the duplication happening in the date
>  based generic views.  Anyone know if that has been attempted?

Not to my knowledge, but if someone else doesn't try it first, I'm
going to eventually. ;-) That goes for the list_detail ones as well.

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
-~--~~~~--~~--~--~---

Class based generic views

[Joseph Kocherhans]

I just uploaded a patch [1] for class based generic views that use
ModelForm internally. Personally, I think this makes the generic views
a lot more flexible, and gives us a great argument against
adding-yet-another-config-argument-to-generic-views (even though I
haven't heard that particular demand come up for awhile.) Just
subclass the generic view, and do what you need.

Anyhow, here's what I have in mind for the backwards compatibility story:

This patch leaves the old generic views as-is, using manipulators.
This partially fixes the problem, we get ModelForm based generic views
living side by side with the old manipulator based ones. People can
svn up without breaking anything, and convert their code at their
convenience. At some point I think we'll want to either get rid of the
old functions, or convert them to use the new classes (should be
trivial). Personally, I'd rather do the former, but I'm probably in
the minority there.

Malcolm has pointed out that the post_save method is probably not such
a great name. I agree. So, what color would *you* paint that
particular bikeshed?

Joseph

[1] http://code.djangoproject.com/ticket/6735

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Newforms admin relative image fields

[Joseph Kocherhans]

On Fri, Feb 15, 2008 at 11:46 AM, Michael Newman <[EMAIL PROTECTED]> wrote:
>
>  Let me know if there are any patches, I will gladly test. I don't even
>  have a clue where that error would be coming in from. I wish I did.
>  Thanks for the confirmation, Michael Newman

You might want to try an svn up. I just merged changes from trunk into
the newforms-admin branch, and if I remember correctly, there were
some fixes for File/ImageFields on trunk that hadn't made it in to the
branch yet.

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: ModelForms paranoia simplification?

[Joseph Kocherhans]

On Thu, Feb 14, 2008 at 1:14 AM, Malcolm Tredinnick
<[EMAIL PROTECTED]> wrote:
>
>  Any strong objections to not behaving like Python here?

No. Please make the change. I was looking at this the other day and
had one of those "did I really write this?" moments. Thank you for
taking care of #6337 [1] too. That should make it a lot easier for me
to get rid of my last nit with #6241.

Joseph

[1] http://code.djangoproject.com/ticket/6337
[2] http://code.djangoproject.com/ticket/6241

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

preventing syncdb from loading initial_data

[Joseph Kocherhans]

I ran into a situation today where for every future site I set up,
I'll want to load an initial_data fixture, but for some existing sites
that I'm upgrading, it's very useful to be able to run syncdb without
loading any fixtures. Thus http://code.djangoproject.com/ticket/6511

I'll write up the docs if this is generally thought of as a good thing
(tm). I imagine Russ might have something else in mind to accomplish
the same thing.

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: newforms-admin and django.contrib.auth

[Joseph Kocherhans]

On 12/16/07, James Bennett <[EMAIL PROTECTED]> wrote:
>
> While playing around a bit with newforms-admin, I noticed that it's
> ever-so-close to being able to handle one cool use case which came up
> during the design discussion at PyCon: running django.contrib.admin
> without django.contrib.auth.
>
> The implemention of has_permission() on AdminSite, and
> has_(add|change|delete)_permission() on ModelAdmin, gets it almost all
> the way there, but leaves two stumbling blocks:
>
> 1. Creating instances of LogEntry, which FK to
> django.contrib.auth.models.User, and
> 2. Creating instances of Message, which also FK to
> django.contrib.auth.models.User.
>
> Right now, you *can* work around this by overriding/duplicating a lot
> of code in ModelAdmin, but factoring out log entries and messages into
> methods -- similar to what's already been done with permission checks
> -- would make that unnecessary.
>
> I'm not particularly attached to these method names, but adding
> methods on ModelAdmin, say, log_action() and send_user_message(), and
> having the object-saving code call those methods instead of directly
> handling logging and messages, would solve this pretty cleanly (and
> also add a little bit more useful functionality for someone who wants
> to roll their own implementation of these features).
>
> Anyone have strong feelings one way or another?

+1 on the concept. There are details to figure out, for instance,
which method is in charge of generating the actual content of the
message, but it shouldn't be that difficult. I've been wanting this
for well, nearly as long as Django has existed. I'd lost sight of that
and didn't realize we were so close.

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: newforms-admin and django.contrib.auth

[Joseph Kocherhans]

On 12/17/07, Ivan Sagalaev <[EMAIL PROTECTED]> wrote:
>
> James Bennett wrote:
> > This means the default implementation can happily use
> > django.contrib.auth and the existing is_staff flag and permission
> > system, but that using something else is as easy as subclassing and
> > overriding the right methods. And with a little refactoring to remove
> > the direct reliance on the LogEntry and Message models, it would be
> > easy to run the Django admin without django.contrib.auth
> When you say 'without django.contrib.auth' does it mean that one can
> ditch User model but still use django.contrib.auth to call custom
> AUTHENTICATION_BACKENDs, use it's context processor to populate {{ user }}?

I don't want to speak for James, but that's how I see 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?hl=en
-~--~~~~--~~--~--~---

Re: ModelForm.__init__() argument signature versus other newforms forms

[Joseph Kocherhans]

On 12/12/07, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
> On 12/11/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> >
> >
> > On Mon, 2007-12-10 at 20:56 -0600, Joseph Kocherhans wrote:
> > > On 12/9/07, James Bennett <[EMAIL PROTECTED]> wrote:
> > > >
> > > > OK, so after chatting a bit with Joseph on IRC I'm working on revising
> > > > my original patch. The changes it makes still need some discussion, so
> > > > I'll outline them here.
> > > >
> > > > 1. The "instance" argument to ModelForm.__init__() essentially becomes
> > > > a keyword argument defaulting to None, and moves out of the first
> > > > position in the argument list.
> > > > 2. If "instance" is None, the model to generate a form for will be
> > > > determined by the "model" attribute of the ModelForm's inner Meta
> > > > class.
> > > > 3. Defining a ModelForm subclass without specifying "model" in the
> > > > inner Meta class, and without passing "instance" when instantiating
> > > > the form, is an error and raises ImproperlyConfigured (same as other
> > > > errors, such as a ModelForm which tries to define itself for multiple
> > > > models at once).
> > > >
> > > > This would mean that the snippet of code in my original reply to
> > > > Joseph would actually work, and that a ModelForm could be defined
> > > > without being bound to any particular model, still accept the "fields"
> > > > and "exclude" options, and then determine the model to work with at
> > > > instantiation time. That feels kind of neat to me, but is probably
> > > > worth debating.
> > >
> > > I'm close to checking this in and adding a note to
> > > BackwardsIncompatibleChanges, but I'm still a little uneasy about
> > > generating the form fields at form instantiation time. It just feels
> > > weird to me, but I can't really come up with any actual reasons why. I
> > > mean, I think the functionality is neat, but I'm not comfortable with
> > > the syntax.
> > >
> > > Anyone have opinions or reasoning one way or the other?
> >
> > I don't feel particularly worried about the current implementation. It's
> > neater when a class is nice and complete after __new__ and before
> > __init__, but if the implementation or use pattern requires otherwise,
> > it's rarely a showstopper and for ModelForm, it's not likely that a lot
> > of introspection will be needed that couldn't just look at
> > MyForm.Meta.fields, etc.
> >
> > I'll just note:
> >
> > (1) The new line 186 in the tests (in the second patch on #6162) shows
> > quite clearly, I think, why this change is a good idea. The current
> > version is from the Department of Redundancy Department a bit when
> > creating a simple form. So the motivation behind this change is a net
> > win. I don't think there's much controversy there, but don't forget this
> > big picture when worrying about the details.
> >
> > (2) The bits that seem to be worrying you are caused by your own
> > use-case of wanting to be able to specify fields without a model and
> > only pass in the model later. If you always had 'model' in the Meta
> > class, you could create the whole thing at class construction time (in
> > __new__()). I wouldn't lose a lot of sleep if that particular use-case
> > wasn't supported by this class. It's a whole three or four lines in a
> > helper function if somebody wanted to create such a form where they
> > specify the fields in one place and the model much later and I suspect
> > it's not going to be an everyday thing. Keep in mind this is still a
> > helper function, not an indispensable piece of core functionality and if
> > the implementation becomes a lot simpler by not handling a minor case,
> > be pragmatic.
> >
> > So if you committed it unchanged, we'd be fine. If you simplified
> > __init__, required Meta.model in all cases and moved a lot of that logic
> > to __new__, we'd also generally be happy campers and your inner design
> > genie would probably feel more relaxed.
>
> Thanks for thumping me with the YAGNI stick. ;-) I've fixed the
> signature bit, and left the part about requiring a model for every
> ModelForm unimplemented for now. I want to think about it a bit more.
> Actually, I tried requiring model, and ran into a metaclass problem
> that I don't want to think about tonight. (Something due to ModelForm
> 

Re: Writing tests for #6191 (admin delete view not listing all items)

[Joseph Kocherhans]

On 12/12/07, Nick Lane <[EMAIL PROTECTED]> wrote:
>
> I had a quick look at writing some tests for #6191[1], and have a few
> queries.
>
> Should I be testing the admin delete view to make sure the response
> contains the expected items, or should I just test the "private"
> _get_deleted_objects() method, to check the items are returned in that
> list?

Just testing _get_deleted_objects() is fine by me if you can. I think
the AdminSite object might be intertwined with things in the
newforms-admin branch, so there may still be a bunch of setup.

> P.S. I used Mercurial queues to do the patch, but not sure how to spit
> out a diff in a way which is useful in trac.

Trac will store the actual text of the patch, even if it doesn't
display it correctly. I'm just going to download it and apply it
anyhow, so seeing the pretty web interface doesn't matter much 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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: ModelForm.__init__() argument signature versus other newforms forms

[Joseph Kocherhans]

On 12/11/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
>
>
> On Mon, 2007-12-10 at 20:56 -0600, Joseph Kocherhans wrote:
> > On 12/9/07, James Bennett <[EMAIL PROTECTED]> wrote:
> > >
> > > OK, so after chatting a bit with Joseph on IRC I'm working on revising
> > > my original patch. The changes it makes still need some discussion, so
> > > I'll outline them here.
> > >
> > > 1. The "instance" argument to ModelForm.__init__() essentially becomes
> > > a keyword argument defaulting to None, and moves out of the first
> > > position in the argument list.
> > > 2. If "instance" is None, the model to generate a form for will be
> > > determined by the "model" attribute of the ModelForm's inner Meta
> > > class.
> > > 3. Defining a ModelForm subclass without specifying "model" in the
> > > inner Meta class, and without passing "instance" when instantiating
> > > the form, is an error and raises ImproperlyConfigured (same as other
> > > errors, such as a ModelForm which tries to define itself for multiple
> > > models at once).
> > >
> > > This would mean that the snippet of code in my original reply to
> > > Joseph would actually work, and that a ModelForm could be defined
> > > without being bound to any particular model, still accept the "fields"
> > > and "exclude" options, and then determine the model to work with at
> > > instantiation time. That feels kind of neat to me, but is probably
> > > worth debating.
> >
> > I'm close to checking this in and adding a note to
> > BackwardsIncompatibleChanges, but I'm still a little uneasy about
> > generating the form fields at form instantiation time. It just feels
> > weird to me, but I can't really come up with any actual reasons why. I
> > mean, I think the functionality is neat, but I'm not comfortable with
> > the syntax.
> >
> > Anyone have opinions or reasoning one way or the other?
>
> I don't feel particularly worried about the current implementation. It's
> neater when a class is nice and complete after __new__ and before
> __init__, but if the implementation or use pattern requires otherwise,
> it's rarely a showstopper and for ModelForm, it's not likely that a lot
> of introspection will be needed that couldn't just look at
> MyForm.Meta.fields, etc.
>
> I'll just note:
>
> (1) The new line 186 in the tests (in the second patch on #6162) shows
> quite clearly, I think, why this change is a good idea. The current
> version is from the Department of Redundancy Department a bit when
> creating a simple form. So the motivation behind this change is a net
> win. I don't think there's much controversy there, but don't forget this
> big picture when worrying about the details.
>
> (2) The bits that seem to be worrying you are caused by your own
> use-case of wanting to be able to specify fields without a model and
> only pass in the model later. If you always had 'model' in the Meta
> class, you could create the whole thing at class construction time (in
> __new__()). I wouldn't lose a lot of sleep if that particular use-case
> wasn't supported by this class. It's a whole three or four lines in a
> helper function if somebody wanted to create such a form where they
> specify the fields in one place and the model much later and I suspect
> it's not going to be an everyday thing. Keep in mind this is still a
> helper function, not an indispensable piece of core functionality and if
> the implementation becomes a lot simpler by not handling a minor case,
> be pragmatic.
>
> So if you committed it unchanged, we'd be fine. If you simplified
> __init__, required Meta.model in all cases and moved a lot of that logic
> to __new__, we'd also generally be happy campers and your inner design
> genie would probably feel more relaxed.

Thanks for thumping me with the YAGNI stick. ;-) I've fixed the
signature bit, and left the part about requiring a model for every
ModelForm unimplemented for now. I want to think about it a bit more.
Actually, I tried requiring model, and ran into a metaclass problem
that I don't want to think about tonight. (Something due to ModelForm
subclassing BaseModelForm, which doesn't, and shouldn't have a inner
Meta class.) I think the worst that will happen is slightly cryptic
error messages if someone forgets model, forgets to pass instance, and
the form tries to call None like it was a class.

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: ModelForm.__init__() argument signature versus other newforms forms

[Joseph Kocherhans]

On 12/9/07, James Bennett <[EMAIL PROTECTED]> wrote:
>
> OK, so after chatting a bit with Joseph on IRC I'm working on revising
> my original patch. The changes it makes still need some discussion, so
> I'll outline them here.
>
> 1. The "instance" argument to ModelForm.__init__() essentially becomes
> a keyword argument defaulting to None, and moves out of the first
> position in the argument list.
> 2. If "instance" is None, the model to generate a form for will be
> determined by the "model" attribute of the ModelForm's inner Meta
> class.
> 3. Defining a ModelForm subclass without specifying "model" in the
> inner Meta class, and without passing "instance" when instantiating
> the form, is an error and raises ImproperlyConfigured (same as other
> errors, such as a ModelForm which tries to define itself for multiple
> models at once).
>
> This would mean that the snippet of code in my original reply to
> Joseph would actually work, and that a ModelForm could be defined
> without being bound to any particular model, still accept the "fields"
> and "exclude" options, and then determine the model to work with at
> instantiation time. That feels kind of neat to me, but is probably
> worth debating.

I'm close to checking this in and adding a note to
BackwardsIncompatibleChanges, but I'm still a little uneasy about
generating the form fields at form instantiation time. It just feels
weird to me, but I can't really come up with any actual reasons why. I
mean, I think the functionality is neat, but I'm not comfortable with
the syntax.

Anyone have opinions or reasoning one way or the other?

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: Fixing app_label

[Joseph Kocherhans]

On 12/9/07, Gary Wilson <[EMAIL PROTECTED]> wrote:
>
> Vinay Sajip wrote:
> > On Dec 7, 6:35 pm, "Marty Alchin" <[EMAIL PROTECTED]> wrote:
> >> On Dec 7, 2007 12:56 PM, Vinay Sajip <[EMAIL PROTECTED]> wrote:
> >>
> >>> this be allowed/disallowed/checked for? As for standard template
> >>> loading, there's no reason that the standard template loading
> >>> (app_loader) code could not be modified to work with App instances,
> >>> using whatever logic to use the application path and/or label to
> >>> locate the templates. Or have I misunderstood Malcolm's comment?
> >> The problem here is that a distributed app has to expect specific
> >> paths to its templates, both for its views (for render_to_response,
> >> for instance) and its templates (for extends and include). If my
> >> template says "{% extend 'modular/module.html %}', what would happen
> >> if someone had "App('modular', name='mod_app')"? How would the extends
> >> tag be able to locate the correct template if someone essentially
> >> renamed the app?
> >>
> >
> > The current code in django/template/loaders/app_directories.py appears
> > to search in the directory 'templates' relative to the directory
> > containing the app module. I can't quite see why this needs to change:
> > it's independent of the app label, shouldn't that be OK?
>
> It does look in the "templates" directory of the application directory;
> however, it gets treated as a standard, global template directory.  Current
> practice is to repeat the name of your application inside the "templates"
> directory to avoid name collisions.  For example:
>
> myblogapp/templates/myblogapp/base.html
>
> So even if you were to specify an app_label of "blog" for this app, you would
> still have to reference the templates as "myblogapp/base.html".
>
> The current app_directories template loader has always bugged me because it 
> is:
>
> 1) inefficient - all application template directories are added as global
> template directories and are searched each time by the template loader.
>
> 2) unpredictable - any application could, unbeknownst to the developer,
> override another application's templates.  For example, an application could
> include an "admin" directory in its "templates" directory that overrides admin
> templates.
>
> 3) not DRY - just silly I have to make my "templates" directory one level
> deeper with a duplicated name.
>
> For those of you that have stopped using the app_directories loader in favor
> of the standard filesystem loader and TEMPLATE_DIRS, what was your reasoning
> behind doing so?
>
> And doesn't doing things this was cause the same problems?  Every directory
> added is going to get searched as a global template directory.  You're still
> going to have the unpredictability of apps possibly overriding templates of
> other apps.  You are still going to be repeating yourself by having to put the
> app in INSTALLED_APPS and its template directory in TEMPLATE_DIRS.
>
> I have always thought that you should be able to put an app's templates in its
> "templates" directory and that those templates should only be accessible when
> using the app name in front of it, like "myblogapp/base.html".  The
> "myblogapp/templates" directory should not be looked at in any other case, and
> only global template directories are looked at every time by the filesystem
> template loader.
>
> This should also work with custom app_naming, since now the templates would be
> accessible with the custom name, i.e. "blog/base.html".  This would also work
> if you had two instances of an app running under two different names, i.e.
> "blog1/base.html" and "blog2/base.html".  And I could still override these in
> a global template directory with directories named "blog1" and "blog2".

FWIW I pretty much agree with Gary. And surprisingly, I actually agree
with myself of two years ago when we discussed this before [1] [2].
There's also another related thread [3] and a ticket [4] that Adrian
and Jacob both agreed to mark as wontfix. Their arguments against such
a template loader are in the ticket. They have a valid point, but
changing the app_directories template loader still seems like the
cleanest way to deal with custom app_labels and templates to me. Maybe
this will prompt ideas for another solution though.

Joseph

[1] 
http://groups.google.com/group/django-developers/browse_thread/thread/7197d27127494ee2/df18ee9b91ba383c
[2] http://groups.google.com/group/django-developers/msg/f10d34ebd266fbe2
[3] 
http://groups.google.com/group/django-developers/browse_thread/thread/49bf270495624a4/8e99219f87db975f
[4] http://code.djangoproject.com/ticket/1586

--~--~-~--~~~---~--~~
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 

Re: ModelForm.__init__() argument signature versus other newforms forms

[Joseph Kocherhans]

So, I'm going to pretend you didn't say anything about rearranging
positional arguments because a) it doesn't work, and b) your patch
doesn't do that. So, my response will assume that you are suggesting
that instance become a keyword argument rather than the first
positional argument, and that if 'instance' isn't given, the ModelForm
will create one.

On 12/8/07, James Bennett <[EMAIL PROTECTED]> wrote:

[snip]

>
> Right now I'm
> curious as to why, if it already knows from its Meta class what model
> it's working with, ModelForm *always* needs an instance of the model;

The ModelForm doesn't *always* know what the model is though. You can
build a ModelForm *without* using an inner Meta class. The use case
may be a bit of a stretch, but here it is: Imagine a few models that
have latitude and longitude fields. You could build a ModelForm for
lat/long that would work with any one of these objects since the
ModelForm isn't bound to a particular model until it's instantiated.
The only requirement is that the fields names are the same. Yes, I'm
aware this isn't an argument to *always* require an empty model, you
could get the same effect and only require an empty instance for
ModelForms that haven't already been tied to a particular model.

> it seems that it'd be better for 'instance' to default to None, and
> have ModelForm be smart enough to create its own instance when none is
> supplied.

We can't always do so for the reasons stated above.

> This would also preserve backwards compatibility with the
> general historical trend of "forms that create model instances" --
> neither AddManipulator nor form_for_model have ever required users to
> supply their own empty instance, and ModelForm's requirement of an
> instance in all cases makes generic form-handling code somewhat
> tortuous.

Turning instance into a keyword argument optimizes the syntax for the
add case over the change case (right now it's vice versa). Meh. Code
churn. But, it does have the benefit of making the constructor
signature of Form and ModelForm the same. I can see people tripping up
on the differences... a lot in fact. My original intent with making it
positional was to encourage people to assign defaults to a new model
object before passing it to the form rather than doing the
form.save(commit=False) dance. I knew it was heavy handed, but it
feels even more so now.

> Anyone have strong objections to either of these proposals?

I'm fine with changing the method signature, but I really think you
patch should handle the use case I mentioned before though. It
shouldn't be that difficult.

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: Fixing app_label

[Joseph Kocherhans]

On 12/5/07, Ivan Sagalaev <[EMAIL PROTECTED]> wrote:
>
> Adrian Holovaty wrote:
> > The settings file syntax could look like this:
> >
> > INSTALLED_APPS = AppCollection(
> > App('django.contrib.admin'),
> > App('ellington.news'),
> > )
>
> Why not also use actual module objects here instead of strings like with
> view functions in urlconfs?

I don't see the benefit. It makes sense for views so you can apply
decorators to them  in your urls.py file. I'm not sure what you'd want
to do with a module. The less you actually import into your settings
file, the better IMO.

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: newforms-admin change history

[Joseph Kocherhans]

On 12/3/07, Karen Tracey <[EMAIL PROTECTED]> wrote:
> On 12/3/07, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
>
> >
> > On 12/3/07, Karen Tracey <[EMAIL PROTECTED]> wrote:
> > > In testing out the latest (r6864) newforms-admin branch I noticed that
> the
> > > change history for items I changed always said "No fields changed." even
> > > though I was changing fields.  Looking at the code I see it's because
> the
> > > old change history code is commented out, with a big TODO comment.  I
> don't
> > > know if I should open a ticket for stuff like this?  Or add it to the
> TODO
> > > list on the wiki page for the branch?  Or...?
> >
> > Opening a ticket would be the way to go if there isn't one open already.
>
> Didn't see one so I opened one, #6117.  From a brief look it seems to me the
> way to determine what has changed would be to compare the cleaned_data
> values for fields to the corresponding initial values?  If you think that's
> the right general approach,  I could take a look at working up a patch. (Or
> if there's a different approach that should be taken, you could point me in
> that direction.)

So I've thought a little bit about putting access to "what's changed"
in the BaseModelForm class. It would be a very nice feature to have,
it could be lazy, and the modelform already has access to the original
object *and* the form data. No idea what the API would look like
though. If you want to propose something, I'll certainly participate
in the discussion.

I suppose it *could* go in BaseForm, but the pattern there seems to be
"use initial, or use data, but not both".

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: newforms-admin change history

[Joseph Kocherhans]

On 12/3/07, Karen Tracey <[EMAIL PROTECTED]> wrote:
> In testing out the latest (r6864) newforms-admin branch I noticed that the
> change history for items I changed always said "No fields changed." even
> though I was changing fields.  Looking at the code I see it's because the
> old change history code is commented out, with a big TODO comment.  I don't
> know if I should open a ticket for stuff like this?  Or add it to the TODO
> list on the wiki page for the branch?  Or...?

Opening a ticket would be the way to go if there isn't one open already.

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 includes auto-escaping as of [6776]

[Joseph Kocherhans]

The subject says it all. I think most of you using the newforms-admin
branch know better than to just svn up at random, but this is a pretty
big change, so here's your warning. Note that quite a few things in
django.contrib.admin had to be merged by hand since the original code
was moved, or no longer exists, so there are probably some escaping
bugs still lurking there. If you have time to test it out in the near
future, please do so so we can get bugs filed and fixed during the
sprint.

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?hl=en
-~--~~~~--~~--~--~---

Re: django-admin.py can't access user-supplied commands, even if --settings option is provided

[Joseph Kocherhans]

On 11/14/07, Todd O'Bryan <[EMAIL PROTECTED]> wrote:
>
> Hey Russ,
>
> It looks like you made it impossible to call user-supplied commands
> using django-admin.py, even if the user specifies a --settings option
> which would give the apps and thus provide the commands. My patch for
>
> http://code.djangoproject.com/ticket/5516
>
> specifically handles the --settings and --pythonpath options before
> attempting to access any information about the command so that
> django-admin.py gets the same access to app-provided commands as
> manage.py.
>
> Was there a reason you added
>
> self.user_commands = False
>
> to django.core.management.ManagementUtility, or did you just not
> realize that the code checked to see if --settings was used and did
> the right thing?

Hey Todd, I haven't looked at you patch, but here's what Russ
mentioned when I asked:

http://groups.google.com/group/django-developers/browse_thread/thread/fb148adb454b74ef/789da4389cf33295?lnk=gst=kocherhans+django-admin#789da4389cf33295

Hope you can put something together though. I want this, but don't
really have time to hack on it in the near future.

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: ModelForms

[Joseph Kocherhans]

On 11/12/07, Marty Alchin <[EMAIL PROTECTED]> wrote:
>
> On Nov 12, 2007 3:37 PM, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
> > class MyForm(ModelForm):
> > extra_field = SomeField()
> >
> > class Options:
> > model = MyModel
> > fields = ['list', 'of', 'field', 'names']
> >
> > def formfield_callback(db_field):
> > # return a formfield for the given db field
> >
> > def save(self, commit=True):
> > # override save if you need to
> >
> > def clean(self):
> > # override clean if you need to
> >
>
> Call me crazy, but why would formfield_callback even be needed in this
> case? Wouldn't it be possible supply customized fields as attributes
> of the class, alongside the extra_field assignments? It just seems
> counterintuitive to have some fields defined one way, with other
> fields defined in another way.

The admin (at least in newforms-admin) is still going to need
*something* like formfield_callback, but I haven't figured out the
details yet. In most cases though, you're right. I'll spell out the
details quickly though:

class Article(models.Model):
title = models.CharField(max_length=100)
body = models.TextField

class ArticleForm(models.Model)
body = MyCustomBodyField() # override the default formfield

class Options:
model = Article

The resulting form here would still have 2 fields, title and body.
body would have a custom form field, and title would have the default
one.

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: ModelForms

[Joseph Kocherhans]

On 11/11/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
>
> The problem I have with ModelForm is that it doesn't feel like it has
> any parallels with the existing class-based formdefinitions. Manual
> Form definitions have a very similar flavour to Model definitions -
> each class attribute is a part of the model/form, etc. On one level,
> ModelForm tries to follow this lead by using a class-based syntax and
> allowing save() and clean() methods - but then it has a completely
> different approach to defining form fields, etc. In contrast,
> form_for_* doesn't looks anything like a manual form definition, so
> it's obvious that you're dealing with a different beast.

I see your point and I've been increasingly unhappy with my original
syntax for exactly those reasons, though you put it a lot more
eloquently than I would have. :) I came up with a new hybrid this
morning that I think addresses both of our concerns, and to me feels a
lot better than either of them.

class MyForm(ModelForm):
extra_field = SomeField()

class Options:
model = MyModel
fields = ['list', 'of', 'field', 'names']

def formfield_callback(db_field):
# return a formfield for the given db field

def save(self, commit=True):
# override save if you need to

def clean(self):
# override clean if you need to

This also allows for forms that have all their fields built by hand,
and not bound to any particular model class until instantiation:

class LatLongForm(ModelForm):
latitude = SomeCustomField()
longitude = SomeCustomField()

# Note there is no inner Options class and thus no model specified
# This form will work on any model instance with fields named
# 'latitude' and 'longitude'

def save(self, commit=True):
# override save if you need to

def clean(self):
# override clean if you need to

This way a Form still doesn't need its constructor changed, only the
ModelForm takes and object and has a save method.

To go along with this, I'd like to slightly change the signature of
the ModelForm constructor to this:

def __init__(self, obj, data=None, files=None...):

This would force people to instantiate and pass in an empty object for
add forms, and hopefully encourage a pattern of setting any defaults
on a model instance before you pass it to the form. I'm hoping this
will mean less people need to muck around with form.save(commit=False)
and the form.save_m2m() method.

> > The whole idea of a formfield callback is powerful, but it really
> > lacks in readability for the common tasks of specifying custom widgets
> > and excluding specific fields.
>
> Agreed. I would also add dynamically modifying the list of choices in
> a Select to this list of deficiencies.

I think during the last sprint we decided to add another custom method
type to forms to handle this. I thought there was a different ticket
that dealt with forms, but #3987 [1] is the closest I could find.
Maybe I'm just dreaming things up though.

[1] http://code.djangoproject.com/ticket/3987

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: ModelForms

[Joseph Kocherhans]

On 11/9/07, Marty Alchin <[EMAIL PROTECTED]> wrote:
>
> On Nov 9, 2007 9:57 AM, Marty Alchin <[EMAIL PROTECTED]> wrote:
> > The only thing it doesn't handle yet is how to remove
> > fields from the customized form, but this might be as simple as
> > assigning the field to None or some new ExcludedField class or
> > something.
>
> I actually like the idea of an ExcludedField. ExcludedFields wouldn't
> be output in HTML, and wouldn't be expected in the incoming data, but
> would be set in the constructor instead, using keyword arguments. Take
> the following example.
>
> class Article(models.Model):
> author = models.ForeignKey(User)
> title = models.CharField(max_length=255)
> body = models.TextField()
>
> class ArticleForm(forms.ModelForm(Article)):
> author = forms.ExcludedField()
> body = myapp.ReStructuredTextField()
>
> def new_article(request):
> if request.method == 'POST':
> form = ArticleForm(request.POST, author=request.user)
> if form.is_valid():
> obj = form.save()
> ...
> else:
> form = ArticleForm(author=request.user)
>
> Using this, is_valid would return False if author wasn't set in the
> constructor, unless ExcludedField was declared using required=False. I
> don't think it'd be necessary to deal with validating the data on an
> ExcludedField though, since it would only get set in Python code.
> Setting it to the wrong type would be a code error, not an input
> error.

Why not just do this? No need for any special new fields at all.

class Article(models.Model):
author = models.ForeignKey(User)
title = models.CharField(max_length=255)
body = models.TextField()

class ArticleForm(ModelForm):
model = Article
exclude = ['author']

def new_article(request):
article = Article(author=request.user)

if request.method == 'POST':
form = ArticleForm(request.POST, obj=article)
if form.is_valid():
obj = form.save()
...
else:
form = ArticleForm(obj=article)

It's the business of the form to know what the user is supposed to
provide. In this case, author needs to be provided by the programmer,
and if the programmer screwed up and saving the Article raises an
error due to a missing author field, there's nothing the user can do.
Adding extra machinery to handle stuff like that in the form seems
overly complicated 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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: ModelForms

[Joseph Kocherhans]

On 11/9/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
>
> If we're kicking around ideas on this, here's a slightly different
> suggestion. First, an example:
>
> class MyForm(Form):
> extra_field = forms.CharField()
>
> class Meta:
> model = MyModel
> fields = ('a','b')
> def formfield(f):
> return ...
>
> def save():
>...
>
> i.e., rather than writing a new ModelForm base class, put the
> 'form_for_*' stuff into a Meta class (Meta probably isn't the right
> name, but it will do for now), which is used by the BaseForm metaclass
> as a set of assembly instructions for how to add model/instance based
> fields to MyForm.
>
> If you provide a Meta class, any of the field/exclude declarations are
> used to add new fields to the model; if there is a formfield() method
> on the Meta class, it is used to determine which Field class will be
> used.
>
> The fields added from the Meta class augment those provided manually
> (useful for the 'form_for_model plus these extra fields' use case,
> such as is required for password validation). If you need custom
> save/clean methods, you put them right in the form definition where
> they are required, which is exactly what you would do if you were
> manually defining the form from scratch.

The reason I like the ModelForm class is that it provides a clear
separation between a form that knows about models and one that
doesn't. I love that the basic newforms Form has no clue what a Django
model is. Using ModelForm makes it possible to write a SQLAlchemyForm
or a SQLObjectForm. I don't see that happening with the Meta syntax.

I like that your proposed syntax makes it very clear that this is just
a form, it's ok to go ahead and define clean methods on it, etc. The
ModelForm syntax would take documentation, but would behave the same
way.

The ModelForm syntax the rough implementation would look like this (I
emphasize rough):

class BaseModelForm(BaseForm):
# leaving a bunch of other kwargs out here for brevity
def __init__(self, data=None, files=None, obj=None, initial=None):
# get_initial_data pulls data out of the obj as a dict
obj_data = get_initial_data(obj)
# possibly do this:
# obj_data.update(initial)
self.obj = obj
super(BaseModelForm, self).__init__(data, files, initial=obj_data)

def save(self, commit=True):
# mostly a copy of save_instance here.

I'd hate to see the obj arg get put into the constructor of a
BaseForm, so Form's metaclass would end up generating a subclass of
BaseForm or BaseModelForm depending on whether or not the Form had an
inner Meta class (or whatever we call it). The implementation of the
ModelForm syntax seems cleaner to me, but there's most likely a better
way to implement your syntax that I haven't thought of.

Also, I'd like to see more attributes added to ModelForm, but I didn't
want to pollute the core proposal with a bunch of other ideas that may
not sit as well. I'd love to see something like this, but I'd like to
consider these after the foundation is laid:

class MyForm(ModelForm):
model = MyModel
extra_fields = {
'some_field': IntegerField()
}
widgets = {
'existing_field': CustomWidget()
}

def clean(self):
# do some custom cleaning
return self.cleaned_data

The whole idea of a formfield callback is powerful, but it really
lacks in readability for the common tasks of specifying custom widgets
and excluding specific fields.

> > The biggest problem I see is that this would be entirely backwards
> > incompatible with the way form_for_model and form_for_instance work
> > now. (especially the latter) It *may* be possible to change form_for_X
> > into some sort of hackish wrappers, but it wouldn't be pretty.
>
> If we decide to go down this path, I would prefer to see the
> form_for_* APIs deprecated and removed, rather than maintained as
> wrappers. If a wrapper is trivial, there's no real harm in keeping it
> around, but if its going to take a lot of effort to build and
> maintain, we could end up with a bigger bug hole and image problem
> than if we just grit our teeth and rip the band-aid off in one swift
> action.

I don't think the maintenance would be particularly difficult, but the
implementation would be ugly (probably not difficult, but ugly), and
it leaves "more that one way to do it". I may change my mind once I
actually *write* said wrappers, so I'd rather postpone this discussion
until we're talking about some actual code.

> This obviously means preparing the path well - lots of prior warning
> that the change will happen, maybe a release before the change comes
> into effect, plus public commentary on _why_ we're making such a big
> change, a mea culpa for getting it wrong in the first place, and good
> documentation on how to manage the change. However, 

ModelForms

[Joseph Kocherhans]

form_for_model and form_for_instance seem like complicated and clever
ways to accomplish what basically boils down to a form that has a save
method and can accept a model instance in its constructor method.

I propose we (or I rather) actually build it that way before 1.0.

Form declaration:

class MyForm(ModelForm):
model = MyModel

#optional
def save(self, commit=True):
# do custom save stuff here if needed

Usage:

def add_view(request):
if request.POST:
form = MyForm(request.POST)
if form.is_valid()
obj = form.save()
...
else:
form = MyForm()
...

def change_view(request, id):
obj = MyModel.objects.get(pk=id)
if request.POST:
form = MyForm(request.POST, obj=obj)
if form.is_valid()
obj = form.save()
...
else:
form = MyForm(obj=obj)
...

ModelForm would be a declarative class that requires, at minimum, a
model attribute. Other attributes would include:

- formfield_callback (a function that takes a db field and **kwargs
and returns a form field or None)
- fields (a list of field names to include in the form)
- exclude (a list of field names to exclude from the form)

The biggest problem I see is that this would be entirely backwards
incompatible with the way form_for_model and form_for_instance work
now. (especially the latter) It *may* be possible to change form_for_X
into some sort of hackish wrappers, but it wouldn't be pretty.

If we don't actually do this, I'll eventually release it as a 3rd
party package, but having it around would make some things in
newforms-admin a lot more sane to implement.

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: Overriding a Model's save() method does not allow proper creation of ManyToMany related objects

[Joseph Kocherhans]

On 11/7/07, Dmitri Fedortchenko <[EMAIL PROTECTED]> wrote:
>
> The Admin class should be able to define post_ and pre_save hooks that are
> called before or after all Manipulation of the model is done (there are
> post_save hooks for the save method, but they are still called before the
> Manipulator is done working with the model)

Something similar is in progress already.
http://code.djangoproject.com/wiki/NewformsAdminBranch

It is however, mostly undocumented and subject to change. These things
take time :)

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
-~--~~~~--~~--~--~---

No custom management commands for django-admin.py?

[Joseph Kocherhans]

I looked around in the various tickets and threads for the reasoning
behind this, and wasn't able to find anything. Is there a particular
reason django-admin.py doesn't load custom commands? Changing this
line [1] makes everything work fine in my tests.

Is it just that it would require you to specify settings? (via
--settings or $DJANGO_SETTINGS_MODULE) Seems like catching the
ImportError and issuing a friendly warning "Custom commands will not
be loaded because settings were not specified", or maybe even failing
silently would work fine.

Joseph

[1] 
http://code.djangoproject.com/browser/django/trunk/django/core/management/__init__.py#L150

--~--~-~--~~~---~--~~
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: Hook to clear sensitive session data?

[Joseph Kocherhans]

On 10/17/07, Jeremy Dunck <[EMAIL PROTECTED]> wrote:
>
> We have a use case where we'd like to store some adhoc data that's
> related to a user in their session.
>
> I note that contrib.auth.logout just deletes these session keys:
> SESSION_KEY = '_auth_user_id'
> BACKEND_SESSION_KEY = '_auth_user_backend'
>
> I'd like an additional batch of keys to be deleted (or, more to the
> point, all keys *except for a few*) when logout is called.
>
> Of course I could have a separate function that does it and call that
> any time logout gets called, but I'd prefer not to have to do that.
> Since the data is sensitive, it seems like using a facade function or
> a kwarg would be too easy to screw up.
>
> What do you think about adding a setting, AUTHENTICATION_ON_LOGOUT,
> which supplies an importable or callable?
>
> I guess a signal could do it, too.
>
> Signature something like:
> def on_logout(session_wrapper, old_user)

Personally, I prefer signals to settings in this case. I planned on
adding pre/post login/logout signals, but so far haven't needed them.

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: formset_for_model() and the form prefix

[Joseph Kocherhans]

On 10/15/07, akaihola <[EMAIL PROTECTED]> wrote:
>
> Am I correct in my conclusion that formset_for_model() in the newforms-
> admin branch doesn't offer any convenient way to define the form's
> prefix?

You define a prefix when you instantiate the FormSet, not when you
define the class. It works the same as Form.

> Is my best option currently to subclass BaseModelFormSet and override
> the defalt value of the prefix= kwarg in its __init__()?
>
> If so, wouldn't it make sense to offer prefix= as a kwarg for the
> formset_for_model() and formset_for_form() functions?

If you really want to make a base class with a different default value
for prefix, then yes, that's exactly what you should do. I'm a strong
-1 on adding prefix to any of the formset_for_x functions.

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: form_for_model exclude_fields

[Joseph Kocherhans]

I'd like to add an 'exclude_fields' keyword argument to
form_for_model, etc. exclude_fields would be a list of field names
that should be excluded from the form. If both 'fields' and
'exclude_fields' were passed in, exclude_fields would win for any
field that existed in both lists. Any objections or issues that need
further clarification?

I know the argument list for form_for_model is getting long, but
excluding fields is just so damn useful ;)

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: Discussion on #5721

[Joseph Kocherhans]

On 10/10/07, Brian Rosner <[EMAIL PROTECTED]> wrote:
>
> I hope someone understands what I am getting at.

I do. You've pretty much discovered one of the reasons why I didn't
try to write formset_for_instances or something similar in the first
place. I just spent about a half hour thinking about it again and came
to the same conclusions. If you want to come up with a patch, I'll
definitely take a look and help try to iron it out, but as you've
already discovered, it's tricky. FWIW I'm working on a replacement for
form_for_instance that uses initial_data, but it'll probably be awhile
before I finish it up.

The oldforms file widgets have 2 separate html inputs, a hidden one
for the current file value, and second for the actual file input. I
think getting the file widget/field to render and check for such a
hidden field might be a cleaner and easier approach. The initial_data
function may need to be tweaked slightly to get this to work. I don't
remember what it does with file fields.

For instance, html for an oldforms file field looks like this:




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: A couple of newforms-admin questions

[Joseph Kocherhans]

On 10/10/07, Karen Tracey <[EMAIL PROTECTED]> wrote:
>
> At 05:10 PM 10/10/2007, Joseph Kocherhans wrote:
> >On 10/10/07, Karen Tracey <[EMAIL PROTECTED]> wrote:
> > > I'm also curious about something not on the to-do list: something to
> > > replace the old radio_admin Field attribute.  It seems radio_admin is
> > > still allowed on fields, but has no effect on the field's display in
> > > newforms-admin.  Is the plan to remove radio_admin and provide
> > > similar functionality in the new scheme (similar to raw_id_fields
> > > maybe?).  Or...?  (I'm asking because I could take a look at doing
> > > whatever the plan is, if you're just needing someone with a little
> > > time to spend on doing it.  It definitely seems that at a minimum
> > > radio_admin ought to be disappearing?)
> >
> >You're probably right. Something like radio_admin_fields on the
> >ModelAdmin class sounds reasonable. Could you file a ticket for this
> >so we don't lose track? I don't recall seeing one, but I could be
> >wrong.
>
> I couldn't find one either, so I opened one:
>
> http://code.djangoproject.com/ticket/5731
>
> I'll probably take a look at what's involved in doing it, but given
> my unfamiliarity with the code it's quite possible someone else could
> whip up a patch sooner.

Here's a hint that will hopefully help you (or anyone else really) get
started: this should probably happen in the formfield_for_dbfield
method of the ModelAdmin class.

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: A couple of newforms-admin questions

[Joseph Kocherhans]

On 10/10/07, Karen Tracey <[EMAIL PROTECTED]> wrote:
>
> The branch page for newforms-admin
> (http://code.djangoproject.com/wiki/NewformsAdminBranch) has
> 'Implement "edit inline" functionality' on the to-do list.  But the
> new syntax for inline editing is listed further down, and it all
> seems to work fine for my site newly converted to newforms-admin.  Is
> the to-do list just out of date or is there more to be done with edit inline?

Mostly the to-do list is out of date. edit_inline is pretty much
functional at this point. There are still a bunch of somewhat obscure
bugs in trac that may or may not still be applicable.

> I'm also curious about something not on the to-do list: something to
> replace the old radio_admin Field attribute.  It seems radio_admin is
> still allowed on fields, but has no effect on the field's display in
> newforms-admin.  Is the plan to remove radio_admin and provide
> similar functionality in the new scheme (similar to raw_id_fields
> maybe?).  Or...?  (I'm asking because I could take a look at doing
> whatever the plan is, if you're just needing someone with a little
> time to spend on doing it.  It definitely seems that at a minimum
> radio_admin ought to be disappearing?)

You're probably right. Something like radio_admin_fields on the
ModelAdmin class sounds reasonable. Could you file a ticket for this
so we don't lose track? I don't recall seeing one, but I could be
wrong.

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: Django 100% threadsafe with DB?

[Joseph Kocherhans]

On 9/25/07, Graham Dumpleton <[EMAIL PROTECTED]> wrote:
>
> Can we please somehow settle this issue once and for all. I have tried
> to get discussions going on this issue in the past but have got
> minimal feedback. I thought that too a degree it had been determined
> that multithreaded servers were okay, although users should though
> ensure there own code is multithread safe, but now again someone is
> saying that Django itself is not multithread safe. :-(

I talked with Jacob about this quite a while ago and he told me that
Django was not originally written to be threadsafe. The only threading
problems I remember hearing about were with the database connections,
and those issues were fixed in #1442 [1]. To my knowledge, there has
never been any review of the code to check for other possible sticky
spots. I used to deploy Django on Windows and never had any threading
problems, but the sites were mostly low traffic, internal, and
probably not good candidates for exposing problems.

In short, Django was not *designed* to be threadsafe, but any obvious
problems that I'm aware of have been fixed. YMMV.

Joseph

[1] http://code.djangoproject.com/ticket/1442

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: newforms-admin still broken?

[Joseph Kocherhans]

On 9/24/07, andybak <[EMAIL PROTECTED]> wrote:
>
> As far as I can tell newforms-admin has been broken for the last week.
> Add and change pages are broken for most objects (I think any with a
> foreign key) and the error given is something like:
> TypeError at /admin/cms/keyword/add/
> instancemethod expected at least 2 arguments, got 0
>
> It appears that 5505 is at least good enough as a temporary patch but
> this patch is itself now broken against the current newforms-admin in
> SVN. It's fairly easy to modify the patch but anyone using newforms-
> admin needs to:
> a) really that the rather cryptically named 5505 relates to the
> breakage in admin
> b) work out how to fix the patch.

I just committed http://code.djangoproject.com/changeset/6415 which
fixes the issue. I still think that this should be solved in the base
Widget class, as I have said in #5505, but I'm not going to make that
call, and this will do for now.

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: changeset 6391

[Joseph Kocherhans]

On 9/20/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
>
> My initial reaction to the problem was to think about adding an 'app
> prefix' when you deploy an app, much like a form prefix, that is
> injected into the template context to affect the resolution of {% url
> %} tags. However, thinking about the implementation and consequences
> of such a change this early on a Friday morning is making my brain
> hurt.

*Sigh* after thinking about it briefly, I don't see any obvious or
easy solutions either. I think I'm going to file a ticket about the
url tag and multiple sites, and when I merge newforms-admin next, I'm
not going to integrate this particular changeset. If anyone sees any
possible alternatives that can be implemented quickly (and thus, not
hold up a merge) please speak up.

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: changeset 6391

[Joseph Kocherhans]

On 9/20/07, Gary Wilson <[EMAIL PROTECTED]> wrote:
>
> So last night I checked in changeset 6391, and this morning it hit me that
> this breaks things for anyone using the admin application at more than one URL
> since the url tag cannot handle cases where multiple instances of an
> application are being used.  This may not be as big an issue for the current
> trunk since having multiple instances of the admin application doesn't make
> too much sense, but it is one of the features touted for newforms-admin.

Making better use of the url tag in the admin templates was on my long
term todo list. That changeset just gives me motivation to figure it
out earlier since I'll need to do so next time I merge changes from
trunk into the newforms-admin branch. I guess I could just *not*
integrate that particular changeset, but I would feel dirty if I
didn't. :)

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
-~--~~~~--~~--~--~---

Setting pk to None before sending post_delete signal

[Joseph Kocherhans]

What is the reasoning (or is there any) behind setting an object's pk
to None before sending the post_delete signal? A swapping of lines [1]
would change it. I could just listen for the pre_delete signal, but I
don't actually want to do what I'm going to do (remove some data in an
external system) if one of the pre_delete listeners stops deletion.

My gut reaction is that this shouldn't happen, but I'm assuming it's
there for a reason.

http://code.djangoproject.com/browser/django/trunk/django/db/models/query.py#L1183

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: copy.deepcopy for newforms' Bug ?

[Joseph Kocherhans]

On 9/17/07, andybak <[EMAIL PROTECTED]> wrote:
>
> >From my experience and a post on Django-users I think this has also
> broken the newforms-admin change and add pages.

It appears that newforms-admin add and change pages are broken if your
model has a ForeignKey or ManyToManyField that isn't in raw_id_fields.
I haven't seen if the patch(es) in #5505 fix it though.

[6342] is the changeset that triggers the breakage. I haven't dug
through it yet though. It's the first post-friday merge of trunk into
newforms-admin, so there's a lot there. I'll take a look tonight.

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: Change ModelAdmin 'fields' to 'fieldsets'

[Joseph Kocherhans]

On 9/8/07, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
>
> On 9/8/07, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
> > Any serious opposition?
>
> Not at all -- this sounds perfectly sensible, and a good improvement.

Committed in [6080]. I don't think anything in there makes Russell's
suggestions about fieldsets going in newforms any harder than they
were. In fact, it would probably be easier to do now.

Also, this changeset makes either fields or fieldsets restrict the
fields on the actual newforms Form objects (by passing the flattened
field names to form_for_model.) That way there aren't any fields that
exist in python, but aren't displayed. It's possible that you can
shoot yourself in the foot this way by not providing required fields
to the db layer, but those bugs are a lot easier to track down than
the ones where you get errors from the form, that aren't displayed on
the page anywhere. (I'm sure we've all done that one almost every
singe time we're using fieldsets and add a required field to 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: ANN: newforms-admin syntax change for inlines

[Joseph Kocherhans]

On 9/9/07, pm13 <[EMAIL PROTECTED]> wrote:
>
> I think that there was call of function "formset_for_model" in each
> request (ModelAdmin.get_inline_formsets -> inline_formset ->
> formset_for_model). But now this method is called from
> ModelAdmin.__init__ (ModelAdmin.__init__ ->  InlineModelAdmin.__init__
> -> inline_formset -> formset_for_model).

Why does that cause a problem for you?


> So if I have two users with different query, I can't cache it. But it
> is not possible to have 100 SQL queries (if I have 100 rows). I see
> only two solution - use the previous variant (and call
> formset_for_model in each request) or somehow intelligently bind form,
> its fields and formset (but it seems to be complex). But I don't know
> django well - maybe there are other possibilities. What do you think?

I can't interpret what you mean by this. Could you try explaining it
another way?


> I created example of the first solution:
> http://code.djangoproject.com/ticket/5372

The patch you attached in that ticket looks like it will solve your
problem, and in fact, you can just subclass TabularInline or
StackedInline, override the formfield_for_dbfield on you subclass, and
add the property from your patch. No patch to Django needed. What am I
missing?

Could you explain why this snippet wouldn't work?

CachingStackedInline(StackedInline):
def formfield_for_dbfield(self, db_field, **kwargs):
if isinstance(db_field, models.ForeignKey):
kwargs['cache_choices'] = True
return super(InlineModelAdmin,
self).formfield_for_dbfield(db_field, **kwargs)

def _formset_class(self):
return forms.inline_formset(self.parent_model, self.model,
fk_name=self.fk_name, formfield_callback=self.formfield_for_dbfield,
extra=self.extra)
formset_class = property(_formset_class)

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: ANN: newforms-admin syntax change for inlines

[Joseph Kocherhans]

On 9/8/07, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
> If you use the newforms-admin branch and the edit inline
> functionality, you want to read this.
>
> I'm planning on breaking the current syntax for defining inlines in
> the very near future, but I figured I'd warn people and ask for
> comments first.

I've checked this in as r6072. No factory functions yet. I'll probably
hold off on those until the sprint, or start another thread.

http://code.djangoproject.com/changeset/6072

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: ANN: newforms-admin syntax change for inlines

[Joseph Kocherhans]

On 9/9/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
>
> On 9/9/07, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
> >
> > If you use the newforms-admin branch and the edit inline
> > functionality, you want to read this.
> >
> > I'm planning on breaking the current syntax for defining inlines in
> > the very near future, but I figured I'd warn people and ask for
> > comments first. Currently it's something like this:
>
> I don't have any partiular objections to the new syntax, but can you
> give a quick rundown of why these changes are necessary? The only
> reason that comes to my Sunday-addled brain at the moment is that it
> would make 'inline within an inline' forms easier to write. Is this
> the reason, or is there another that I'm missing?

Would you believe me if I just said it makes the internals *much* more
consistent and easier to understand? It's part of a refactoring that
changes the wrapper classes related to inlines use a lot more of the
existing admin form wrapper constructs. A desire to refactor things
and http://code.djangoproject.com/ticket/4491 is where this started.

I suppose I could make the syntax backwards-compatible by naming the
factory functions the same as the existing classes, but I think it
would make things more confusing.


> Also - how does this affet the proposal to merge the 'inlines' clause
> into the 'fields' clause (and following your other proposal - the
> 'fieldsets' clause)? Again, I can't see any reason why it shouldn't be
> possible, but I wanted to make sure we weren't making a rod for our
> own backs.

If we decide to put inline definitions into fields or fieldsets, this
change won't make it any more difficult. I'd rather cross that bridge
a little later though. I have thought about both the syntax and the
implementation for that and I have a few ideas, but I don't have the
time to dedicate to it just yet.

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: Change ModelAdmin 'fields' to 'fieldsets'

[Joseph Kocherhans]

On 9/9/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
>
> On 9/9/07, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
> >
> > I'd like to change the 'fields' attribute on ModelAdmin to
> > 'fieldsets', and use 'fields' for a tuple of field names rather than a
> > list of (fieldset_name, options) tuples. Only one of those two options
> ...
> > Any serious opposition?
>
> Sounds ok to me - with the need for one clarification. What happens if
> I specify both a fields and a fieldsets argument? Is fields ignored?
> Is it merged into the 'none' fieldset? Used as the none fieldset as
> long as one isn't specified?

I think django.core.management.validation should verify that only one
of the two is defined and issue an error if they both are.


> I also have one slightly larger suggestion in this area: that we
> extract fieldsets out of contrib.admin and put them in
> newforms-proper, and expose a fieldsets argument into the
> form_for_model/instance functions. For my money, the options for
> ModelAdmin should be a match for what forms_for_model/instance can do
> (although obviously the admin options will be augmented somewhat to
> expose nifty widgets, behavior etc.). If we need a feature for admin,
> chances are an end users will need it for their forms.

I'd really hate to see any more display logic go into BaseForm. The
Admin wrapper classes work quite well, and will be even better once I
clean them up a bit. I'd rather see their more generic parts extracted
out into django.newforms.display or possibly a new contrib package.
Maybe something like this:

form = form_for_model(MyModel)
fieldsets = [
('my fieldset', {'fields': ['one', 'two', 'three'],
'description': 'blah'})
html_form = HTMLForm(form, fieldsets)

HTMLForm's __iter__ would iterate over Fieldset objects, etc. Pretty
much exactly like the admin wrapper classes do now. It isn't quite as
convenient as directly passing fieldsets into form_for_model, but it
would allow people the flexibility that they're going to scream for
once they think they can define all their display stuff in python
rather than writing 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?hl=en
-~--~~~~--~~--~--~---

ANN: newforms-admin syntax change for inlines

[Joseph Kocherhans]

If you use the newforms-admin branch and the edit inline
functionality, you want to read this.

I'm planning on breaking the current syntax for defining inlines in
the very near future, but I figured I'd warn people and ask for
comments first. Currently it's something like this:

class MyModelAdmin(ModelAdmin):
inlines = [
StackedInline(MyModel, extra=2)
]

In order to fix a few newforms-admin bugs, the inline class will take
the parent model and the AdminSite object as arguments to its
constructor. This means that the 'inlines' attribute will need to be a
list of classes rather than a list of instances now. The most obvious
way to do it looks like this:

class MyInline(StackedInline):
model = MyModel
extra = 2

class MyModelAdmin(ModelAdmin):
inlines = [
MyInline
]

I'm still thinking about a more convenient syntax for the simple case,
probably a couple of factory functions that act like the old
StackedInline and TabularInline classes.

I'm thinking something like:

class MyModelAdmin(ModelAdmin):
inlines = [
stacked(MyModel, extra=2)
]

where stacked is a function that makes a new class that inherits from
StackedInline, applies the kwargs to that class and returns it. Other
ideas are welcome.

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: Change ModelAdmin 'fields' to 'fieldsets'

[Joseph Kocherhans]

I'd like to change the 'fields' attribute on ModelAdmin to
'fieldsets', and use 'fields' for a tuple of field names rather than a
list of (fieldset_name, options) tuples. Only one of those two options
should be specified. In addition, the fieldsets_add and
fieldsets_change methods would return a list of (fieldset_name,
options) tuples rather than actual Fieldset objects.

class MyAdmin(ModelAdmin):
fields = ('one', 'two', 'three')

would be eqivalent to:

class MyAdmin(ModelAdmin):
fielsets = (
(None, {'fields': ('one', 'two', 'three')})
)

I think those changes make admin configuration a little more
consistent and understandable, and it would help me simplify the
implementation a bit. Changing 'fields' to a plain old list would make
it more consistent with prepopulated_fields, raw_id_fields, and
search_fields. Essentially, the current 'fields' argument is really
specifying fieldsets anyhow, not fields.

Any serious opposition?

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: Reason why SlugField doesn't subclass CharField?

[Joseph Kocherhans]

On 9/6/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> On 9/6/07, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
> > Is there any particular reason that django.db.fields.SlugField doesn't
> > inherit from CharField?
>
> I can't think of any reason why it doesn't subclass CharField -- go for it.

Done in 6056.

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
-~--~~~~--~~--~--~---

Reason why SlugField doesn't subclass CharField?

[Joseph Kocherhans]

Is there any particular reason that django.db.fields.SlugField doesn't
inherit from CharField? I've come up with 2 possible fixes for
prepopulated_fields in newforms-admin.

1. copy the formfield method for CharField over to SlugField
 or
2. make SlugField inherit from CharField

The formfield isn't being initialized correctly, so the newforms
CharField thinks its max_length is None. Option 2 seems much cleaner,
and obvious to me, so of course my initial reaction is that it doesn't
inherit for a reason. :) All tests pass with option 2.

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: Let's schedule a Django sprint

[Joseph Kocherhans]

On 9/5/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> It's about time we scheduled an official Django sprint. We've got a
> bunch of features that are almost done but haven't yet been
> committed/merged -- including newforms-admin, ORM aggregate support,
> multi-DB support and GeoDjango. Plus, we've got almost 1,000 open
> tickets in our ticket system. Let's spend 24 hours (or maybe even more
> than a single day?) to get some of this done in an organized fashion,
> and also to encourage new people to contribute.
>
> I propose Friday, September 14. Some reasoning:

Count me in, for the weekend as well.

/me hopes he can kind of recreate a conference environment at home.

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: I need fix "non proper sql server support" in the next 3 weeks. What is next?

[Joseph Kocherhans]

On 7/31/07, mamcx <[EMAIL PROTECTED]> wrote:
>
> So, how proceed? To how I need to talk?

These 2 posts are probably the best summary of the status of SQL Server support:

http://groups.google.com/group/django-developers/browse_thread/thread/68cceeea79921b07/0dbdeb1a8c01bae4?lnk=gst=%22sql+server%22+OR+mssql=15#0dbdeb1a8c01bae4

http://groups.google.com/group/django-developers/browse_thread/thread/c0b856250887e848/a8dd0f1cf99a5d86?lnk=gst=jeremy+dunck+sql+server=9#a8dd0f1cf99a5d86

Which patch did you look at and what version of Django are you using?
You might be able to get some SQL Server support working in 3 weeks,
but I don't think you will be able to solve the pagination problem in
that amount of time.

Also, even if you do get SQL Server support working in 3 weeks, you
will have to maintain your own version of Django. Oracle support took
several months before it was checked into the trunk, and they had a
whole team of people working on it and committed to maintaining 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?hl=en
-~--~~~~--~~--~--~---

Re: Edit inline in newforms-admin branch (ATTN: Joseph Kocherans)

[Joseph Kocherhans]

On 6/26/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
>
> On 6/20/07, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
> >
> > Yep. None of the javascript stuff really works right now. The calendar
> > and picker widgets for date and time fields, for instance, are broken.
>
> Sounds like a good opportunity to plug ticket #4418 - widget level
> support for specifying media (javascript/css) requirements.
>
> I haven't gone back to retrofit this into newforms-admin (or even had
> a chance to look at the new edit-inline stuff), but I'd be interested
> on any feedback on how the edit-inline changes would affect this
> approach.

Thanks for bringing this up Russ. The problem at the moment is that
the admin doesn't look at any of the inlines when figuring out what
javascript to load, so if your inlines have date fields, the js
doesn't get loaded unless the parent has a date field. I don't think
#4418 causes any problems for the new edit inline stuff. In fact it
makes it easier.  I was going to have to solve the duplicate problem,
but I forgot about #4418. I think the widgets for each inline model
just need to be included with the widgets from them main form when
combining each widget.media together.

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: Inline editing without a parent model

[Joseph Kocherhans]

On 6/24/07, Tomi Pieviläinen <[EMAIL PROTECTED]> wrote:
>
> Will there be a possibility to use edit_inline with a model that
> doesn't have a parent model in newforms admin? It would be really
> useful to see other lines when you need to input relatively same data
> (and I was planning to hack some kind of copy functionality in).
> If this is not going to happen, I'll just start making my own (with
> formsets, I suppose) but I'd prefer to avoid duplication.

I don't think something like that would go into the admin system
anytime soon. That said though, doing it yourself should be *much*
less painful with newforms-admin using formset_for_model and/or
BaseModelFormSet from django.newforms.models. Beware though, the api
still isn't completely stable.

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)

[Joseph Kocherhans]

On 6/19/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> Hi, I've been trying this out as the new inline functionality in
> newforms-admin branch but I've found one problem: raw_id_admin fields
> aren't rendered correctly in inline fields. They are still rendered as
> select widgets.
>
> Is this a known issue that is being worked on?

Yep. None of the javascript stuff really works right now. The calendar
and picker widgets for date and time fields, for instance, are broken.
The configuration will be different for raw_id fields as well. For
example:

class MyModelAdmin(models.ModelAdmin):
inlines = [StackedInline(MyModel, raw_id_fields=('field1', 'field2'))]

That code doesn't work yet, but that will probably be how to do it.
Christian Metts is helping me out with some template changes to make
things look nicer now that each object has a deletion checkbox. Once I
get his work integrated, I'll start on stuff like raw_id fields. If
you want to file a ticket against newforms-admin, that would be great.
Thanks for testing 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?hl=en
-~--~~~~--~~--~--~---

Re: Edit inline in newforms-admin branch (ATTN: Joseph Kocherans)

[Joseph Kocherhans]

On 6/9/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> On 6/8/07, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
> > I'm most of the way there. Basically just template stuff and a little
> > bit of ModelAdmin code is left. I got stuck a few times keeping this
> > stuff usable outside the admin, and at multiple levels. I think it was
> > worth the effort, but time will tell. Expect to see a working version
> > checked in next week. Maybe sooner. And huzzah! core=True is no longer
> > necessary.
>
> This is great news. Looking forward to it!

I just checked in a bunch of changes.
http://code.djangoproject.com/changeset/5473

The templates still need some work, ok... a lot of work. I need to
write some more tests, and I'm going to rework some of the internals,
but things are pretty much functional.

Feel free to start filing bugs and asking questions, but please ask
them in a new thread. And to answer many people's first question, no,
you cannot have inlines inside of inlines. If you want that, you're on
your own, and good luck ;) The second question, no, inline file
uploads don't work right now, but I plan on making that happen at some
point.

Joseph


from django.db import models
from django.contrib.admin import site, ModelAdmin, StackedInline, TabularInline

class Poll(models.Model):
question = models.CharField(maxlength=255)

def __str__(self):
return self.question

class Choice(models.Model):
poll = models.ForeignKey(Poll)

choice = models.CharField(maxlength=255)
votes = models.IntegerField()

def __str__(self):
return self.choice

class PollAdmin(ModelAdmin):
inlines = [TabularInline(Choice, extra=2)]

class ChoiceAdmin(ModelAdmin):
list_display = ['choice', 'poll', 'votes']

site.register(Poll, PollAdmin)
site.register(Choice, ChoiceAdmin)

--~--~-~--~~~---~--~~
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: Custom field _post_create_sql()

[Joseph Kocherhans]

On 5/29/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> Malcolm's _get_field_sql() question is a good one -- I'm +1 on adding
> that method to the fields. Only thing is, does _get_field_sql() get
> passed the database backend?

If the method is going in, I think passing in the db backend would be
a great idea along with pushing django.db.backends.X.creation into the
specific field classes.

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?

[Joseph Kocherhans]

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
-~--~~~~--~~--~--~---

runtest.py slowdowns?

[Joseph Kocherhans]

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: Edit inline in newforms-admin branch (ATTN: Joseph Kocherans)

[Joseph Kocherhans]

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
-~--~~~~--~~--~--~---

Re: Two field-related suggestions for newforms.models

[Joseph Kocherhans]

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)

[Joseph Kocherhans]

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: Edit inline in newforms-admin branch (ATTN: Joseph Kocherans)

[Joseph Kocherhans]

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: Two field-related suggestions for newforms.models

[Joseph Kocherhans]

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)

[Joseph Kocherhans]

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: Edit inline in newforms-admin branch (ATTN: Joseph Kocherans)

[Joseph Kocherhans]

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)

[Joseph Kocherhans]

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: Upcoming changes to the Django admin

[Joseph Kocherhans]

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
-~--~~~~--~~--~--~---