Re: GSoC Proposal: Serialization Enhancements

Questions for the time-pressed: * Have you ever needed, or can you conceive of ever wanting, to provide multiple formats (JSON/XML/etc) for the same data? In other words, is there a use case for easily producing different serializations of the same data? * If you could serialize data in whatever

GSOC proposal: improve F expresions and DateField lookups

Hello everyone, My name is Maxim Veytsman and I am a third year computer science student at the University of Toronto. There was a project idea in the wiki called "Improve Query Expressions (F() syntax." I have a list of syntactical improvements to handling of F expressions especially with Date

Re: GSoC - Generic REST API module for Django

Malcom, I took a look at django-restapi and it seems like a great start. Having been the mentor for the first run at it, what features would you like to see added? If you have a minute, I think that would definitely serve as a great guide. Thanks, Bill Konrad On Mar 31, 9:15 pm, Malcolm Tredi

Re: GSoC 2009: Testing Upgrades/Awesomeness

On 1 Dub, 04:15, Jacob Kaplan-Moss wrote: > On Tue, Mar 31, 2009 at 8:52 PM, Russell Keith-Magee > AFAIK the two choices for doing browser tests are Selenium and > Windmill. Windmill has (as of today) direct Django integration, and > the developers are keen to help us get whatever we need out of

Re: GSoC 2009: Testing Upgrades/Awesomeness

So here is an updated version, more awesome (by my estimation) . Let me know what you think! Upgrade the Awesomness Quotient of the Django Test Utils and Regression Suite = Abstract To fix and test, so cover the

Re: GSoC 2009: Testing Upgrades/Awesomeness

Many thanks on the feedback all. I wanted to let you know I'm working on an updated proposal removing 1) and 4) and replacing them with a collection of convenience assertions/functions for core test stuff. On Tue, Mar 31, 2009 at 8:15 PM, Jacob Kaplan-Moss < jacob.kaplanm...@gmail.com> wrote: > >

Re: GSoC 2009: Testing Upgrades/Awesomeness

On Tue, Mar 31, 2009 at 8:52 PM, Russell Keith-Magee wrote: > I like the sentiment and the goal - my only concern is the extent to > which this is in scope for a Django GSoC project. If making this > integration requires changes on the Django side, you're fine - but if > you need to make changes

Re: GSoC 2009: Testing Upgrades/Awesomeness

On Wed, Apr 1, 2009 at 4:03 AM, Kevin Kubasik wrote: Hi Kevin! > The Problem > *** > > Django has a fantastic set of regression tests which cover much of the > codebase, but the famous Admin interface isn't covered by any sort of > automated tests. Not entirely true - the admin does ha

Re: GSoC - Generic REST API module for Django

On Tue, 2009-03-31 at 17:31 -0700, Bill Konrad wrote: > First off, thanks for taking the time to read through it and give so > much feedback. > > Please let me clarify one thing. If you read the above as a proposal > than it wouldn't have seemed much like a proposal. I was only > outlining what

Re: GSoC - Generic REST API module for Django

For the record, here is a list of somewhat related projects: http://opensource.washingtontimes.com/projects/django-apibuilder/ http://github.com/ingenieroariel/dapi/ http://code.google.com/p/django-restapi/ http://github.com/fiam/wapi/ http://github.com/toastdriven/multiresponse/

Re: GSoC - Generic REST API module for Django

First off, thanks for taking the time to read through it and give so much feedback. Please let me clarify one thing. If you read the above as a proposal than it wouldn't have seemed much like a proposal. I was only outlining what a REST API module (I know you don't like that naming) would need

Re: GSoC - Generic REST API module for Django

On Tue, 2009-03-31 at 15:36 -0700, Bill Konrad wrote: > Ivan, > > Thanks for the quick feedback. What I meant by predictable (and maybe > it's the wrong word in this case) is that when assigning a URI to a > resource, a convention is followed, not that the user can "predict" > the URI itself. I

Re: GSoC - Generic REST API module for Django

On Tue, 2009-03-31 at 14:35 -0700, bkonrad wrote: > I was fortunate enough today to have a quick chat with Jacob Kaplan- > Moss about the concept of a generic REST API module for Django. We > spoke about how this has been attempted before and some of the > remaining issues that still require atte

Re: CSRF template tag patch done

Hi Luke -- I'm sorry it took me so long to review this patch, but I wanted to make sure I knew what I was talking about first. What you've done here is admirable, and I agree that the goal of out-of-the-box CSRF protection is important, but ultimately I can't get behind committing this. It's si

Re: GSoC - Generic REST API module for Django

> > > http://github.com/ingenieroariel/dapi/tree/master is an intersting project > working on the same thing, it's probably a good idea to look at it(and any > other attempts) for reference. > > Alex > Thanks for the pointer Alex, Brian helped me jump start a RESTful API project using the same app

Re: Deletion of related objects

On Tue, 2009-03-31 at 14:48 -0500, Jeremy Dunck wrote: > Malcolm, Jacob pointed me at you, since the code in question was a > commit around QSRF-time. > > I'm aware of ticket #7539, but would prefer to keep the scope narrower > and ask the hopefully-useful question-- is #9308 a bug? If so, I'd >

Re: GSoC - Generic REST API module for Django

On Tue, Mar 31, 2009 at 6:38 PM, Bill Konrad wrote: > > Kaylan, > > Good point. That would have to be a part of the specification 100%. > Any foreign key table entries that are "folded in" would have to check > out with the permissions component. > > On Mar 31, 6:24 pm, Kalyan Lanka wrote: > >

Re: GSoC - Generic REST API module for Django

Kaylan, Good point. That would have to be a part of the specification 100%. Any foreign key table entries that are "folded in" would have to check out with the permissions component. On Mar 31, 6:24 pm, Kalyan Lanka wrote: > I am not a Django developer but have been closely following this grou

Re: GSoC - Generic REST API module for Django

Ivan, Thanks for the quick feedback. What I meant by predictable (and maybe it's the wrong word in this case) is that when assigning a URI to a resource, a convention is followed, not that the user can "predict" the URI itself. On Mar 31, 6:18 pm, Ivan Sagalaev wrote: > bkonrad wrote: > > 1. P

Re: GSoC - Generic REST API module for Django

I am not a Django developer but have been closely following this group as I have been in love with Django framework since I started using it. You guys have done a great job. > > > 6. Proper Links / Foreign Key Resources > > If the request for primary key starts our sending out "foldable" for

Re: GSoC - Generic REST API module for Django

bkonrad wrote: > 1.Predictable URI Naming Apart from my serious doubt that this can be done at all I'd like to point out that the very notion of *predicting* URLs is not RESTful. URLs are generated by server (by whatever logic it chooses) and client treats them as opaque identifiers. The m

GSoC - Generic REST API module for Django

I was fortunate enough today to have a quick chat with Jacob Kaplan- Moss about the concept of a generic REST API module for Django. We spoke about how this has been attempted before and some of the remaining issues that still require attention. After our chat, I compiled a problem statement tha

GSoC 2009: Testing Upgrades/Awesomeness

So I'm here at PyCon and we keep getting more and more cool testing ideas, I want them in Django, so I have teh following proposal, lemme know what you think. I would love feedback of all flavors, both on the application itself and what its proposing. It's below in restructuredText: Upgrade the

Re: Deletion of related objects

On Mar 31, 2009, at 12:48 PM, Jeremy Dunck wrote: > > Malcolm, Jacob pointed me at you, since the code in question was a > commit around QSRF-time. > > I'm aware of ticket #7539, but would prefer to keep the scope narrower > and ask the hopefully-useful question-- is #9308 a bug? If so, I'd > l

Re: django <--> wsgi

On Tue, Mar 31, 2009 at 1:12 PM, Waylan Limberg wrote: > > On Tue, Mar 31, 2009 at 2:21 PM, Travis Parker > wrote: > > > [snip] > > > > 2. settings (views -> apps, dj middleware -> wsgi middleware) > > i don't have nearly as nice a proposal for dealing with this. there > > are a lot of django vi

Re: Changeset 10219 does not fix #9587

It seems to be ok! Thanks On Mar 31, 4:59 pm, Joseph Kocherhans wrote: > 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 wrote: > > > On Tue, Mar 31, 2009 at 12:32 PM, Vinicius Mendes > >wrote: > >

Re: django <--> wsgi

On Tue, Mar 31, 2009 at 2:21 PM, Travis Parker wrote: > [snip] > > 2. settings (views -> apps, dj middleware -> wsgi middleware) > i don't have nearly as nice a proposal for dealing with this. there > are a lot of django views and middleware out there that would be nice > to have usable as wsgi c

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 wrote: > > On Tue, Mar 31, 2009 at 12:32 PM, Vinicius Mendes >wrote: > > > > > What do you think about reopening the ticket? > > > > You're right. The changeset

Deletion of related objects

Malcolm, Jacob pointed me at you, since the code in question was a commit around QSRF-time. I'm aware of ticket #7539, but would prefer to keep the scope narrower and ask the hopefully-useful question-- is #9308 a bug? If so, I'd like to close it for 1.1. In summary, #9308 describes a situation

Re: django <--> wsgi

On Tue, Mar 31, 2009 at 3:22 PM, Travis Parker wrote: > > On Mar 31, 12:04 pm, Alex Gaynor wrote: > > On Tue, Mar 31, 2009 at 2:21 PM, Travis Parker >wrote: > > > > > > > > > > > > > hello django devs, > > > > > It was nice to meet a few of you at pycon. I talked briefly with jacob > > > about a

Re: django <--> wsgi

On Mar 31, 12:04 pm, Alex Gaynor wrote: > On Tue, Mar 31, 2009 at 2:21 PM, Travis Parker wrote: > > > > > > > hello django devs, > > > It was nice to meet a few of you at pycon. I talked briefly with jacob > > about a plan to improve django's ability to play nice with the wsgi > > community with

Re: Changeset 10219 does not fix #9587

On Tue, Mar 31, 2009 at 2:57 PM, Vinicius Mendes | meiocodigo.com < vbmen...@gmail.com> wrote: > > Joseph, > > I think the problem is still the same of the reported in the ticket, > since the reporter talks about inlineformset_factory, so he is using > InlineFormsets. > > Did you see the patch I p

Re: django <--> wsgi

On Tue, Mar 31, 2009 at 2:21 PM, Travis Parker wrote: > > hello django devs, > > It was nice to meet a few of you at pycon. I talked briefly with jacob > about a plan to improve django's ability to play nice with the wsgi > community with 2-way conversions between django views and wsgi apps, > and

Re: Changeset 10219 does not fix #9587

Joseph, I think the problem is still the same of the reported in the ticket, since the reporter talks about inlineformset_factory, so he is using InlineFormsets. Did you see the patch I put in dpaste? http://dpaste.com/21753/ It's basically the same idea used in the changeset. On Mar 31, 3:35 p

django <--> wsgi

hello django devs, It was nice to meet a few of you at pycon. I talked briefly with jacob about a plan to improve django's ability to play nice with the wsgi community with 2-way conversions between django views and wsgi apps, and between django middleware and wsgi middleware. I have started loo

Re: Changeset 10219 does not fix #9587

Here is the problem demonstration: http://dpaste.com/21801/ On Mar 31, 3:06 pm, Alex Gaynor wrote: > On Tue, Mar 31, 2009 at 1:55 PM, Vinicius Mendes | meiocodigo.com < > > > > vbmen...@gmail.com> wrote: > > > Look at this link: > > >http://code.djangoproject.com/browser/django/trunk/django/for

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 save_existing_object

Re: Changeset 10219 does not fix #9587

On Tue, Mar 31, 2009 at 1:55 PM, Vinicius Mendes | meiocodigo.com < vbmen...@gmail.com> wrote: > > Look at this link: > > http://code.djangoproject.com/browser/django/trunk/django/forms/formsets.py > > I think your revision isn't the HEAD of trunk. The comment you said is > in lines 227-229. But t

Re: Changeset 10219 does not fix #9587

Look at this link: http://code.djangoproject.com/browser/django/trunk/django/forms/formsets.py I think your revision isn't the HEAD of trunk. The comment you said is in lines 227-229. But the point here isn't create a cleaned_data for the form. I know it will not exist. The problem is that this

Re: Changeset 10219 does not fix #9587

On Tue, Mar 31, 2009 at 1:39 PM, Vinicius Mendes | meiocodigo.com < vbmen...@gmail.com> wrote: > > I didn't understand. Line 216 is the docstring: > > """ > Returns True if form.errors is empty for every form in self.forms. > """ > > I don't want to create the cleaned data. I just adopted the same

Re: Changeset 10219 does not fix #9587

I didn't understand. Line 216 is the docstring: """ Returns True if form.errors is empty for every form in self.forms. """ I don't want to create the cleaned data. I just adopted the same logic used in the patch to solve the problem. If the form doesn't have a cleaned_data attr, so I get it from

Re: Changeset 10219 does not fix #9587

On Tue, Mar 31, 2009 at 1: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_object

Changeset 10219 does not fix #9587

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

Re: Call for ideas: Admin Improvements

On Tue, Mar 31, 2009 at 9:43 AM, Russell Keith-Magee wrote: > I'm in full agreement that "Improving the admin UI" is certainly a > good pre-proposal, and I'm sure there's plenty of tickets that could > fill a SoC. My concern is that "move to using jQuery" isn't a good > line item in a proposal wi

Re: Call for ideas: Admin Improvements

On Tue, Mar 31, 2009 at 9:44 PM, mrts wrote: > > Sorry if I sounded intrusive, what I meant was that prototyping with > jQuery (or whatever other JS framework) may at the very least provide > a quick way prove that a particular idea works (instead of a time- > consuming plain-JS implementation).

Re: Call for ideas: Admin Improvements

On Tue, Mar 31, 2009 at 9:39 PM, Jacob Kaplan-Moss wrote: > > On Tue, Mar 31, 2009 at 8:30 AM, Russell Keith-Magee > wrote: >> It would be _exceedingly_ unwise to advise any student to base a GSoC >> proposal on the use of JQuery (or any other framework, for that >> matter). > > I think that soo

Re: Call for ideas: Admin Improvements

Sorry if I sounded intrusive, what I meant was that prototyping with jQuery (or whatever other JS framework) may at the very least provide a quick way prove that a particular idea works (instead of a time- consuming plain-JS implementation). But it is of course for the BDFLs to decide if that is a

Re: Call for ideas: Admin Improvements

On Tue, Mar 31, 2009 at 8:30 AM, Russell Keith-Magee wrote: > It would be _exceedingly_ unwise to advise any student to base a GSoC > proposal on the use of JQuery (or any other framework, for that > matter). D'oh. The reason that Zain is including use of jQuery in this proposal is because I, e

Re: Call for ideas: Admin Improvements

On Tue, Mar 31, 2009 at 9:02 PM, mrts wrote: > > On Mar 31, 2:41 pm, Russell Keith-Magee > wrote: >> Correct. Django has very deliberately made a decision to avoid >> blessing any single Javascript toolkit. It is unlikely that this will >> change simply because a GSoC applicant has proposed it.

Re: Call for ideas: Admin Improvements

On Mar 31, 2:41 pm, Russell Keith-Magee wrote: > Correct. Django has very deliberately made a decision to avoid > blessing any single Javascript toolkit. It is unlikely that this will > change simply because a GSoC applicant has proposed it. Proposals that > hinge on the use of JQuery (or any oth

Re: GSoC Proposal: Serialization Enhancements

On Tue, Mar 31, 2009 at 11:43 AM, Russ Amos wrote: > I appreciate you taking the time to identify my now-glaring misconceptions, > Russ (... I have to laugh.  I've never met another Russ). Soon we will take over the world. :-) > Would writing an appropriate template, while certainly not ideal,

Re: Call for ideas: Admin Improvements

On Tue, Mar 31, 2009 at 7:28 PM, Julien Phalip wrote: > > On Mar 31, 6:53 pm, zain wrote: >> I'm applying for the GSoC with some thoughts to generally improve the >> admin interface. So far, I have the following ideas: >> >> 1) An autocomplete widget >> 2) Drag & Drop support for ordered relatio

Re: Call for ideas: Admin Improvements

On Mar 31, 6:53 pm, zain wrote: > I'm applying for the GSoC with some thoughts to generally improve the > admin interface. So far, I have the following ideas: > > 1) An autocomplete widget > 2) Drag & Drop support for ordered relations > 3) Foreign Key traversal to see and modify models reference

Re: Call for ideas: Admin Improvements

I think inplace edit functionality could be very useful. You can take a look to this Django application: https://tracpub.yaco.es/djangoapps/browser/inplaceeditform/trunk/inplaceeditform For any model like that: class Book(models.Model): title = models.CharField(max_length=200) body = mod

Re: Call for ideas: Admin Improvements

- Photo Management - crop, rotate (with ability to add more filters) - Make it easier for people to create custom themes and styles for the admin and change between them - Allow models to be added twice with two modeladmins serving a different process --- Dougal Matthews - @d0ugal

Re: Call for ideas: Admin Improvements

Add and remove instances to/from formsets with a button click is much needed instead of the current delete checkbox and `extra` handling (both for formsets in general and for admin formsets in particular). There is a snippet (that I've not tried) at http://www.djangosnippets.org/snippets/1389/ .

Re: Call for ideas: Admin Improvements

- Dynamic Managers - Select which field you want to filter by and boom. No hard code - Finer Permissions (not exactly an interface suggestion) - Limit the ability of a user right down to the created object - You have many accounts and you can assign an agent permissions to

Call for ideas: Admin Improvements

I'm applying for the GSoC with some thoughts to generally improve the admin interface. So far, I have the following ideas: 1) An autocomplete widget 2) Drag & Drop support for ordered relations 3) Foreign Key traversal to see and modify models referenced to by ForeignKeys inline 4) Refactor the a