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 fro
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 basta
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
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:
que
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!
--~--~--
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.
--~--~-~--~~
>
> 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
> 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
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
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 subs
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 queri
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 u
12 matches
Mail list logo
