Admin refactoring

2010-02-10 Thread PauloS
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

2010-01-22 Thread PauloS
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

2009-06-15 Thread PauloS

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

2009-03-05 Thread PauloS

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

2009-03-04 Thread PauloS

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

2009-03-03 Thread PauloS

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

2009-03-02 Thread PauloS

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

2009-03-01 Thread PauloS

> 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

2009-02-28 Thread PauloS

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

2009-02-28 Thread PauloS

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

2009-02-27 Thread PauloS

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

2009-02-14 Thread PauloS

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