Admin refactoring
Currently it is easy to change the template engine in a Django project, but if you change the ORM layer you lost the whole Admin thing, the very app that made Django so special. If we are talking about refactoring Admin code (not only html/css stuff), do you guys think it can be more decoupled from Django ORM? Is it possible to design some abstraction middleware to loose the bond between admin and Django ORM? Regards, -- Paulo -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@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: What The Enterprise wants from Django
On Jan 20, 3:15 pm, sago wrote: > I've had one very long and complex issue with a major client over > legacy databases with Composite Primary Keys (and other composite keys > more generally), an issue which has also come up in other contexts. > One of my smaller clients switched to a strange bastardization of > Django and SQLAlchemy because this was an issue. I understand the > history of #373 and why it is hard - just for disclosure. Composite primary keys is a major issue over here and we also ended up with a bastard of SQLAlchemy and Django. -- Paulo -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@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: Focusing on inlines this week
When dealing with FormSets, you can have them arbitrarily ordered because they accept a queryset argument. This is not true for inlines. The patch on Ticket #10263 make InLineFormSet consistent with FormSet and gives you complete freedom to filter/order inlines. I use it a lot and hope to see it accepted. Regards, -- Paulo --~--~-~--~~~---~--~~ 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: My case for #9006
On Mar 4, 1:53 pm, Alex Gaynor wrote:
> On Mar 4, 2009, at 8:29 AM, PauloS wrote:
>
> The only other obvious thing is that you should test:
> if queryset is not None
>
I will get there someday:
8<--
if queryset is None:
queryset = self.model._default_manager
qs = queryset.filter(**{self.fk.name: self.instance})
8<--
--~--~-~--~~~---~--~~
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: My case for #9006
On Mar 3, 1:55 pm, Alex Gaynor wrote:
> Looking at the patch IMO it should still dot he filter(**{self.fk.name:
> self.instance.pk}) even if you provide a queryset.
You are right again. Would you mind to look again and give any advice
(I'm as crude in python as in English).
Thanks!
--~--~-~--~~~---~--~~
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: My case for #9006
On Mar 2, 3:23 pm, Alex Gaynor wrote: > > I'm happy with this. Can I start writing a patch? > > He who has the patch has the power :) Atached to ticket #10263. With this change I was able to write a neat spreadshet-like interface with filtering and ordering. --~--~-~--~~~---~--~~ 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: My case for #9006
> > Firstly there is no reason for the _factory functions to take a queryset > argument, the queryset is specific to the formset instance, not the class > itself. Secondly in no way are 2 arguments more consistant than a single > queryset argument, because once we add filter someone will request exclude, > and now we have 3 arguments, then someone will have a custom manager and > they'll want a way to specify it, and it never ends. Simply making the > InlineModelFormset constructor consistant with the BaesModelFormset > constructor is the only sensible solution. > I'm happy with this. Can I start writing a patch? --~--~-~--~~~---~--~~ 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: My case for #9006
> Perhaps I'm not making myself clear, but it ALREADY take a queryset > argument: Alex, I know this, but last time I checked BaseInlineFormSet does not. Same case with *formset_factory helper functions. It's clear why not, it's because these helper functions are supposed to build the queryset for you based in the arguments you feed. That is also why I think a filter and an order_by arguments instead of a single queryset argument makes more sense - it fits better to the style these functions were coded. Note that the later statement is not only based on my personal taste, its also based on the fact that 2 arguments would lead to a much smaller patch than the single queryset argument idea. Add two arguments (filter and order_by) or a single queryset argument to these functions and derived objects would make them more generic while exposing the functionality already in BaseModelFormSet. I'm sorry if I failed to communicate well, English is not my native idiom. Regards, -- Paulo --~--~-~--~~~---~--~~ 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: My case for #9006
InlineFormSet is perfect to build spreadsheet-like grid interfaces, but for a good user experience the form elements need to have consistent order across GET-after-POST cycles. Currently this happens BY ACCIDENT in most SGBD backends, and I think relying on accidents is bad programming style. The "set a default ordering on a model" solution works, but passing a queryset argument would be nice, so you can filter and reorder InlineFormSets at will in the server side instead of resorting to javascript tricks on the client side. I think that a Q object and an order_by optional parameters make more sense in inlineformset_factory, but my question is: if I modify formset_factory, modelformset_factory, inlineformset_factory and BaseInlineFormSet to take an optional queryset argument, would it be acceptable? TIA, -- Paulo --~--~-~--~~~---~--~~ 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: My case for #9006
On Feb 27, 5:28 pm, Collin Grady wrote: > One could also set a default ordering on a model and have a consistent > order everywhere :) This way you have to pay the ORDER BY price for every query? --~--~-~--~~~---~--~~ 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: My case for #9006
Hi, I have a related patch (#10263). I have an application where I rendered my inline forms like an spreadsheet, the effect when the user saves the form and the row order changes is very unpleasant. This bug does not show up often because most databases other than Postgres return unordered queries in an arbitrary order that remains consistent over reasonable timeframes. This behavior is not guaranteed by the standards. The proposed patch solves the issue with InlineFormSets under Postgres, does nothing "under the hood" and is very small and contained. As a plus, selecting the order of the inline formset is very useful. Alex marked this ticket as "Design decision needed" and asked about passing a queryset already ordered as parameter; while this would give greater flexibility, right now I'm more concerned with fixing the bug than with any collateral enhancement. If Alex could make the point for a broader approach I would be happy to provide another patch. Regards, -- Paulo Scardine --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
patch: order_by parameter for inline_modelformset
Hi all, At inlineformset_factory and BaseInlineFormSet? constructor there is no option to specify order_by criteria for the resulting queryset. The record order at the rendered formset will depend on the order returned by the database layer; notably PostgreSQL may change this order after every update. When using PRG (Post/Redirect/Get) the result order is often changed causing an unpleasant effect that may confuse users. I sent a patch as ticket #10263. What do you think? Regards, -- Paulo --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
