On Thu, Jun 2, 2011 at 8:58 AM, Luke Plant wrote:
> On 25/05/11 10:55, Anshuman Aggarwal wrote:
>> Hate to bump a thread, but any thoughts on the last proposal, Luke?
>
> My personal opinion is that the feature you proposed is not going to be
> correct enough of the time to warrant the duplication
On 25/05/11 10:55, Anshuman Aggarwal wrote:
> Hate to bump a thread, but any thoughts on the last proposal, Luke?
My personal opinion is that the feature you proposed is not going to be
correct enough of the time to warrant the duplication of code that it
would require to work.
Other core devs ma
Hate to bump a thread, but any thoughts on the last proposal, Luke?
On May 20, 4:13 pm, Anshuman Aggarwal wrote:
> Usage would be: list_display = (ff('model__field__fkfield',
> short_description='FK Field') but ideally, the short_description
> should be optional with the default logic being used
Usage would be: list_display = (ff('model__field__fkfield',
short_description='FK Field') but ideally, the short_description
should be optional with the default logic being used to fetch it out
of the FK.
We can change the __ to a . easily enough without any impact to
anything else.
On May 20, 4:
Hi Luke,
Thanks for a detailed reply. I have gone over your points carefully
and agree on most except a few key ones.
Based on your response:
- The question here is really how often is the guesswork right and
for how many different projects/use cases.
I have overseen Django used at more than a f
Hi Anshuman,
On 17/05/11 14:42, Anshuman Aggarwal wrote:
> list_display
> allows for callables and hence arbitrary names can be used which are
> similar to the syntax for foreign key fields.
> However, this problem exists for list_filter also: someone may define
> a
> field with the name class__f
I had seen it on trac (since I am following that ticket which has been
marked closed).
I got a mail to not open tickets closed by the core team and to take
up the discussion here. I am putting my reply to your comment here and
keeping the discussion on this thread for resolution.
list_display ope
On 17/05/11 12:20, Anshuman Aggarwal wrote:
> Since the parent__child syntax is being used for list filter, search
> fields and everywhere else, is there a reason why the list_display has
> to be sacrosanct?
Please see my response on Trac - I didn't notice you had brought this up
here, so posted t
I know this has been discussed (not sure to what depth) but callables
is not the solution. Please bear with me and help me (not force me) to
understand why what I am suggesting is wrong.
I did look in the list and have tried taking this discussion to the
ticket system. http://code.djangoproject.com
I know this has been discussed (not sure to what depth) but callables is not
the solution. Please bear with me and help me (not force me) to understand why
what I am suggesting is wrong.
I did look in the list and have tried taking this discussion to the ticket
system. http://code.djangoproject.
10 matches
Mail list logo
