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

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

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 >

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

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

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/

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.

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

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

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,

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

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

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"

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

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

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 >

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

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

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

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

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

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

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 

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

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

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

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

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

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 >

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

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

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

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

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

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

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)

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 =

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