Re: Ticket disposal

On Mar 2, 2010, at 4:28 PM, Peter Sagerson wrote: > Hello, > > I submitted a patch[1] for 1.2 which was not accepted and almost certainly > won't be in the future. This is perfectly fine, but it would be nice to get > the bug closed wontfix so we have some closure (people are still adding >

Re: Model validation incompatibility with existing Django idioms

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 ru

Backwards-incompatible change for model validation

I just committed r12206 [1] which contains a few backwards-incompatible changes to model validation. First off, ModelForm used to validate your entire model and raise UnresolvableValidationError for any model fields that had errors, but were excluded from the form. Now, ModelForm will only

Re: Model validation incompatibility with existing Django idioms

On Wed, Jan 6, 2010 at 12:49 PM, Simon Willison wrote: > A couple of related tickets filed today about model validation: > > http://code.djangoproject.com/ticket/12513 > http://code.djangoproject.com/ticket/12521 This has been fixed in r12206 [1]. Could people who had

Re: Model validation incompatibility with existing Django idioms

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']) >>          

Re: Model validation incompatibility with existing Django idioms

On Wed, Jan 6, 2010 at 12:49 PM, Simon Willison wrote: > A couple of related tickets filed today about model validation: > > http://code.djangoproject.com/ticket/12513 > http://code.djangoproject.com/ticket/12521 > > The first one describes the issue best - the new model

Re: Model validation incompatibility with existing Django idioms

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> >>&g

Re: Model validation incompatibility with existing Django idioms

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

Re: Model validation incompatibility with existing Django idioms

On Wed, Jan 6, 2010 at 12:49 PM, Simon Willison wrote: > A couple of related tickets filed today about model validation: > > http://code.djangoproject.com/ticket/12513 > http://code.djangoproject.com/ticket/12521 > > The first one describes the issue best - the new model

Re: Finalizing model-validation: ComplexValidator

On Sun, Jan 3, 2010 at 7:34 PM, Alex Gaynor wrote: > > What if we had some sort of wrapper class for objs, it could overide > __getattribute__ to return either an attr if it's an obj, or a > subscript if it's a datadict.  it seems to me this would solve both > concerns? I

Re: Finalizing model-validation: ComplexValidator

On Sat, Jan 2, 2010 at 4:34 PM, Sean Bleier wrote: > > As for the timeline, I think that if complex validators are left as-is > then of course it isn't a deal breaker for inclusion to trunk before > the major feature freeze on January 5th.  However, If complex > validators

Finalizing model-validation: ComplexValidator

Model validation is just about ready to go. I have one small issue with it, namely with ComplexValidator, which I'll describe below, but I think we can resolve it fairly easily. Here's a bit of background. Sorry if you're already familiar with the branch. Validators are functions that are tied to

Re: 1.2 Feature freeze

On Wed, Dec 23, 2009 at 2:34 AM, James Bennett wrote: > Technically, the major feature freeze for Django 1.2 was to have > happened sometime yesterday, US Central time. As of this moment, we're > not actually frozen, but will be as soon as I hear status reports on > the

Re: Final Multi-DB status Update

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 (o

Re: For QuerySet qs, list(qs)[k] does not always equal qs[k]

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

Re: For QuerySet qs, list(qs)[k] does not always equal qs[k]

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

Re: Search for the ORM and Haystack

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

Re: Using form validation to prevent deletion no longer works (after rev 10206/ticket #9587)

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

Re: Using form validation to prevent deletion no longer works (after rev 10206/ticket #9587)

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 >

Re: Changeset 10219 does not fix #9587

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

Re: Changeset 10219 does not fix #9587

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

Re: DDN on #9284

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

DDN on #9284

#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

Re: Recursive inlines in admin?

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,

Re: I want a pony: Django Cheeseshop

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

Re: Altering data uploaded to FileField before save is called

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

Proposal for dynamic form choices

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 =

Re: Shared declarative syntax in both ModelAdmin and ModelForms.

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

Re: more DDN Tickets

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

Re: Django 1.0 roadmap

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

Re: #5731

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

Re: Proposal: Form rendering with filters

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

Re: newforms-admin FormSet API

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

Re: GSoC proposition - djangosearch backend

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

Re: TextIndexingAbstractionLayer and FullHistory branches for GSoC

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

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

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

Re: Class based generic views

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 l

Class based generic views

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

Re: Newforms admin relative image fields

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

Re: ModelForms paranoia simplification?

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

preventing syncdb from loading initial_data

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

Re: newforms-admin and django.contrib.auth

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

Re: newforms-admin and django.contrib.auth

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

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

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]> wr

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

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

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

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'

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

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

Re: Fixing app_label

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

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

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

Re: Fixing app_label

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

Re: newforms-admin change history

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 &

Re: newforms-admin change history

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

newforms-admin includes auto-escaping as of [6776]

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

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

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

Re: ModelForms

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

Re: ModelForms

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

Re: ModelForms

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

Re: ModelForms

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 =

ModelForms

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:

Re: Overriding a Model's save() method does not allow proper creation of ManyToMany related objects

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 >

No custom management commands for django-admin.py?

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

Re: Hook to clear sensitive session data?

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 =

Re: formset_for_model() and the form prefix

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

Proposal: form_for_model exclude_fields

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

Re: Discussion on #5721

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

Re: A couple of newforms-admin questions

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

Re: A couple of newforms-admin questions

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 >

Re: Django 100% threadsafe with DB?

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

Re: newforms-admin still broken?

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

Re: changeset 6391

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,

Re: changeset 6391

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

Setting pk to None before sending post_delete signal

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

Re: copy.deepcopy for newforms' Bug ?

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

Re: Proposal: Change ModelAdmin 'fields' to 'fieldsets'

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 any

Re: ANN: newforms-admin syntax change for inlines

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

Re: ANN: newforms-admin syntax change for inlines

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'

Re: ANN: newforms-admin syntax change for inlines

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

Re: Proposal: Change ModelAdmin 'fields' to 'fieldsets'

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

ANN: newforms-admin syntax change for inlines

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

Proposal: Change ModelAdmin 'fields' to 'fieldsets'

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

Re: Reason why SlugField doesn't subclass CharField?

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

Reason why SlugField doesn't subclass CharField?

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

Re: Let's schedule a Django sprint

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.

Re: I need fix "non proper sql server support" in the next 3 weeks. What is next?

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:

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

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

Re: Inline editing without a parent model

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

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

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

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

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 >

Re: Custom field _post_create_sql()

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

Re: runtest.py slowdowns?

On 5/14/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: > > On 5/15/07, Joseph Kocherhans <[EMAIL PROTECTED]> wrote: > > > > Has anyone noticed a fairly recent order of magnitude slowdown in how > > long it takes to run the django test suite? I used to get

runtest.py slowdowns?

Has anyone noticed a fairly recent order of magnitude slowdown in how long it takes to run the django test suite? I used to get times of about 14 seconds around March (at PyCon) but it's taking ~150 seconds now. It's quite possibly something that's changed in my setup, but I figured I'd see if

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

On 5/13/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > > What's your ETA on these changes? I finally have some free time this > week, and I'd like to work toward getting this branch finalized. If > you don't have time to hack on this, let me know where you left off. I'm still working on the

Re: Two field-related suggestions for newforms.models

On 5/10/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: > > On 5/11/07, Joseph Kocherhans <[EMAIL PROTECTED]> wrote: > > > > On 4/29/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: > > > > > > I realize that you can subclass the form cl

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

On 5/10/07, Joseph Kocherhans <[EMAIL PROTECTED]> wrote: > On 5/5/07, Jari Pennanen <[EMAIL PROTECTED]> wrote: > > > > Modularity of edit inline? Any better? > > > > Currently: > > models.ForeignKey(Other, edit_inline=models.TABULAR, parameters...)

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

On 5/5/07, Jari Pennanen <[EMAIL PROTECTED]> wrote: > > Modularity of edit inline? Any better? > > Currently: > models.ForeignKey(Other, edit_inline=models.TABULAR, parameters...) > obiviously is a big waste of OO abilities, > > instead something like, the OO way: > models.ForeignKey(Other,

Re: Two field-related suggestions for newforms.models

On 4/29/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: > > 1) Is there room for a 'fields' argument on form_for_instance and > form_for_model - a list of field names that you want included on the > form (defaulting to None, meaning the full list), so that it is simple > to create a form with

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

On 4/6/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > > As of [4944], the newforms-admin admin site should be working properly > -- you're right that I hadn't finished the AdminSite stuff. (Sorry for > the miscommunication!) It's working pretty well now. To activate the > admin site, do this: >

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

On 3/25/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > > Now that we have 0.96 out the door, I'd love to wrap up the > newforms-admin branch, which is mostly missing edit-inline support but > works well for other cases. > > Joseph Kocherans was working on edit-inline support, but I haven't >

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

On 3/25/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > > Now that we have 0.96 out the door, I'd love to wrap up the > newforms-admin branch, which is mostly missing edit-inline support but > works well for other cases. > > Joseph Kocherans was working on edit-inline support, but I haven't >

Re: Upcoming changes to the Django admin

On 3/3/07, Ivan Sagalaev <[EMAIL PROTECTED]> wrote: > > Jacob Kaplan-Moss wrote: > > Edit-inline is also going to be moved out into the admin declaration, > > Edit-inline was also useful outside of the admin, in manipulators. Are > there any plans to have newforms handling this or this will

  1   2   3   >