GSOC proposal: improve F expresions and DateField lookups

[Max Veytsman]

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 DateTimeFields, and I'm hoping on some feedback before
I submit my application.

Since I'm talking about syntactical improvements I think it's best to
have a demonstrative example for each one.  Suppose I have the
following models:

class Item(models.Model):
  subject = models.CharField(max_length=200)
  text = models.TextField()
  datetime_posted = models.DateTimeField(auto_now_add=True)

class Author:
  name = models.CharField(max_length=40)
  birthday = models.DateField()


Improvements to Handling of Dates
==

1) Syntax for comparisons using fields derived from DateField

For instance to select all of the items that were written before the
10th of the month I would do

Item.objects.filter(datetime_posted__day__lt=10)

2) Allow F expressions to access fields derived from DateField.

I.E. for all Items written by an author during his/her birthmonth:
Item.objects.filter(datetime_posted__month=F
('author__birthdate__month')

3) Add the __date lookup to DateTimeFields
I.E. for all Items written on the author's birthday
Item.objects.filter(date_poststed__date=F(author__birthday))

This is to compare a DateTimeField with a DateField
This is covered by the following ticket:
http://code.djangoproject.com/ticket/9596http://code.djangoproject.com/ticket/9596
which provides a patch, although it may not work for all backends.  I
will make sure it does, and provide more rigorous testing.

4) Allow for annotation by fields derived from F expressions
This will probably be the meat of the project.

I.E. to group Items by date:
Item.objects.annotate(date=F('datetime__date')).values('date').values
(num_items=Count('id'))

This is covered in ticket #10302(http://code.djangoproject.com/ticket/
10302)

Allowing F expressions to be used in annotate will allow a lot of
power in queries, not just related to date manipulation.

5) This already has a patch but I think I should mention it.  Ticket
10514(http://code.djangoproject.com/ticket/10154) allows for
timedeltas to be added or subtracted from F expressions.

I.E.
For all Items posted within 5 days after the author's birthday
Item.objects.filter(datetime_posted__date__gte=F
('author__birthday'),datetime_posted__date__lte=F('author__birthday')
+datetime.timedelta(days=5))

If anyone has any comments about how the solution there can be
improved, please let me know as this fits into what I am doing.

Improvements to Handling of Strings
===

I also want to allow for string F expressions.
I'm going to stop using the example for these as they are simpler.

If the field foo contains a string
1) F('foo')+"bar" should concatenate the two strings

2) F('foo')*N should repeat N times

3) I would like some feedback on this one: would allowing for splicing
be a good idea?

I can see how an expression like __startswith=F('foo')[0:3] could be
useful to have.  Is implementing this a good idea?

That's pretty much what I want to do over the summer. I hope that in
sum this is substantial enough for a GSOC project.  I would also love
for any other recommendations, and for ways to improve the timedelta
functionality.

Thank you for your time,
Maxim Veytsman

--~--~-~--~~~---~--~~
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: GSoC - Generic REST API module for Django

[Bill Konrad]

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 Tredinnick 
wrote:
> 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 a REST API module (I know you don't like that naming)
> > would need to provide.  The proposal goes much further and contains
> > more detail.
>
> Well, you said you had created a problem statement and I assumed that
> mail was it. Apparently not. It's a bit confusing as this whole proposal
> to do something for Summer of Code hinges on there actually being a
> problem to solve and a solution that solves it, not the fact that REST
> exists.
>
> > The reason that I refer to it as a module and think there is more to
> > this than just an architectural style is that by providing an API
> > "service" that models can be registered with (think django-rest-
> > interface from 2007) a lot of the details can be ignored by someone
> > who is not interested in writing a full API from scratch.
>
> Then please stop calling it a generic REST API. Because it's not. It's
> an interface to expose models. A generic REST API requires the full
> power of Python because, as I've already noted, it's an orthogonal
> concept to what is stored persistently. We provide a way to retrieve
> arbitrary data -- view functions and the ORM. You can't hope to make it
> any simpler than that for the general case.
>
> >   The
> > objective would be to let the developer define which data can be
> > accessed through the API, who can access it and have most of the
> > internal details handled for him.
>
> So is this another pass at the 2007 project again? Why not contribute to
> django-restapi instead and keep that going along? I know why that
> project got as far as it did and what the limitations and strengths of
> it are (since I was the mentor for that student). For a
> model-presentation API, it's going in the right direction and people are
> using it.
>
> The devil is in the details here and the worthiness of a proposal along
> these lines very much on what you are thinking requires changes in
> Django's core. I think the answer to that is "very little". Which then
> leads me to wonder about what you're proposing to do.
>
> [...]
>
> > Does that help clarify what I wrote a bit?
>
> Not really, because I still don't know what you're proposing to do and
> the specifics are important for a Summer of Code project.
>
> Regards,
> Malcolm
--~--~-~--~~~---~--~~
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: GSoC 2009: Testing Upgrades/Awesomeness

[Jacob Kaplan-Moss]

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 on the Nose/Windmill side, then you have a
> problem, as we don't have any control over those projects. Also - I
> was under the impression that both Nose and Windmill already had
> Django interfaces of some description. I could be mistaken - I haven't
> really used either of them extensively myself.

I'm not sure about Nose either, but Windmill has Django support, and
actually grew a management comment as part of the PyCon sprints.
You'll add 'windmill' to INSTALLED_APPS, and then run `manage.py
test_windmill` (or similar); see
http://trac.getwindmill.com/changeset/1172.

So we don't have to make a single change to Django to make that
support work, which makes me very happy :)

> Requiring Windmill here makes me a little nervous. I have no
> experience with Windmill to know if it is a good choice for this task.

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
Windmill. Selenium doesn't, and I don't know what the developer's
priorities are. I don't see that it's that hard a choice given the
alternatives.

> I don't want to just add Windmill tests because we can - we need to be
> adding tests that actually add value for regression purposes. It's
> very easy to write functional tests that don't actually validate
> functionality - they just make it difficult to modify code.

We *really* need coverage of the admin UI. Working on the admin
actions, I've twice checked in JavaScript that doesn't work on IE. We
wouldn't tolerate committing code broken on MySQL; why do we tolerate
code broken on IE? I see adding functional UI tests as a necessity if
we want to keep adding new admin features.

> We also need to ensure that the test suite continues to run for those
> that haven't got Windmill installed (albeit with a warning).

Indeed. Anything else is broken.

> There is
> an old ticket that proposed to allow skipping tests that are known
> failures, reporting them as 'known failures/skipped tests' rather than
> outright failures. This might be something worth including in your
> proposal.

Yeah, it's http://code.djangoproject.com/ticket/4788; that'd make an
obvious addition to the project. Kevin, you should take a look at the
skip-test feature added to Python (trunk) recently; might be worth
ripping off... err... adapting for our purposes.

> django-test-utils is a great set of tools, but working on those tools
> is (IMHO) out of scope for the SoC, since it isn't part of the Django
> project itself.

Agreed. Find Django core stuff to work on, not third-party projects.

> I was under the impression that GSoC was intended to be a full-time
> activity - however, I couldn't find any reference to this in the FAQ.
> You may want to confirm that a 'part time' application is allowed.

Google doesn't specify
(http://socghop.appspot.com/document/show/program/google/gsoc2009/faqs#student_time);some
projects require full-time status, but I'm OK with not as long as the
student's up front about how much time he'll be able to spend. Given
that none of *us* work full-time on Django I don't see that we should
absolutely require our students to do so.

Jacob

--~--~-~--~~~---~--~~
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: GSoC 2009: Testing Upgrades/Awesomeness

[Russell Keith-Magee]

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 have _some_ tests, in the
regression tests module. However, I agree that these tests could be
substantially improved.

> In addition, the tools for testing a site under the
> Django framework are weak, even if the API's available are quite
> powerful.

Again - depends what you mean by 'testing a site' - if you mean
functional testing at the UI level, then I will concur wholeheartedly.

> Proposal
> 
>
> Overall Django has some great testing tools, but the addition of a few
> key integrations and tools could make it a much more comprehensive and
> easy to use testsuite. Namely, nose runners and extensions, Windmill
> integration, and some expansions to Eric's django-test-utils package.
> Namely, I want to accomplish the following:
>
>   1. Work with Windmill and Nose to make sure running django tests
> with Nose and running Windmill tests through django is easy and
> painless. This will mostly involve work on the external projects, and
> probably won't touch Django proper. But in coordinating with these
> projects, I also hope to provide any missing or needed extension
> points in Django to make this integration possible.

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 on the Nose/Windmill side, then you have a
problem, as we don't have any control over those projects. Also - I
was under the impression that both Nose and Windmill already had
Django interfaces of some description. I could be mistaken - I haven't
really used either of them extensively myself.

>   2. Expand the Django test runner to provide Code Coverage
> statistics. There are already some efforts towards this goal underway,
> and I don't plan on reinventing the wheel. My hope is to integrate
> their work, and potentially expand it based on Django's community
> requests. Most likely the base of this work will be figleaf, but I
> plan on researching other options. Lastly, I want to evaluate the
> coverage of Django's current regression suite and provide a wiki page/
> writeup detailing any major deficiencies so that they can be
> addressed.

+1. There are a few coverage options out there, and there is already
an accepted ticket for this feature.

>   3. Utilize the new Windmill test support to provide coverage of the
> Admin interface. This is an extremely large task overall, but given
> how easy Windmill has made the creation of tests, I hope that I will
> be able to provide coverage of a majority of the admin's
> functionality. This will not include support for the
> django.contrib.gis namespace, but I will try and test all other
> namespaces that have Admin integration or functionality (namely auth,
> admin and comments).

Requiring Windmill here makes me a little nervous. I have no
experience with Windmill to know if it is a good choice for this task.
I don't want to just add Windmill tests because we can - we need to be
adding tests that actually add value for regression purposes. It's
very easy to write functional tests that don't actually validate
functionality - they just make it difficult to modify code.

We also need to ensure that the test suite continues to run for those
that haven't got Windmill installed (albeit with a warning). There is
an old ticket that proposed to allow skipping tests that are known
failures, reporting them as 'known failures/skipped tests' rather than
outright failures. This might be something worth including in your
proposal.

>   4. The last major component of this project will be the extension
> and expansion of the django-test-utils package to add the following
> components:
>         1. Update the TestGen Middleware to serialize all testing
> data (probably just via cPickle initially) to disk.
>         2. Implement a pluggable 'Processor' framework to generate
> the runnable tests from the serialized request data.(Aka twill/django
> unittest/unittest)
>         3. A basic web interface to start/stop the TestingMiddleware
> and display its status/results.
>         4. Utilizing the new Plugin framework allow for test-time
> analysis such as unused Context variables and dead links.
>                 5. Integrate something like Werkzeug_ on test fails from web
> interface runner.

django-test-utils is a great set of tools, but working on those tools
is (IMHO) out of scope for the SoC, since it isn't part of the Django
project itself.

If you're looking for something to pad out your proposal, there are
plenty of testing tickets on the Django Trac that have been accepted,
and would be fantastic 

Re: GSoC - Generic REST API module for Django

[Malcolm Tredinnick]

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 a REST API module (I know you don't like that naming)
> would need to provide.  The proposal goes much further and contains
> more detail.

Well, you said you had created a problem statement and I assumed that
mail was it. Apparently not. It's a bit confusing as this whole proposal
to do something for Summer of Code hinges on there actually being a
problem to solve and a solution that solves it, not the fact that REST
exists.

> The reason that I refer to it as a module and think there is more to
> this than just an architectural style is that by providing an API
> "service" that models can be registered with (think django-rest-
> interface from 2007) a lot of the details can be ignored by someone
> who is not interested in writing a full API from scratch.

Then please stop calling it a generic REST API. Because it's not. It's
an interface to expose models. A generic REST API requires the full
power of Python because, as I've already noted, it's an orthogonal
concept to what is stored persistently. We provide a way to retrieve
arbitrary data -- view functions and the ORM. You can't hope to make it
any simpler than that for the general case.

>   The
> objective would be to let the developer define which data can be
> accessed through the API, who can access it and have most of the
> internal details handled for him.

So is this another pass at the 2007 project again? Why not contribute to
django-restapi instead and keep that going along? I know why that
project got as far as it did and what the limitations and strengths of
it are (since I was the mentor for that student). For a
model-presentation API, it's going in the right direction and people are
using it.

The devil is in the details here and the worthiness of a proposal along
these lines very much on what you are thinking requires changes in
Django's core. I think the answer to that is "very little". Which then
leads me to wonder about what you're proposing to do.

[...]
> Does that help clarify what I wrote a bit?

Not really, because I still don't know what you're proposing to do and
the specifics are important for a Summer of Code project.

Regards,
Malcolm



--~--~-~--~~~---~--~~
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: GSoC - Generic REST API module for Django

[Ariel Mauricio Nunez Gomez]

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/

Ariel

--~--~-~--~~~---~--~~
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: GSoC - Generic REST API module for Django

[Bill Konrad]

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 to provide.  The proposal goes much further and contains
more detail.

The reason that I refer to it as a module and think there is more to
this than just an architectural style is that by providing an API
"service" that models can be registered with (think django-rest-
interface from 2007) a lot of the details can be ignored by someone
who is not interested in writing a full API from scratch.  The
objective would be to let the developer define which data can be
accessed through the API, who can access it and have most of the
internal details handled for him.

For the record I 100% agree with you that a REST API can be written in
Django by hand, from scratch and be perfectly adherent to REST
principles.  At the same time, however, I see room for a utility like
this.  I think that the result would be a higher % of Django
applications exposing public facing APIs and creating an environment
of greater interoperability between applications.

Does that help clarify what I wrote a bit?

On Mar 31, 7:08 pm, Malcolm Tredinnick 
wrote:
> 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 attention.  After our chat, I
> > compiled a problem statement that I believe roughly accommodates the
> > needs of the Django community.  My objective here is to hone these
> > points and then create a solution proposal for review by the core
> > committers.  Feedback greatly appreciated.
>
> > Problem Statement
>
> > Django needs a generic REST API module.
>
> I actually question that very premise. Django needs to support generic
> REST precisely by *not* trying to wrap it up as a "module". And I say
> that as somebody who write REST-based applications almost all the time,
> because it's simply a nice maintainable architecture style.
>
> [...]
>
>
>
> > 1. Predictable URI Naming
>
> > A logical, clean URI structure is at the core of any REST API.
> > Individual items and collections should have standard naming schemes
> > across all resources.  Additionally, URIs should be static to the
> > greatest extent possible.
>
> However, URI's vary infinitely across the complete set of all
> applications. They need to be consistent within an application, but what
> you do for a particular application is domain specific.
>
> What's the existing problem in Django here? Clean, predictable URI's are
> already possible. Lots of people already use them.
>
>
>
> > 2. Graceful Handling of Complex Resources
>
> > Jacob’s example is a GET method to “/heros/superman”.  Such a resource
> > needs to return a complete set of data on Superman, and this means
> > being able to aggregate data from multiple resources.
>
> Again, already possible with views. What isn't possible here?
>
>
>
> > 3. Generic / Pluggable Authentication
>
> > Resource data can be sensitive in nature and needs to be distributed
> > only to those that have a right to receive it.  This permissions
> > system should be generic in the sense that a resource does not
> > personally allow / deny access, but instead delegates permission
> > requests to a generic permissions handler.
>
> which permission system is used is up to the application. Django already
> has the contrib.auth module, which can be used even without cookies
> (although it requires some different middleware). There's a small gap
> here in providing documentation and probably some HTTP authentication
> header handling middleware.
>
>
>
> > 4. Flexible Serialization
>
> > Django API consumers will have disparate data format needs, and these
> > need to be addressed.  Formats such as XML, YAML, JSON need to be
> > considered during implementation.
>
> So we already have serialisers that handle all of those for querysets.
> If you're serialising other things, there are a number of approaches
> discussed in the various threads here already about GSOC for
> serialisation. Subclassing the existing serialisers isn't particularly
> difficult. "Solving" serialisation in general, whatever that means, is a
> project all on its own (as witnessed by the broad scopes of the
> proposals already discussed herre).
>
>
>
> > 5. Clean Request Handling / Mapping
>
> > Jacob notes that browser limitations make one-to-one mapping of HTTP
> > methods (GET/POST/PUT/DELETE) to CRUD operations only a piece of the
> > puzzle.  Flexibility is need here to accommodate various consumer
> > classes.
>
> That's not too hard to do already. Again, you're describing a bullet
> point here, 

Re: GSoC - Generic REST API module for Django

[Malcolm Tredinnick]

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.

It's entirely up to the developer as to which pattern to follow. It's
not something the software can help with (although it's already
encouraged, since we use reg-exps to parse the URIs).

For example, there are very valid use-cases, when including a locale
specifier in a URL for putting it either at the front or the end of the
URL (e.g. /de/foo/blah vs /foo/blah/de). Both are valid and good
practice in different cases. Even within the same website, both styles
might be appropriate (it's not going to be common, but I can think of
some cases). There's no way for a set of libraries like Django to
provide more than a way to parse out useful bits of URLs for situations
like that (and locale parsing, particularly in the leading-component
case, is one of the use-cases for some of the URL resolver modifications
we'll eventually need).

Regards,
Malcolm



--~--~-~--~~~---~--~~
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: GSoC - Generic REST API module for Django

[Malcolm Tredinnick]

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 attention.  After our chat, I
> compiled a problem statement that I believe roughly accommodates the
> needs of the Django community.  My objective here is to hone these
> points and then create a solution proposal for review by the core
> committers.  Feedback greatly appreciated.
> 
> Problem Statement
> 
> Django needs a generic REST API module. 

I actually question that very premise. Django needs to support generic
REST precisely by *not* trying to wrap it up as a "module". And I say
that as somebody who write REST-based applications almost all the time,
because it's simply a nice maintainable architecture style.

[...]

> 
> 1.Predictable URI Naming
> 
> A logical, clean URI structure is at the core of any REST API.
> Individual items and collections should have standard naming schemes
> across all resources.  Additionally, URIs should be static to the
> greatest extent possible.

However, URI's vary infinitely across the complete set of all
applications. They need to be consistent within an application, but what
you do for a particular application is domain specific.

What's the existing problem in Django here? Clean, predictable URI's are
already possible. Lots of people already use them.

> 
> 2.Graceful Handling of Complex Resources
> 
> Jacob’s example is a GET method to “/heros/superman”.  Such a resource
> needs to return a complete set of data on Superman, and this means
> being able to aggregate data from multiple resources.

Again, already possible with views. What isn't possible here?

> 
> 3.Generic / Pluggable Authentication
> 
> Resource data can be sensitive in nature and needs to be distributed
> only to those that have a right to receive it.  This permissions
> system should be generic in the sense that a resource does not
> personally allow / deny access, but instead delegates permission
> requests to a generic permissions handler.

which permission system is used is up to the application. Django already
has the contrib.auth module, which can be used even without cookies
(although it requires some different middleware). There's a small gap
here in providing documentation and probably some HTTP authentication
header handling middleware.

> 
> 4.Flexible Serialization
> 
> Django API consumers will have disparate data format needs, and these
> need to be addressed.  Formats such as XML, YAML, JSON need to be
> considered during implementation.

So we already have serialisers that handle all of those for querysets.
If you're serialising other things, there are a number of approaches
discussed in the various threads here already about GSOC for
serialisation. Subclassing the existing serialisers isn't particularly
difficult. "Solving" serialisation in general, whatever that means, is a
project all on its own (as witnessed by the broad scopes of the
proposals already discussed herre).

> 
> 5.Clean Request Handling / Mapping
> 
> Jacob notes that browser limitations make one-to-one mapping of HTTP
> methods (GET/POST/PUT/DELETE) to CRUD operations only a piece of the
> puzzle.  Flexibility is need here to accommodate various consumer
> classes.

That's not too hard to do already. Again, you're describing a bullet
point here, rather than identifying some particular problem in Django or
proposing a solution (which is a consistent problem throughout this
document), so I'm not quite sure where you're coming from.

I have done a fair bit of thinking in this area, trying to work out the
*minimum* changes to Django to allow as much flexibility as possible.
Particularly based on ideas such as JAX-RS (JSR-311 -- the Java REST API
framework) and similar things. I think most of these problems --
dispatching to different handlers for different methods can be solved
fairly easily with two small modifications to how URL resolvers (and
reversers) are picked up and a couple of decorators. If nothing else
happens in the interim, that's something I'll do early in the 1.2
timeframe, as I ran out of time for 1.1.

> 
> 6.Proper Links / Foreign Key Resources
> 
> All resources which contain foreign key fields should be serialized to
> contain links to said resources in the form of a URI.  One potential
> expansion on this concept is adding “deep” or “full” serialization
> support, whereby a consumer can request that foreign key references be
> “folded” in to the core object.  This is open for debate.

Indeed it is. General REST design (and, remember, you're claiming to be
discussing a generic REST API, not something that provides a way to
display models) completely separates the API from the persistent
storage. They are orthogonal areas. *Sometimes* there will be a nice
mapping, but that's not 

Re: CSRF template tag patch done

[Jacob Kaplan-Moss]

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 simply far too draconian: if I forget to do all steps needed to
upgrade, all my contrib apps stop working. And then as soon as I *do*
those steps, all *my* apps that use POST stop working. I just can't
see that causing anything other than a huge amount of pain for all but
the most savvy users. Updating every view that handle a POST is a
*lot* of work for even small apps.

An even bigger problem would be for users of third-party reusable
apps: my personal blog is a mere 645 lines of code, but there's over
10,000 lines of third-party apps I'm building on top of. If I want to
upgrade to 1.1 and keep using the admin, I need to wait for all of
those apps to be upgraded to use CSRF protection.

Now think about an app built on top of Pinax, which itself builds on
other reusable apps...

Ultimately I think we just can't do this, *especially* this late in the game.

Unless I'm completely wrong here -- always a possibility! -- I'm going
to reject this for 1.1, and possibly entirely if it can't be made
easier.

Again, I'm sorry I waited so long to look closely into this; the
lateness is entirely my fault, and so not having this feature in 1.1
(in some form) is also entirely my bad as well.

Jacob

--~--~-~--~~~---~--~~
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: Deletion of related objects

[Malcolm Tredinnick]

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
> like to close it for 1.1.
> 
> In summary, #9308 describes a situation where B has a nullable FK to
> A, and an instance of A is being deleted.   Currently, any B's related
> to A also get deleted.

I was mostly trying to retain whatever the previous behaviour was with
delete in qsrf. I disagree with Django's cascading delete behaviour, but
wasn't interested in changing it at the time, since I was mostly
bug-fixing, no apple-cart-upsetting.

In the case of #9308, specifically, I think setting the related pointers
to NULL would be a better solution, but I'm not sure if it's considered
a fundamental change in behaviour, inconsistent with what we're doing
now.

Regards,
Malcolm



--~--~-~--~~~---~--~~
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: GSoC - Generic REST API module for Django

[Alex Gaynor]

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:
> > 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" foreign
> key
> > related objects, it can cause some security issues for the application.
>  For
> > example I would like to send about a person information but not all their
> > addresses.  I think it would be good if the spec. provides hooks so that
> the
> > developer can customize based on the role of the consumer on how deep the
> > response can go.
> >
>
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

-- 
"I disapprove of what you say, but I will defend to the death your right to
say it." --Voltaire
"The people's good is the highest law."--Cicero

--~--~-~--~~~---~--~~
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: GSoC - Generic REST API module for Django

[Bill Konrad]

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 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" foreign key
> related objects, it can cause some security issues for the application.  For
> example I would like to send about a person information but not all their
> addresses.  I think it would be good if the spec. provides hooks so that the
> developer can customize based on the role of the consumer on how deep the
> response can go.
--~--~-~--~~~---~--~~
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: GSoC - Generic REST API module for Django

[Bill Konrad]

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. 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 more you document or specify rules for
> constructing URLs for clients the less RESTful your service is.
--~--~-~--~~~---~--~~
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: GSoC - Generic REST API module for Django

[Kalyan Lanka]

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" foreign key
related objects, it can cause some security issues for the application.  For
example I would like to send about a person information but not all their
addresses.  I think it would be good if the spec. provides hooks so that the
developer can customize based on the role of the consumer on how deep the
response can go.

--~--~-~--~~~---~--~~
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: GSoC - Generic REST API module for Django

[Ivan Sagalaev]

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 more you document or specify rules for 
constructing URLs for clients the less RESTful your service is.

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

GSoC - Generic REST API module for Django

[bkonrad]

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 that I believe roughly accommodates the
needs of the Django community.  My objective here is to hone these
points and then create a solution proposal for review by the core
committers.  Feedback greatly appreciated.

Problem Statement

Django needs a generic REST API module.  This fact has been recognized
for some time by the community, and efforts have been made to build a
viable solution.  To date, however, no module has shipped with a
Django release.  Using Jacob Kaplan-Moss’s document “REST Worst
Practices” as well as industry resources such as Joe Gregorio
(Google), RESTful Web Services by Richardson and Ruby, and the
original paper on REST by Roy Fielding as guides, a list of Django
REST features has been compiled.  By addressing each requirement in
the context of existing work, a specification for a functional
solution can be generated.

1.  Predictable URI Naming

A logical, clean URI structure is at the core of any REST API.
Individual items and collections should have standard naming schemes
across all resources.  Additionally, URIs should be static to the
greatest extent possible.

2.  Graceful Handling of Complex Resources

Jacob’s example is a GET method to “/heros/superman”.  Such a resource
needs to return a complete set of data on Superman, and this means
being able to aggregate data from multiple resources.

3.  Generic / Pluggable Authentication

Resource data can be sensitive in nature and needs to be distributed
only to those that have a right to receive it.  This permissions
system should be generic in the sense that a resource does not
personally allow / deny access, but instead delegates permission
requests to a generic permissions handler.

4.  Flexible Serialization

Django API consumers will have disparate data format needs, and these
need to be addressed.  Formats such as XML, YAML, JSON need to be
considered during implementation.

5.  Clean Request Handling / Mapping

Jacob notes that browser limitations make one-to-one mapping of HTTP
methods (GET/POST/PUT/DELETE) to CRUD operations only a piece of the
puzzle.  Flexibility is need here to accommodate various consumer
classes.

6.  Proper Links / Foreign Key Resources

All resources which contain foreign key fields should be serialized to
contain links to said resources in the form of a URI.  One potential
expansion on this concept is adding “deep” or “full” serialization
support, whereby a consumer can request that foreign key references be
“folded” in to the core object.  This is open for debate.

7.  Scalable Deployment / Low Coupling.

Jacob makes the good point in his “Worst Practices” document that the
resource usage profile of a heavily used API is nothing like that of
the web app component of a service.  Therefore, the API module must be
capable of being run on its own server(s).

Thanks!

Bill Konrad


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

GSoC 2009: Testing Upgrades/Awesomeness

[Kevin Kubasik]

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 Awesomness Quotient of the Django Test Utils and
Regression Suite
=

Abstract


To fix and test, so cover the Admin site/
with Windmill use, avoiding the great fright.
At moment be, we cover not, popular/
is the admin but tested is not.
Great addition tests would be/
the key in promoting greater Django harmony.


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. In addition, the tools for testing a site under the
Django framework are weak, even if the API's available are quite
powerful.

Proposal


Overall Django has some great testing tools, but the addition of a few
key integrations and tools could make it a much more comprehensive and
easy to use testsuite. Namely, nose runners and extensions, Windmill
integration, and some expansions to Eric's django-test-utils package.
Namely, I want to accomplish the following:

   1. Work with Windmill and Nose to make sure running django tests
with Nose and running Windmill tests through django is easy and
painless. This will mostly involve work on the external projects, and
probably won't touch Django proper. But in coordinating with these
projects, I also hope to provide any missing or needed extension
points in Django to make this integration possible.
   2. Expand the Django test runner to provide Code Coverage
statistics. There are already some efforts towards this goal underway,
and I don't plan on reinventing the wheel. My hope is to integrate
their work, and potentially expand it based on Django's community
requests. Most likely the base of this work will be figleaf, but I
plan on researching other options. Lastly, I want to evaluate the
coverage of Django's current regression suite and provide a wiki page/
writeup detailing any major deficiencies so that they can be
addressed.
   3. Utilize the new Windmill test support to provide coverage of the
Admin interface. This is an extremely large task overall, but given
how easy Windmill has made the creation of tests, I hope that I will
be able to provide coverage of a majority of the admin's
functionality. This will not include support for the
django.contrib.gis namespace, but I will try and test all other
namespaces that have Admin integration or functionality (namely auth,
admin and comments).
   4. The last major component of this project will be the extension
and expansion of the django-test-utils package to add the following
components:
 1. Update the TestGen Middleware to serialize all testing
data (probably just via cPickle initially) to disk.
 2. Implement a pluggable 'Processor' framework to generate
the runnable tests from the serialized request data.(Aka twill/django
unittest/unittest)
 3. A basic web interface to start/stop the TestingMiddleware
and display its status/results.
 4. Utilizing the new Plugin framework allow for test-time
analysis such as unused Context variables and dead links.
 5. Integrate something like Werkzeug_ on test fails from web
interface runner.

Timeline


Weekly I should be able to put in between 20-30 hours a week, but that
will be focused on the weekends. During the week I will have classes,
but will be available during many of them for discussion, but will
avoid coding. (I have 2 lab classes that require me to be in a room
for 4 hours, but most of the time is watching something settle or spin
or do nothing at all). A breakdown of my projected timing:
Week 1: Gain familiarity with Windmills capabilities and limitations,
start integration of existing work on Nose and Windmill support.
Week 2-3: Get code coverage working for both Django Regression Suite
and under a manage command.
Week 4: Write first Windmill test for admin. Determine the
'environment' or set of Models we will use to test the Admin, confirm
with community that I am testing *every* major feature available in
the Admin.
Week 5-10: Test mania. Windmill test writing fury. Breakdown goes:
- Model list page and single object add (simple forms)
- Changelist (filters/drilldown/search etc.)(no actions yet)
- single object delete + complex forms (datetime, image, slug etc.)
- inline objects
- actions and history
- misc features and remaining niches
Week 10-12: Discuss missing tests or other cases to check. Possibly
provide branch of tests for new admin work (if that project is
accepted for GSOC). Add cool fun features and integration to django-
test-utils.


About you
-

I'm a long-time open source junkie in my last few quarters at 

Re: Deletion of related objects

[bo blanton]

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
> like to close it for 1.1.
>
> In summary, #9308 describes a situation where B has a nullable FK to
> A, and an instance of A is being deleted.   Currently, any B's related
> to A also get deleted.
>
> #9308 takes the position that any B.a_id's should be set to null
> rather than B instances being removed along with the desired deletion
> of A.   I'm asking explicitly whether this is is a bug?



i'm feeling that most of these "delete" issues could be fixed via  
something like this

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

i know y'all are really hating 'new signals' but i'm not sure how to  
do the myriad of cases without one.
Then the user can set things to null or 'ignore it' , change it, etc,  
etc.  And it has the added benefit of not breaking the api as it  
stands now (where i'm sure some folks rely on the delete not setting  
things to null)

bo

--~--~-~--~~~---~--~~
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: django <--> wsgi

[Waylan Limberg]

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 components but which require
> django.conf.settings to work. if they are going to go into a wsgi
> environment though, it seems a little strange to require a
> DJANGO_SETTINGS_MODULE environment variable and a django-style
> settings.py. i don't have any great ideas. open for suggestions.
>
[snip]

It seems to be a little known/remembered fact that
DJANGO_SETTINGS_MODULE and settings.py are not required to use django
code that requires settings. Settings can actually be configured
manually within python code calling settings.configure(). This way,
you only actually set settings that you need. In fact, outside of the
strict situation of a django project, it is the only way I deal with
settings when using parts of django.

See here for details: http://www.djangobook.com/en/1.0/appendixE/#cn57

However, the trick is that you can only call settings.configure() once
and it's possible that multiple middleware will need settings. On top
of that, the user may use some of those middlewhere and not others
and/or change the order of the middlewhere. You'll need some way to
work out whether configure has been called for each middlewhere and
only call it the first time. Not fun, but it's got to be better than
dealing with DJANGO_SETTINGS_MODULE and settings.py.

-- 

\X/ /-\ `/ |_ /-\ |\|
Waylan Limberg

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

Deletion of related objects

[Jeremy Dunck]

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 where B has a nullable FK to
A, and an instance of A is being deleted.   Currently, any B's related
to A also get deleted.

#9308 takes the position that any B.a_id's should be set to null
rather than B instances being removed along with the desired deletion
of A.   I'm asking explicitly whether this is is a bug?

Commit [8128] added some code which looks vaguely related, with the
commit message:
"Fixed #7853 -- Fixed another case of deleting inherited models with
foreign key references. Thanks to Russell for the test case that
demonstrated the problem."

There's a patch now which alters that code, but I'm not convinced it's
fixing anything.  This area is fairly lightly tested:
http://code.djangoproject.com/browser/django/trunk/tests/modeltests/delete/models.py?rev=8030#L36

Thoughts?

--~--~-~--~~~---~--~~
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: django <--> wsgi

[Alex Gaynor]

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 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 looking into the code needed to make this happen, and a
> > > few things have creeped up that need some design decisions:
> >
> > > 1. view *args and **kwargs (django view -> wsgi app)
> > > a wsgi app created from a django view is probably not going to be
> > > called by django's dispatcher, so we have to either do without
> > > arguments besides a request object, or generate them in the new wsgi
> > > app. we could just say that django views are only eligible to become
> > > wsgi apps if they take no extra arguments:
> >
> > > @view_to_wsgi_app
> > > def django_style_view(request):
> > >#...
> >
> > > but i think that takes considerable punch out of the proposal. maybe
> > > if the decorator accepted a regular expression like in urlpatterns,
> > > the decorator could pull the arguments out of the request path.
> >
> > > @view_to_wsgi_app(r'books/get/(?P\d{2})/')
> > > def django_style_view(request, book_id=None):
> > >#...
> >
> > > and it could potentially also take *args and **kwargs to add to the
> > > info pulled from the path
> >
> > > @view_to_wsgi_app(r'books/get/(?P\d{2})/', 'James Joyce',
> > > publisher='Penguin')
> > > def django_style_view(request, author, book_id=None, publisher=None):
> > >#...
> >
> > > with that we have pretty much the same control that we had with
> > > django's urlpatterns routing, but potentially some duplicated work if
> > > you are also defining these patterns with Routes or whatever else.
> >
> > > 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 components but which require
> > > django.conf.settings to work. if they are going to go into a wsgi
> > > environment though, it seems a little strange to require a
> > > DJANGO_SETTINGS_MODULE environment variable and a django-style
> > > settings.py. i don't have any great ideas. open for suggestions.
> >
> > > 3. error pages (views -> apps, dj middleware -> wsgi middleware)
> > > i think when we take a django piece and stick it into a wsgi
> > > environment, we should give up most control and only do the one
> > > specific task. but then again our error pages sure are nice. maybe
> > > this is an argument for pulling the error pages into exception
> > > middleware which could then be converted to wsgi middleware.
> >
> > > travis parker
> >
> > How about creating Django Views from WSGI middleware(aka just hooking
> them
> > up in the URLConf), this is probably a bit easier, maybe even just a
> wrapper
> > function to assign an attr to it so the Handler knows to give it whatever
> > the appropriate params are(I'm not totally up on what WSGI middleware
> looks
> > like).
> >
> > Alex
> >
> > --
> > "I disapprove of what you say, but I will defend to the death your right
> to
> > say it." --Voltaire
> > "The people's good is the highest law."--Cicero
>
> wsgi middleware doesn't necessarily expect to be the ending turnaround
> point (django's views do - they *must* accept an HttpRequest and
> *must* return an HttpResponse). the django version of wsgi middleware
> is django middleware as they both might return a response or might
> pass the request on down the stack (or on the other end, might modify
> or replace the response coming up the stack from below).
>
> i realized something else:
> 4. wsgi middleware -> django middleware is probably not possible
> this is for the same reason that we don't have a
> middleware_from_decorator utility. a piece of wsgi middleware is
> simply a decorator around a wsgi application (which is a callable), so
> the behavior of what to do when the decorated app throws an exception
> is buried in the same fucntion as what to do with the request, and
> what to do with the response. they can't be split up. we could
> probably make a converter of wsgi middleware into django view
> decorator.
>
> travis
> >
>
You're completely right, I seem to recall hearing someone discuss the idea
and must have translated it into something it clearly wasn't :/

Alex

-- 
"I disapprove of what you say, but I will defend to the death your right to
say it." --Voltaire
"The people's good is the highest law."--Cicero

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google 

Re: Changeset 10219 does not fix #9587

[Alex Gaynor]

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 put in dpaste? http://dpaste.com/21753/ It's
> basically the same idea used in the changeset.
>
> On Mar 31, 3:35 pm, Joseph Kocherhans  wrote:
> > 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.
>
> I didn't understand, you think is better reopen the ticket, open a new
> ticket or don't do anything?
>
> >
> > Joseph
> >
>
Joseph was saying to not bother either opening a new ticket or reopening
that since he's working on it right now.

Alex
-- 
"I disapprove of what you say, but I will defend to the death your right to
say it." --Voltaire
"The people's good is the highest law."--Cicero

--~--~-~--~~~---~--~~
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: django <--> wsgi

[Alex Gaynor]

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 between django middleware and wsgi middleware.
>
> I have started looking into the code needed to make this happen, and a
> few things have creeped up that need some design decisions:
>
> 1. view *args and **kwargs (django view -> wsgi app)
> a wsgi app created from a django view is probably not going to be
> called by django's dispatcher, so we have to either do without
> arguments besides a request object, or generate them in the new wsgi
> app. we could just say that django views are only eligible to become
> wsgi apps if they take no extra arguments:
>
> @view_to_wsgi_app
> def django_style_view(request):
>#...
>
> but i think that takes considerable punch out of the proposal. maybe
> if the decorator accepted a regular expression like in urlpatterns,
> the decorator could pull the arguments out of the request path.
>
> @view_to_wsgi_app(r'books/get/(?P\d{2})/')
> def django_style_view(request, book_id=None):
>#...
>
> and it could potentially also take *args and **kwargs to add to the
> info pulled from the path
>
> @view_to_wsgi_app(r'books/get/(?P\d{2})/', 'James Joyce',
> publisher='Penguin')
> def django_style_view(request, author, book_id=None, publisher=None):
>#...
>
> with that we have pretty much the same control that we had with
> django's urlpatterns routing, but potentially some duplicated work if
> you are also defining these patterns with Routes or whatever else.
>
> 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 components but which require
> django.conf.settings to work. if they are going to go into a wsgi
> environment though, it seems a little strange to require a
> DJANGO_SETTINGS_MODULE environment variable and a django-style
> settings.py. i don't have any great ideas. open for suggestions.
>
> 3. error pages (views -> apps, dj middleware -> wsgi middleware)
> i think when we take a django piece and stick it into a wsgi
> environment, we should give up most control and only do the one
> specific task. but then again our error pages sure are nice. maybe
> this is an argument for pulling the error pages into exception
> middleware which could then be converted to wsgi middleware.
>
> travis parker
> >
>
How about creating Django Views from WSGI middleware(aka just hooking them
up in the URLConf), this is probably a bit easier, maybe even just a wrapper
function to assign an attr to it so the Handler knows to give it whatever
the appropriate params are(I'm not totally up on what WSGI middleware looks
like).

Alex

-- 
"I disapprove of what you say, but I will defend to the death your right to
say it." --Voltaire
"The people's good is the highest law."--Cicero

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

[Vinicius Mendes | meiocodigo.com]

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 pm, Joseph Kocherhans  wrote:
> 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.

I didn't understand, you think is better reopen the ticket, open a new
ticket or don't do anything?

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

django <--> wsgi

[Travis Parker]

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 looking into the code needed to make this happen, and a
few things have creeped up that need some design decisions:

1. view *args and **kwargs (django view -> wsgi app)
a wsgi app created from a django view is probably not going to be
called by django's dispatcher, so we have to either do without
arguments besides a request object, or generate them in the new wsgi
app. we could just say that django views are only eligible to become
wsgi apps if they take no extra arguments:

@view_to_wsgi_app
def django_style_view(request):
#...

but i think that takes considerable punch out of the proposal. maybe
if the decorator accepted a regular expression like in urlpatterns,
the decorator could pull the arguments out of the request path.

@view_to_wsgi_app(r'books/get/(?P\d{2})/')
def django_style_view(request, book_id=None):
#...

and it could potentially also take *args and **kwargs to add to the
info pulled from the path

@view_to_wsgi_app(r'books/get/(?P\d{2})/', 'James Joyce',
publisher='Penguin')
def django_style_view(request, author, book_id=None, publisher=None):
#...

with that we have pretty much the same control that we had with
django's urlpatterns routing, but potentially some duplicated work if
you are also defining these patterns with Routes or whatever else.

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 components but which require
django.conf.settings to work. if they are going to go into a wsgi
environment though, it seems a little strange to require a
DJANGO_SETTINGS_MODULE environment variable and a django-style
settings.py. i don't have any great ideas. open for suggestions.

3. error pages (views -> apps, dj middleware -> wsgi middleware)
i think when we take a django piece and stick it into a wsgi
environment, we should give up most control and only do the one
specific task. but then again our error pages sure are nice. maybe
this is an argument for pulling the error pages into exception
middleware which could then be converted to wsgi middleware.

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

[Vinicius Mendes | meiocodigo.com]

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/forms/forms...
>
> > 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 will
> > cause problems in lines 428 and 447 of models.py (
> >http://code.djangoproject.com/browser/django/trunk/django/forms/model...
> > ). I wrote a little patch, if you want to take a look, you will
> > understand what I am saying. The diff is here:
>
> >http://dpaste.com/21753/
>
> > On Mar 31, 2:41 pm, Alex Gaynor  wrote:
> > > 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 logic
> > > > used in the patch to solve the problem. If the form doesn't have a
> > > > cleaned_data attr, so I get it from the field, and check it. All the
> > > > changes were made in the django/forms/models.py In the methods
> > > > save_existing_objects and save_new_objects.
>
> > > > On Mar 31, 2:35 pm, Alex Gaynor  wrote:
> > > > > 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_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?
>
> > > > > > 
>
> > > > > > Vinícius Mendes
> > > > > > Engenheiro de Computação
> > > > > > Meio Código - A peça que faltava para o seu código!
> > > > > > URLhttp://www.meiocodigo.com
>
> > > > > Look at line 216 of formsets.py it specifically makes sure not to
> > > > interogate
> > > > > cleaned_data.
>
> > > > > Alex
>
> > > > > --
> > > > > "I disapprove of what you say, but I will defend to the death your
> > right
> > > > to
> > > > > say it." --Voltaire
> > > > > "The people's good is the highest law."--Cicero
>
> > > Not the line 216 i see, but to save trouble here's the full comment:
>
> > >  215                # The way we lookup the value of the deletion field
> > here
> > > takes  216                # more code than we'd like, but the form's
> > > cleaned_data will  217                # not exist if the form is invalid.
>
> > > Alex
>
> > > --
> > > "I disapprove of what you say, but I will defend to the death your right
> > to
> > > say it." --Voltaire
> > > "The people's good is the highest law."--Cicero
>
> No, my comments weren't directed at trunk, but neither was the commit you
> referenced.  You'll need a failing test case(probably just trying to call
> save on a formset like the ones in the tests).
>
> Alex
>
> --
> "I disapprove of what you say, but I will defend to the death your right to
> say it." --Voltaire
> "The people's good is the highest law."--Cicero
--~--~-~--~~~---~--~~
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: Changeset 10219 does not fix #9587

[Alex Gaynor]

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 the point here isn't create a cleaned_data for
> the form. I know it will not exist. The problem is that this will
> cause problems in lines 428 and 447 of models.py (
> http://code.djangoproject.com/browser/django/trunk/django/forms/models.py
> ). I wrote a little patch, if you want to take a look, you will
> understand what I am saying. The diff is here:
>
> http://dpaste.com/21753/
>
> On Mar 31, 2:41 pm, Alex Gaynor  wrote:
> > 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 logic
> > > used in the patch to solve the problem. If the form doesn't have a
> > > cleaned_data attr, so I get it from the field, and check it. All the
> > > changes were made in the django/forms/models.py In the methods
> > > save_existing_objects and save_new_objects.
> >
> > > On Mar 31, 2:35 pm, Alex Gaynor  wrote:
> > > > 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_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?
> >
> > > > > 
> >
> > > > > Vinícius Mendes
> > > > > Engenheiro de Computação
> > > > > Meio Código - A peça que faltava para o seu código!
> > > > > URLhttp://www.meiocodigo.com
> >
> > > > Look at line 216 of formsets.py it specifically makes sure not to
> > > interogate
> > > > cleaned_data.
> >
> > > > Alex
> >
> > > > --
> > > > "I disapprove of what you say, but I will defend to the death your
> right
> > > to
> > > > say it." --Voltaire
> > > > "The people's good is the highest law."--Cicero
> >
> > Not the line 216 i see, but to save trouble here's the full comment:
> >
> >  215# The way we lookup the value of the deletion field
> here
> > takes  216# more code than we'd like, but the form's
> > cleaned_data will  217# not exist if the form is invalid.
> >
> > Alex
> >
> > --
> > "I disapprove of what you say, but I will defend to the death your right
> to
> > say it." --Voltaire
> > "The people's good is the highest law."--Cicero
> >
>
No, my comments weren't directed at trunk, but neither was the commit you
referenced.  You'll need a failing test case(probably just trying to call
save on a formset like the ones in the tests).

Alex

-- 
"I disapprove of what you say, but I will defend to the death your right to
say it." --Voltaire
"The people's good is the highest law."--Cicero

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

[Alex Gaynor]

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 logic
> used in the patch to solve the problem. If the form doesn't have a
> cleaned_data attr, so I get it from the field, and check it. All the
> changes were made in the django/forms/models.py In the methods
> save_existing_objects and save_new_objects.
>
> On Mar 31, 2:35 pm, Alex Gaynor  wrote:
> > 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_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?
> >
> > > 
> >
> > > Vinícius Mendes
> > > Engenheiro de Computação
> > > Meio Código - A peça que faltava para o seu código!
> > > URLhttp://www.meiocodigo.com
> >
> > Look at line 216 of formsets.py it specifically makes sure not to
> interogate
> > cleaned_data.
> >
> > Alex
> >
> > --
> > "I disapprove of what you say, but I will defend to the death your right
> to
> > say it." --Voltaire
> > "The people's good is the highest law."--Cicero
> >
>
Not the line 216 i see, but to save trouble here's the full comment:

 215# The way we lookup the value of the deletion field here
takes  216# more code than we'd like, but the form's
cleaned_data will  217# not exist if the form is invalid.

Alex

-- 
"I disapprove of what you say, but I will defend to the death your right to
say it." --Voltaire
"The people's good is the highest law."--Cicero

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

[Vinicius Mendes | meiocodigo.com]

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 the field, and check it. All the
changes were made in the django/forms/models.py In the methods
save_existing_objects and save_new_objects.

On Mar 31, 2:35 pm, Alex Gaynor  wrote:
> 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_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?
>
> > 
>
> > Vinícius Mendes
> > Engenheiro de Computação
> > Meio Código - A peça que faltava para o seu código!
> > URLhttp://www.meiocodigo.com
>
> Look at line 216 of formsets.py it specifically makes sure not to interogate
> cleaned_data.
>
> Alex
>
> --
> "I disapprove of what you say, but I will defend to the death your right to
> say it." --Voltaire
> "The people's good is the highest law."--Cicero
--~--~-~--~~~---~--~~
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: Call for ideas: Admin Improvements

[Jacob Kaplan-Moss]

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 without a community discussion or BDFL
> pronouncement that this is the right thing to do.

Yeah, and I think Zain perhaps opened up a can of worms by not clearly
stating that the use of jquery (or whatever) is basically required to
pull off something of this nature. I told him, and I'll repeat it,
that "refactor the admin javascript to use {framework}" is a worthless
task without it being part of some bigger task that needs the tools
said framework provides. So I'd view the "refactor to use framework"
part as being incidental to the "add cool features to the UI"; the
latter isn't possible without the former.

I don't think this needs a decision -- consensus, BDFL, or otherwise
-- right away, though; this is still a pre-proposal, and we don't know
that we'll accept it, and we don't know that we'll find a mentor, and
we don't know that the project will succeed. Indeed, there's a good
chance that the simple controversy here will keep Zain away from this
one; not everyone wants to step into this problem.

In the end we'll have to make a call one way or the other, and I'm
happy to be the bad guy and just make a declaration. But I'm going to
wait to do so until I actually see working code. Let's let the
decision be made by features so compelling we're willing to deal with
the bullshit.

Jacob

--~--~-~--~~~---~--~~
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: Call for ideas: Admin Improvements

[Russell Keith-Magee]

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). But it is of course for the BDFLs
> to decide if that is allowed or not.

I don't think there is any doubt that jQuery (or any other JS
framework) could be used to implement these features, so a "prototype"
doesn't gain us anything. In the absence of a community decision to
adopt a JS framework, this project would effectively become a fork of
contrib.admin - an outcome that isn't a good use of the Django's
community's resources (including, in this case, Google's money).

Of course, in the light of Jacob's message, it sounds like we might be
about to adopt a JS framework, so this becomes a moot point.

Yours,
Russ Magee %-)

--~--~-~--~~~---~--~~
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: Call for ideas: Admin Improvements

[Russell Keith-Magee]

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 sooner or later we're going to need to make this move
> inside the admin, or else more advanced stuff is just out of reach. I
> know that the choice of which framework to use is a painful,
> contentious one, but, hey, Python just chose mercurial over git so
> maybe the holy warriors are looking over there right now :)

For the record - I actually agree that this sort of change is
inevitable. IMHO, we've pretty much hit the limit of what we can
achieve without moving to a JS framework. I don't welcome the
inevitable holy war, but this is one of those times where a BDFL comes
in handy :-)

> More seriously, though, I think this is a pretty good pre-proposal,
> and assuming that Zain can find enough work to fill the summer with
> admin UI improvements I'll champion it, framework or not.

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 without a community discussion or BDFL
pronouncement that this is the right thing to do.

We are pretty busy as a community right now in the lead up to v1.1;
having a protracted bikeshed discussion about javascript frameworks
will inevitably draw attention away from other places where attention
is actually required. However, the amount of work that is possible (or
even desirable) in an 'admin UI refactor' project is entirely
dependent on having this discussion. We certainly don't have the time
or resources to have this discussion in the 3 days remaining before
final GSoC proposals are due.

Of course, if you're happy to have a deliberately short public
discussion and make a pronouncement, this all becomes moot. Again, for
the record, I'd be completely comfortable with this approach to the
problem.

Russ %-)

--~--~-~--~~~---~--~~
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: Call for ideas: Admin Improvements

[mrts]

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 allowed or not.

On Mar 31, 4:30 pm, Russell Keith-Magee 
wrote:
> 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. Proposals that
> >> hinge on the use of JQuery (or any other toolkit) will not be looked
> >> upon favourably.
>
> > From a conceptual point of view this is of course correct, however,
> > from a pragmatic viewpoint this restriction *could* be lifted if the
> > person who implements this can prove that admin refactor will be
> > considerably easier by coupling jQuery.
>
> > At least a jQuery-based initial version can be provided and the
> > decision to implement things with plain JS instead can be made later,
> > before the eventual merge.
>
> mrts, it's not just correct from a "conceptual" point of view. It's
> correct in every conceivable way.
>
> Please keep in mind that I'm one of the core developers, and as such,
> I am in a fairly good position to be able to advise students on what
> will be considered a strong proposal for the GSoC. We (the Django Core
> Developers) _might_, at some point in the future, in consultation with
> the community, pick a javascript framework to use for contrib.admin.
> However, that decision isn't going to be made lightly, it's unlikely
> to be made at the request of a GSoC student, and it certainly isn't
> going to be made between now and the submission deadline for GSoC.
>
> 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).
>
> Yours,
> Russ Magee %-)
--~--~-~--~~~---~--~~
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: Call for ideas: Admin Improvements

[Jacob Kaplan-Moss]

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, erm, advised him to. We had a pretty long discussion here
at PyCon about admin UI improvements as an SoC project. A couple
people pointed out (correctly) that one of the issues in such a
proposal would be that some more advanced stuff (i.e. drag'n'drop
inlines) would be pretty painful to pull off with the ghettoframework
we're using now. But with a framework (any, really), it'd be pretty
easy. So I told Zain that if he took this on, it'd be fine to include
the use of A Framework as a make-this-task-easier kind of thing.

I think that sooner or later we're going to need to make this move
inside the admin, or else more advanced stuff is just out of reach. I
know that the choice of which framework to use is a painful,
contentious one, but, hey, Python just chose mercurial over git so
maybe the holy warriors are looking over there right now :)

More seriously, though, I think this is a pretty good pre-proposal,
and assuming that Zain can find enough work to fill the summer with
admin UI improvements I'll champion it, framework or not.

Jacob

--~--~-~--~~~---~--~~
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: Call for ideas: Admin Improvements

[Russell Keith-Magee]

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. Proposals that
>> hinge on the use of JQuery (or any other toolkit) will not be looked
>> upon favourably.
>
> From a conceptual point of view this is of course correct, however,
> from a pragmatic viewpoint this restriction *could* be lifted if the
> person who implements this can prove that admin refactor will be
> considerably easier by coupling jQuery.
>
> At least a jQuery-based initial version can be provided and the
> decision to implement things with plain JS instead can be made later,
> before the eventual merge.

mrts, it's not just correct from a "conceptual" point of view. It's
correct in every conceivable way.

Please keep in mind that I'm one of the core developers, and as such,
I am in a fairly good position to be able to advise students on what
will be considered a strong proposal for the GSoC. We (the Django Core
Developers) _might_, at some point in the future, in consultation with
the community, pick a javascript framework to use for contrib.admin.
However, that decision isn't going to be made lightly, it's unlikely
to be made at the request of a GSoC student, and it certainly isn't
going to be made between now and the submission deadline for GSoC.

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

Yours,
Russ Magee %-)

--~--~-~--~~~---~--~~
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: GSoC Proposal: Serialization Enhancements

[Russell Keith-Magee]

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, provide
> most of the functionality for the common use case being discussed?  A
> template would not simplify the process, certainly, but it would provide
> everything that templates do...  There's more than enough logic to fit data
> to a format, and the host of filters would be undeniably useful.  Again,
> this is certainly not ideal -- the '{' escaping for JSON alone would drive a
> person insane.  Are there use cases this is excluding?

Depends on exactly what you mean by 'template'. I would expect that
the end serialization would still occur using the underlying
JSON/XML/YAML libraries, so you can't really use a template in the
sense of a Django HTML template. However, if you're talking about a
format in which you can express serialization instructions, then I
could be convinced (but I need to see details).

> I ask not because I think that's the best solution, but obviously I need a
> more accurate mental image of the goal, as seen by the core developers.  So
> long as deserialization is no issue, as is typical in AJAX applications (or
> anything where an external system is looking at an app's state), providing a
> 'shortcut' interface to provide structure and some form of pre-processing
> hooks seems like a good way to go.

To clarify - it's not that deserialization *isn't* an issue, it's that
deserialization isn't always possible. Django's default serializers
have sufficient data in them to allow deserialization. That same data
_could_ be presented in  a different format, and it would certainly be
nifty if, in those cases, deserialization could be preserved. However,
I accept that this is a non-trivial goal, so if it turns out to not be
possible (or only possible under specific circumstances - such as a
serializer explicitly marked as deserializable), then I won't lose
much sleep.

> For example, using the models in my
> original proposal,
>
> from project.app.models import Order
> from django.core.serializers import Serializer
>
> class OrderSerializer(Serializer):
>     structure = {
>     "order_id": "pk",
>         ''products": [
>          {
>                 "name": "products__name",
>                 "price": "products__price",
>                 "description": "products__description"
>             }
>         ],
>         "total": "total_price"
>     }

Ok - I can see the approach you're aiming at here. I can see how it
could work - there are some details to sort out, but on the whole, I
like the elegance.

Some immediate concerns/questions:

 * How do you deal with objects of different type? At present, you can
pass a disparate list of objects to the serializer. The only
requirement is that every element in the list is a Django object - it
doesn't need to be a homogeneous list.

 * How does this translate to non-JSON serializers? The transition to
YAML shouldn't be too hard, but what about XML? How does `structure`
get interpreted by the XML serializer? How do you differentiate
between the element name, element attributes, and child nodes that can
be used in XML serialization?

> Some "helpers" I think might be useful would be hooks for the various types
> of fields, including but not limited to relations, to allow things like
> special text processing or dependency traversal, and providing the current
> default "structure" in case the user simply wants to do some pre-processing
> of some form.

I appreciate that this is one of those details that we will need to
finesse with time, but it would be interesting to hear your
preliminary thoughts on this - in particular, on how you plan to link
the string in the 'template' to the helper.

> It's obviously rough, and hashing out the specifics of the exposed API will
> take some research and discussion, but does this synergize better with the
> general use case? Let me know, also, if I haven't quite established my take
> on your take, so to speak.

This attempt is certainly a lot closer than the last. As you note -
there are still details, but it's certainly going in the right
direction. I haven't got any particularly concrete ideas on what the
final solution should look like - I just know the sort of limitations
that the existing framework has, and the sort of use cases I'd like to
be able to hit.

However, here's my brain dump, such as it is:

My initial thoughts was that the serializers would end up being a lot
like the Feeds framework - a base class with lots of
methods/attributes that can be overridden to provide specific
rendering behaviour. If you tear down the serialization problem, you
end up with a set of relatively simple questions:

 * What is the top level structure (e.g.,, the outer [] in JSON, the
XML header and 

Re: Call for ideas: Admin Improvements

[Russell Keith-Magee]

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 relations
>> 3) Foreign Key traversal to see and modify models referenced to by
>> ForeignKeys inline
>> 4) Refactor the admin's Javascript to use JQuery for maintainability
>>
>> Do you have any other ideas for features and fixes to improve the
>> admin interface?
>
> I think that an API for declaring read-only fields and the ability to
> edit multiple objects on the same page are some wanted features which
> have been discussed on this list. I'm not sure if you would consider
> those suggestions pure interface design though.
>
> All the things enumerated so far seem more like a list of small
> features. So I assume that for a GSoC proposal you'd need to suggest a
> coherent approach rather than a list of minor fixes/feature
> extensions.

Not necessarily. Using the Django ticket tracker as a source for ideas
could be a way to create a very compelling application. A random
grab-bag of tickets probably won't be looked upon favourably, but If
there is a common theme to the tickets (e.g., in this case, UI
enhancements for the admin), then you essentially have a collection of
ideas that have already been approved by the Django core, and are just
waiting for someone to do the work. The granularity provided by using
multiple tickets makes it easier to make accurate time estimates,
easier to evaluate progress, and easier to constrain scope if the time
required exceeds expectations.

> As for including jQuery (or any other javascript library),
> I doubt this will be received favourably. Going for plain javascript -
> even if it's a bit more challenging to do - is a good way to find
> overall consensus.

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 other toolkit) will not be looked
upon favourably.

Yours,
Russ Magee %-)

--~--~-~--~~~---~--~~
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: Call for ideas: Admin Improvements

[Manuel Saelices]

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 = models.TextField()

you can put a hidden inline editor (activated by dobleclicking label), with
this sentences:

{% inplace_edit book "title" %}
{% inplace_edit book "body" %}

This create a default model form for Book object. Also, you can redefine a
custom model form.


Regards,
Manuel Saelices.

On Tue, Mar 31, 2009 at 9:53 AM, 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 referenced to by
> ForeignKeys inline
> 4) Refactor the admin's Javascript to use JQuery for maintainability
>
> Do you have any other ideas for features and fixes to improve the
> admin interface?
>
> >
>

--~--~-~--~~~---~--~~
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: Call for ideas: Admin Improvements

[Dougal Matthews]

   - 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
http://www.dougalmatthews.com/




2009/3/31 mrts :
>
> 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/
> .
>
> On Mar 31, 10:53 am, 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 referenced to by
>> ForeignKeys inline
>> 4) Refactor the admin's Javascript to use JQuery for maintainability
>>
>> Do you have any other ideas for features and fixes to improve the
>> admin interface?
> >
>

--~--~-~--~~~---~--~~
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: Call for ideas: Admin Improvements

[mrts]

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

On Mar 31, 10:53 am, 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 referenced to by
> ForeignKeys inline
> 4) Refactor the admin's Javascript to use JQuery for maintainability
>
> Do you have any other ideas for features and fixes to improve the
> admin interface?
--~--~-~--~~~---~--~~
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: Call for ideas: Admin Improvements

[Richard Smith]

   - 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
 one account only
  - Dynamic add/remove columns for models
   - Foreign Key filtering (this would go along with your #3)
   - History improvements with undo functionality (this is already done with
   django-reversion but is an excellent addon)
   - Mass file/photo upload
   - drag and drop for model objects with an order field (this would be
   great for images)
   - Ability to increase text size inside the textfield widget
   - ability to increase textfield widget size

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

Call for ideas: Admin Improvements

[zain]

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 admin's Javascript to use JQuery for maintainability

Do you have any other ideas for features and fixes to improve the
admin interface?

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