Re: RFC: More class based views, take two
Hi Iván, I'd temporarily given up on getting extra_views into Django because of a blocking issue with pagination and formsets. Assuming a goal is to be able to build a new admin using class-based views, there is a prerequisite of being able to paginate, sort and filter on the querysets used for modelformsets. The problem is that with Django's class-based views as they are, pagination is handled at the template context stage of the logic, whereas the formsets are instantiated and validated much earlier. I had raised a ticket about fixing this, but it was closed as wontfix because it would almost certainly introduce backwards-incompatible changes On a related now, you mentioned that none of the libraries you've mentioned are sufficiently polished. What further work do they need? As I see it, my main omission right now is documentation, though that is in progress. Regards, Andy On 27 May 2012 21:54, Iván Raskovsky wrote: > The generic class based views were introduced in 1.3, since then they > haven't seen much love. I feel the most wanted missing views are the > formsets related ones (specially the inline_formsets related ones). > > I've written to the list some months ago[0] with no reply. Luckily I'll > get more traction this time. Several projects have popped up[1, 2, 3] to > cover this area. Each one has different approaches. > > Ticket #16256[4] is tracking this changes > > * enhanced_cbv[0] * > > Tries to maintain a similar API to the existing views and the admin > inlines. Creates three generic views for a multiple formsets view, multiple > model_formsets view and a model with multiple inline_formset view. Joins > the update and create views in one view. > > * extra-views[1] * > > Keeps the current API as much as possible adding views for a one formset > and for one model_formset and adds views for working with > inline_formsets and generic inline_formsets. > > * cbv_utils[2] * > > I haven't played much with this one yet, but it only adds a view to work > with inline_formsets. It also proposes changes to the existing CVB APIs > to simplify adding this views[5]. > > Another related ticket is #10403[6]: a declarative syntax to define > FormSets so we don't need a special wrapper around the factories > simplifying creating inlines in a similar fashion as the admin's > InlineModelAdmin. > > So, we have 3 tested and working alternatives for these views. I think > none of them is polished enough as for inclusion to core. > > I have no idea how to move forward. Right now it seems kinda stalled. > Should we pick one implementation and start moving forward with that > one? If so, which one? Should we start a wiki page discussing the > different API decisions we need to make? > > I think we have the manpower to make this possible, the three > implementations shows people really need this in their projects and I'm > more than willing to spend time working on this. > > Any feedback will be greatly appreciated, > Iván > > [0] https://groups.google.com/d/msg/django-developers/aWRDIwDKDG8/gW3RGurxoZoJ > [1] https://github.com/rasca/django-enhanced-cbv > [2] https://github.com/AndrewIngram/django-extra-views/ > [3] https://github.com/tswicegood/cbv_utils > [4] https://code.djangoproject.com/ticket/16256 > [5] https://code.djangoproject.com/ticket/17557 > [6] https://code.djangoproject.com/ticket/10403 > > -- > 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. > -- 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.
GeoDjango and requirement's versions
Hello! https://docs.djangoproject.com/en/dev/ref/contrib/gis/install/#requirements lists GeoDjango's version requirements. Fedora ships newer versions of those libraries. I was wondering whether any incompatibility could exist: Fedora has: Proj 4.8 GDAL 1.9 I was also wondering about PostGIS 2.0, although there is no Fedora package yet. Greetings, Volker Fröhlich Fedora -- 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: GeoDjango and requirement's versions
On 28 May 2012 07:50, Volker Froehlich wrote: > Hello! > > https://docs.djangoproject.com/en/dev/ref/contrib/gis/install/#requirements > lists GeoDjango's version requirements. > > Fedora ships newer versions of those libraries. I was wondering whether > any incompatibility could exist: I've been using GeoDjango on my Fedora desktop with no issues > > I was also wondering about PostGIS 2.0, although there is no Fedora > package yet. I believe PostGIS 2.0 isn't supported yet: https://code.djangoproject.com/ticket/16455 Chris -- 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: supported backends in core
On May 28, 3:14 pm, Chris Northwood wrote: > I believe PostGIS 2.0 isn't supported > yet:https://code.djangoproject.com/ticket/16455 I added some comments to that ticket. I am going to hijack this thread, and ask what is the status of Oracle and spatialite support? Anybody running tests on these backends? spatialite seems a bit hard to install, and Oracle GIS functionality seems to be available only in the commercial versions. I think in the long run the requirement for any DB backend to stay in core must be that we have a way to run tests automatically on that backend. When working with the ORM, running tests on all backends manually is impossible, as it takes just too much time. Especially if you add Py3 to the mix. Currently Oracle - both gis and standard - is missing automatic testing, and spatialite is missing too. Anybody have the know-how to set these up? Any chance of getting another machine with Oracle installation? - Anssi -- 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: Python 3 port - now available on GitHub
> I found following error when trying to browse to the admin site of my django > app: > > File > ".../venv//lib/python3.2/site-packages/django/db/backends/postgresql_psycopg2/base.py", > line 8, in > from django.db import utils > ImportError: cannot import name utils Not sure why it isn't working for you. The import seems to work for me: vinay@eta-oneiric64:~/projects/django3/tests$ PYTHONPATH=.. DJANGO_SETTINGS_MODULE=test_sqlite python3.2 Python 3.2.2 (default, Sep 5 2011, 21:17:14) [GCC 4.6.1] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from django.db import utils >>> Regards, Vinay Sajip -- 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: Python 3 port - now available on GitHub
On May 26, 1:31 pm, Vinay Sajip wrote: > There are problems with some virtualenv versions, see this open > virtualenv issue: > > https://github.com/pypa/virtualenv/issues/194 > > The problem with importing tokenize.py in your traceback implies you > might be running into this issue. Is there any workaround for this? I need to install psycopg2 and cx- oracle under python 3 to run the tests, and virtualenv is the only way I know how to do this. However, this issue is causing a lot of noise in the results, making testing the py3-branch somewhat hard. - Anssi -- 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: RFC: More class based views, take two
Hi Andy, On Mon, May 28, 2012 at 7:30 AM, Andrew Ingram wrote: > Hi Iván, > > I'd temporarily given up on getting extra_views into Django because of > a blocking issue with pagination and formsets. > > Assuming a goal is to be able to build a new admin using class-based > views, there is a prerequisite of being able to paginate, sort and > filter on the querysets used for modelformsets. The problem is that > with Django's class-based views as they are, pagination is handled at > the template context stage of the logic, whereas the formsets are > instantiated and validated much earlier. I had raised a ticket about > fixing this, but it was closed as wontfix because it would almost > certainly introduce backwards-incompatible changes I'm not sure how to work around the issue, I didn't spend much time on it. But for sure we can either find a BC way to solve this or revisit that wontfix. > On a related now, you mentioned that none of the libraries you've > mentioned are sufficiently polished. What further work do they need? > As I see it, my main omission right now is documentation, though that > is in progress. I agree your implementation is very well done (nicer than mine), but from a quick inspection I could find: * There are almost no docstrings * One can abstract part of the code in BaseFormSetMixin and FormMixin into a new Mixin * get_initial() could get a .copy() as in https://github.com/django/django/blob/master/django/views/generic/edit.py#L18 * I don't agree with the get_success_url implementation (it defers from the current ones) * There's a get_context_data() in FormSetMixin that I think shouldn't live there * I think you are not taking into consideration formsets prefixes clashing * I'm not sold on BaseInlineFormSetMixin inheriting from BaseFormSetMixin: do you really need e.g. get_context_data in there if you won't use it? This is just a quick list I made while skimming through the code and what I remember from past months. I'm more than glad to be proven wrong! I'm sure you can make a similar list quickly with my implementation, I think the best thing we can do is work together, this is a big ticket. Get the best of each implementation and merge it together. It's time to get the ball rolling. Regards, Iván -- 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: Python 3 port - now available on GitHub
On Sat, May 26, 2012 at 4:31 AM, Vinay Sajip wrote: > Anssi, > > Thanks very much for the feedback. > >> Both Oracle and MySQL fail to run because of this error (on both 2.7 >> and 3.2): >> File "/home/akaariai/Programming/django/tests/django/db/backends/ >> mysql/compiler.py", line 2, in >> from django.utils.itercompat import izip_longest >> ImportError: cannot import name izip_longest > > I will investigate this. The izip_longest definition was removed from itercompat in revision b60b45a2a565 (which is fine, since it was only there for Python 2.5 compatibility), but it means that the places that imported it need to be changed to import it directly from py3 instead. -- 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: Python 3 port - now available on GitHub
On May 28, 8:24 pm, Anssi Kääriäinen wrote: > Is there any workaround for this? I need to install psycopg2 and cx- > oracle under python 3 to run the tests, and virtualenv is the only way > I know how to do this. However, this issue is causing a lot of noise > in the results, making testing the py3-branch somewhat hard. Just get a recent version of virtualenv.py and run that. For example, https://raw.github.com/pypa/virtualenv/1.7.1.2/virtualenv.py (I've not specifically tested this exact version, but IIRC I only had the problem with my distro's version, which was a little out of date). It's a self contained script, so just downloading it and running it should allow you to create a working virtual environment. Thanks for your input so far. Regards, Vinay Sajip -- 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: Python 3 port - now available on GitHub
> The izip_longest definition was removed from itercompat in revision > b60b45a2a565 (which is fine, since it was only there for Python 2.5 > compatibility), but it means that the places that imported it need to > be changed to import it directly from py3 instead. Right, and I fixed that a couple of days ago. Anssi has kindly posted feedback to the GitHub issue tracker on my repo, so I'm following up there. Regards, Vinay Sajip -- 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: Customizable Serialization check-in
Hi Piotr; Apologies for the delay in responding to your updated API. On Tue, May 22, 2012 at 6:59 AM, Piotr Grabowski wrote: > I do some changes to my previous API: (https://gist.github.com/2597306 <- > change are included) > > * which fields of object are default serialized. It's depend on > include_default_field but opposite to Tom Christie solution it's default > value is True so all fields (eventually specified in Meta.model_fields) are > present Field options: ~~ * There's a complication here that doesn't make sense to me. Following your syntax, the following would appear to be legal: class FieldA(Field): def serialize(…): def deserialize(…): class FieldB(Field): to = FieldA() def serialize(…): def deserialize(…): class FieldC(Field): to = FieldB(attribute=True) def serialize(…): def deserialize(…): i.e., if Field allows declaration style definitions, and Field can be *used* in declaration style definitions, then it's possible to define them in a nested fashion -- at which point, it isn't clear to me what is going to be output. It seems to me that "attribute" shouldn't be an option on a field declaration; it should either be something that's encompassed in a similar way to serialise/deserialize (i.e., either additional input/output from the serialise methods, or a parallel pair of methods), or the use of a Field as a declarative definition implies that it is of type attribute, and prevents the use of field types that themselves have attributes. Field methods: ~~~ * serialize_value(), deserialize_value(); this is bike shedding, but is there any reason to not use just "serialize() and deserialize()"? ObjectSerializer methods: * Why does ObjectSerializer have options at all? How can it be "meta" operating on a generic object? Consider -- if you pass in an instance of an object, you'll need to use obj.field_name to access fields; if you pass in a dictionary, you'll need to use obj['field_name']. And if you're given a generic object what's the list of default fields to serialize? Like I said last time, ObjectSerializer should be completely definition based. Look at Django's Form base class - it has no "meta" concept -- it's fully declaration based. Then there's ModelForm, which has a meta class; but the output of the ModelForm could be completely manually generated using a base Form. * I mentioned this last time -- why is class_name a meta option, rather than a method on the base class with a default implementation? Having it as an Meta attribute * I'm not wild about the way related_serializer seems to work, either. Again, like class_name, it seems like it should be a method, not an option. By making it an option, you're assuming that it will have a single obvious value, which definitely won't be true -- e.g., I have an object with relations to users, groups and permissions; I want to output users as a list of nested objects, permissions as a list of natural keys, and groups as a list of primary keys. * I'm not sure I see why include_default_fields is needed. Isn't this implied by the values for "fields" and "exclude"? i.e., if fields or exclude is defined, you're not including everything by default; otherwise you are. Why the additional setting? What's the interaction of include_default_fields with fields and exclude? * I don't understand what follow_object is trying to do. Isn't the issue here whether you use a serializer that just outputs a primary key, or an object that outputs field values? And if it's the latter, the sub-serializer determines how deep things go? ModelSerializer options: * I'm really not a fan of model_fields. This seems like a short cut that will make the implementation a whole lot more complex, and ultimately is much less explicit than just naming the fields that you want to serialize. > I'm aware that there will be lot of small issues but I believe that ideas > are good. I'm still optimistic, but there's still some fundamental issues here -- in particular, the existence of Meta on ObjectSerializer, and the way that attributes on XML tags are being handled. I don't think we've hit any blockers, but we need to get these sorted out before you start producing too much code. 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.
Fwd: a problem when PATH_INFO == SCRIPT_NAME
-- Forwarded message -- From: heng zhao Date: Mon, May 28, 2012 at 3:09 PM Subject: Re: a problem when PATH_INFO == SCRIPT_NAME To: django-us...@googlegroups.com I read the comment in https://code.djangoproject.com/ticket/8490, I found someone met the same problem 3years ago. why don't merge it into chunk? On Mon, May 28, 2012 at 2:56 PM, heng zhao wrote: > I'm using Django-1.4 and nginx with fastcgi mode. > when I use runserver mode everything goes well, But in nginx & > fastcgi ,whatever URL i visit, I get a response "/" > I trace the code and found that , when PATH_INFO == SCRIPT_NAME, > path_info has been set to u'/' (core/handlers/wsgi.py WSGIRequest > __init__) > so all the request redirect to / > for example , I visit /foo/, nginx send a fastcgi request with > PATH_INFO = ‘/foo/’ & SCRIPT_NAME = '/foo/' ,and Django redirect it > to ‘/’ > I change : > > if not path_info or path_info == script_name : > path_info = u'/' > to: > > if not path_info : > path_info = u'/' > if path_info == script_name: > script_name = u'' > > I found this problem has been reported and fixed in > https://code.djangoproject.com/ticket/8490, > but he treat it in a strange way, i'm still wondering it's a django bug or > not. > > excuse for my pool english :) -- 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.
