Re: Ticket 15754 https://code.djangoproject.com/ticket/15754

[Marcob]

On Monday, August 6, 2012 4:49:12 PM UTC+2, Marcob wrote:
>
> I'd really like to see it in Django 1.5 trunk, and it looks like the only 
> blocking reason are missing tests.
>

Wow, thanks a lot Alex Gaynor! :-)

https://code.djangoproject.com/ticket/15754#comment:7

Ciao.
Marco.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/n-8-6N3hYM0J.
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.

Ticket 15754 https://code.djangoproject.com/ticket/15754

[Marcob]

In previous Django major releases I used to apply lots of patches (and 
suffer some major headaches :-).
After 1.4 only this little one-liner is left: 
https://code.djangoproject.com/ticket/15754
Leaving it out is impossible for me, as the user experience with some 
custom forms can be painfully slow.
I'd really like to see it in Django 1.5 trunk, and it looks like the only 
blocking reason are missing tests.

Since this is a perfomance improvement, would testing for regressions be 
enough?

Ciao.
Marco.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/upJsYZW15tkJ.
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.

Ticket 16317 https://code.djangoproject.com/ticket/16317

[Marcob]

The ticket 16317 has a very nice 4 months old patch (it's has a two
lines fix, remainder are just test fixes).
It was marked for 1.3 version but now it's better to change it to 1.4
version.
As I really hate to patch django I think my only solution is "to
lobby" this ticket here :-)
Is there anything else I can do?
Ciao.
Marco.
P.S. Someone said the putting your email in cc in a ticket isn't the
way to go.

-- 
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: Django 1.4 roadmap

[Marcob]

On Nov 28, 9:33 pm, Adrian Holovaty  wrote:
> On Mon, Nov 28, 2011 at 6:40 AM, Russell Keith-Magee
>
>  wrote:
> > So -- what we need is for someone in the core team who is able to find
> > the resources in their schedule to commit to shepherding a release.
> > Speaking for myself, I know that this almost certainly isn't going to
> > be me -- my work life has got a lot more complicated since the 1.3
> > release.
>
> And that someone will be me. See my post 
> here:http://www.holovaty.com/writing/back-to-django/

Wow! Great news!

If only I had been shut up a week more ;-)

Ciao.
Marco.

--
http://beri.it/ - Un blog
http://beri.it/i-miei-libri/ - Qualche libro

-- 
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: Django 1.4 roadmap

[Marcob]

On Nov 26, 1:19 pm, Aymeric Augustin
<aymeric.augus...@polytechnique.org> wrote:
> On 24 nov. 2011, at 16:53, Marcob wrote:
>
> > I realize that this is a volunteer-based project, but I was wondering
> > if you have any updates regarding the wiki page for the 1.4 roadmap?
> > (https://code.djangoproject.com/wiki/Version1.4Roadmap)
>
> Hi Marco,
>
> Unlike previous releases, Django 1.4 didn't get a formal roadmap. So it will 
> contain the features currently listed in the release notes [1], plus those 
> that will be added before the release.

Aymeric, thanks a lot!

Btw this is ok for "what", but for just a really rough idea of "when"
a roadmap would be great.

You need a date to be late :-)

Ciao.
Marco.

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

Django 1.4 roadmap

[Marcob]

Dear Django Core Developers,
first and foremost, thank you for Django, which is a wonderful
project.
I realize that this is a volunteer-based project, but I was wondering
if you have any updates regarding the wiki page for the 1.4 roadmap?
(https://code.djangoproject.com/wiki/Version1.4Roadmap)
I'm big on providing feedback as I feel it contributes to the health
of valuable projects like Django.

Thank you in advance.

Ciao.
Marco.

--
http://beri.it/ - Un blog
http://beri.it/i-miei-libri/ - Qualche libro

-- 
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: Kilobyte or Kibibite

[Marcob]

On 12 Gen, 14:26, Russell Keith-Magee  wrote:

> You won't see me disagreeing. +1 to keeping as is.
> Until I start seeing kibibyte being used in the New York Times, or the
> prefered usage in the Chicago Manual of Style, the kibibyte is little
> more to me than an intriguing expression of pedantry. Yes, the
> existing usage is confusing and ambiguous. We don't fix that by
> picking new and relatively unknown terminology.

Lol! Now not only my wife, also Django community call me a
pedant... :-)

Jokes apart, I think you both are right: kB/MB/GB are a universal unit
and it's better to keep them.

Ciao.
Marco.

-- 
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: rethinking raw_id_fields

[Marcob]

On 4 Ott, 04:09, Chuck Harmston  wrote:
> An Ajax admin solution (of the autocomplete sort, which I presume is what
> you're proposing) does not have the same use case for raw_id_fields. It's
> based on the assumption that the user knows the value of the unicode
> representation of the object. It does not allow for discovery like the
> raw_id_fields popup does: no filtering, no sorting, no searching, and no
> browsing. I am a strong -1 this.

Me too. For the same exact reasons.

I usually tweak the link to open a popup already filtered and such
things.

Ciao.
Marco.

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

#6903 -- Go back to old change_list view after hitting save

[Marcob]

I think that #6903 ticket http://code.djangoproject.com/ticket/6903
(together with http://code.djangoproject.com/ticket/12241) should be
considered to be in 1.3 release.
Every single person I know that use admin without this patch asks for
this functionality.
On 3/23/2009 Jacob said: This has gone around quite a bit, but it's
still not quite perfect. It's really a hard problem, unfortunately,
and we're out of time to put it in 1.1.
On 2/23/2010 ubernostrum said: 1.2 is feature-frozen, moving this
feature request off the milestone.
I understand that release 1.3 is to be devoted to this kind of ticket.
Am I right?
Ciao.
Marco.

-- 
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: rethinking raw_id_fields

[Marcob]

On 30 Set, 07:34, "subs...@gmail.com"  wrote:
> Hello all,
> I was browsing the tickets and saw a few of them nagging about some
> restrictions to raw_id_fields.

Since my first Django installation, a couple of years ago, I fixed and
used this patch:
http://code.djangoproject.com/ticket/7028

I see that mtrs wrote an improved version.
I also see that at each new Django release a fixed version comes up
after few days (if not few hours).
I think it is a huge improvement in user experience and I never fully
understood why it always missed each django release since 1.0.
Now I see that another improved patch comes up concerning also M2M:
http://code.djangoproject.com/ticket/13221

Well, M2M and raw_id_fields are a big player in wonderful admin
contrib with a poor interface: why do not improve them?

Ciao.
Marco.

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

How to "lobby" for a ticket to be in 1.3?

[Marcob]

I see a huge list of tickets that shoud be in 1.3 release:
http://code.djangoproject.com/query?status=new=assigned=reopened=1.3

Within them I didn't found some that are, imho, a must for every
Django installation I did in the last two years:

Better raw_id_fields feedback in newform-admins branc
http://code.djangoproject.com/ticket/7028

Go back to old change_list view after hitting save
http://code.djangoproject.com/ticket/6903

At each new django release it's a pita to adapt these patches.

How can I help to make these two tickets in the 1.3 milestone?

Ciao.
Marco.

-- 
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: Admin sloooow with postgresql and a 160k record table

[Marcob]

On 27 Mag, 22:58, Alex Gaynor  wrote:

> FWIW Jacob was wrong, there is another tiket, but I can't find out now
> (yay trac search ;)), so don't be offended if I close your ticket.

Alex, no offense at all :-)

Ah, you don't be offended but I already closed it as a dupe of 8408
(thanks to Jeremy).

Ciao.
Marco.

-- 
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: Admin sloooow with postgresql and a 160k record table

[Marcob]

On May 27, 11:13 pm, Jacob Kaplan-Moss  wrote:

> I thought there was already a ticket open for this, but I can't seem
> to find one. Can you open a ticket so that we don't forget?

To posterity: http://code.djangoproject.com/ticket/13643

:-)

Ciao.
Marco.

-- 
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: Admin sloooow with postgresql and a 160k record table

[Marcob]

On 27 Mag, 23:13, Jacob Kaplan-Moss  wrote:

> I thought there was already a ticket open for this, but I can't seem
> to find one. Can you open a ticket so that we don't forget?

Sure. Meanwhile I solved my problem with LazyPaginator and a bit of
monkey patching.

I'll post my ugly code within the ticket.

Ciao.
Marco.
P.S. You must be right about my db. I'll check it with my fellow dba.

--
http://thinkcode.tv/gratis - Capire in 15 minuti cosa può fare Python
http://stacktrace.it - Aperiodico di resistenza informatica
http://python.thinkcode.tv - Videocorso di Python
http://beri.it - Blog di una testina di vitello

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

Admin sloooow with postgresql and a 160k record table

[Marcob]

With postgresql count(*) is a slow operation because it forces a full
table scan:
http://groups.google.it/group/pgsql.performance/browse_thread/thread/6f94b296019a0e1e/d2d6ca3018f51cb3?hl=it=UTF-8=postgresql+django+slow+count%28*%29#d2d6ca3018f51cb3

I've a table with only 160.000 records (but a record has many fields)
and opening its admin page takes 55 seconds. A select count(*) takes
50 seconds, so I know it's all a db problem.

I think that it could be a nice admin option to prevent full
pagination. I prefer to have only "first - previous - next" links
instead of waiting one minute to have "1.2.3.4...3241" links.

I can't think of another workaround and you?

Ciao.
Marco.

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

Does Python 2.6.5 broke Django 1.1.1 Client Test?

[Marcob]

It's about 4 hours I'm trying to find the real culprit...
To narrow the problem I create the simplest admin test:
from django.test import TestCase
class AdminViewBasicTest(TestCase):
def testAdmin(self):
from django.contrib.auth.models import User
user = User.objects.create_user('test', 't...@test.com',
'test')
user.is_staff = True
user.save()
self.client.login(username='test', password='test')
response = self.client.get('/admin/')
self.failUnlessEqual(response.template[0].name, 'admin/
index.html')

With Python 2.5:
.
 
--
Ran 1 test in 0.110s

OK
Destroying test database...

Same project, environment, everything else, but with Python 2.6.5 (to
play safe I deleted *.pyc):
F
 
==
FAIL: testAdmin (project.prova.tests.AdminViewBasicTest)
 
--
Traceback (most recent call last):
  File "C:\work\test\project\prova\tests.py", line 13, in
testAdmin
self.failUnlessEqual(response.template[0].name, 'admin/
index.html')
AssertionError: 'admin/login.html' != 'admin/index.html'

 
--
Ran 1 test in 0.156s

FAILED (failures=1)
Destroying test database...

It seems that django client test does not keep the session, recreating
it each time.

Django version:
>>> import django
>>> django.VERSION
(1, 1, 1, 'final', 0)

Python versions:
Python 2.5.4 (r254:67916, Dec 23 2008, 15:10:54) [MSC v.1310 32
bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more
information.
>>>

Python 2.6.5 (r265:79096, Mar 19 2010, 21:48:26) [MSC v.1500 32
bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more
information.
>>>

Trying with Django 1.1.2 Alpha the problem goes away.

Please, does anybody know which patch I need to apply to 1.1.1 to fix
this strange problem?
Obviously (and unfortunately) I can't install 1.1.2 Alpha.

Ciao.
Marco.

-- 
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: generic_hierarchy proposal

[Marcob]

On 16 Ott, 15:08, Marcob <marcob...@gmail.com> wrote:

> P.S. Perhaps you can already obtain this with a custom changelist_form
> and a custom date_hierarchy block, moreover I'd like to have a proper
> option.

Obviuosly instead of changelist_form I meaned change_list_template.

Ciao.
Marco.

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

generic_hierarchy proposal

[Marcob]

Often I got this remark about date_hierarchy "Wonderful! May we have
this also with this hierarchical field on that table?".
And my answer is invariably: "Unfortunately no: it works only with
date and/or time field".

I would like a generic_hierarchy option in admin where you can insert
every kind of field, provided that you have a
_hierarchy method in your model that mimic
date_hierarchy in django.contrib.admin.templatetags.admin_list module.

Ciao.
Marco.
P.S. Perhaps you can already obtain this with a custom changelist_form
and a custom date_hierarchy block, moreover I'd like to have a proper
option.

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

Admin: TemplateSyntax error if I input a manual (and not existent) value in a FK in raw_id_fields

[Marcob]

I saw these tickets:

http://code.djangoproject.com/ticket/9484 (closed: duplicate)
Admin, raw_id_fields, not int value
Msg: #8746 covers this.

http://code.djangoproject.com/ticket/8746 (closed: fixed)
Data entered in raw_id_fields needs better checking
Msg: Please file a new ticket for this

http://code.djangoproject.com/ticket/11465 (closed: duplicate)
Broken representation of nonexisting objects for raw_id_fields
Msg: Duplicate of another ticket that reports this exact same thing
(and who's number I can't recall).

It seems a catch-22 to me.

Did I miss another "living" ticket? (it wouldn't be the first
time ;-) ).

Ciao.
Marco.

--~--~-~--~~~---~--~~
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: Strange behaviour with exclude / filter and a nullable FK

[Marcob]

On Sep 15, 8:05 pm, Alex Gaynor  wrote:

> This has already been filed as a bug in Django's ticket 
> tracker:http://code.djangoproject.com/ticket/10790.  In the future please try
> searching the tracker before filing a bug.

Thanks Alex, but:
1) I searched the trac
2) I didn't find the bug
3) So before filing a dupe I wrote here

Was I wrong?

Ciao.
Marco.

--~--~-~--~~~---~--~~
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: Strange behaviour with exclude / filter and a nullable FK

[Marcob]

On 15 Set, 19:32, Marcob <marcob...@gmail.com> wrote:

>     LEFT OUTER JOIN "auth_user" ON ("ticket_ticket"."assigned_id" =

I translated from italian, obviously assigned_id should be
assigned_to_id.

Sorry.

Ciao.
Marco.

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

Can't use partial date format in settings.py

[Marcob]

Reading the following documentation I deduced that partial date
settings (used in date_hierarchy filter) could be set in settings.py:
http://docs.djangoproject.com/en/dev/ref/settings/#year-month-format
http://docs.djangoproject.com/en/dev/ref/settings/#month-day-format

Unfortunately the localization comes before settings as you can see
 :

from django.conf import settings
year_month_format = ugettext('YEAR_MONTH_FORMAT')
month_day_format = ugettext('MONTH_DAY_FORMAT')
if year_month_format == 'YEAR_MONTH_FORMAT':
year_month_format = settings.YEAR_MONTH_FORMAT
if month_day_format == 'MONTH_DAY_FORMAT':
month_day_format = settings.MONTH_DAY_FORMAT
return year_month_format, month_day_format

I solved with an ugly monkeypatching in one of my admin.py:
from django.utils import translation
from django.utils.translation import trans_null
translation.get_date_formats = trans_null.get_date_formats
translation.get_partial_date_formats =
trans_null.get_partial_date_formats

I think the documentation should state this clearly. Or at least a
special setting could tell Django if settings.py date formats has to
be used with priority.

Ciao.
Marco.

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

Strange behaviour with exclude / filter and a nullable FK

[Marcob]

I have a model with a FK on User table:
from django.contrib.auth.models import User

class Ticket(models.Model):
assigned_to = models.ForeignKey(User, null=True, blank=True)
...

Then I have these two querysets:
>>> q1 = Ticket.objects.filter(assigned_to__isnull=True)
>>> q2 = Ticket.objects.exclude(assigned_to__isnull=False)

I thought they shoud generate the same SQL query as they are
conceptually the same thing.

But if I print their query I got:
>>> print q1.query
SELECT ...
FROM "ticket_ticket"
LEFT OUTER JOIN "auth_user" ON ("ticket_ticket"."assigned_id" =
"auth_user"."id")
WHERE "auth_user"."id" IS NULL

>>> print q2.query
SELECT ...
FROM "ticket_ticket"
WHERE NOT ("ticket_ticket"."assigned_id" IS NOT NULL)

The exclude version is much more efficient.

Is this by design?

Ciao.
Marco.

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

Queryset-refactor merge in newforms-admin branch broke date_hierarchy filter

[Marcob]

I found that after queryset-merge in newforms-admin date_hierarchy
filter doesn't work anymore: years and month are repeated.
To fix it I wrote this quick hack in django/contrib/admin/templatetags/
admin_list.py:

Line 240:
-days = cl.query_set.filter(**{year_field: year_lookup,
month_field: month_lookup}).dates(field_name, 'day')
+days = list(set(cl.query_set.filter(**{year_field:
year_lookup, month_field: month_lookup}).dates(field_name, 'day')))

Line 252:
-months = cl.query_set.filter(**{year_field:
year_lookup}).dates(field_name, 'month')
+months = list(set(cl.query_set.filter(**{year_field:
year_lookup}).dates(field_name, 'month')))

Line 266:
-years = cl.query_set.dates(field_name, 'year')
+years = list(set(cl.query_set.dates(field_name, 'year')))

I don't know if this is the right way.

Ciao.
Marco.

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Some of newforms-admin branch files have DOS mode line endings!!!

[Marcob]

On 19 Apr, 13:37, Marcob <[EMAIL PROTECTED]> wrote:
> I just exported newforms-admin branch e try to apply this 
> patchhttp://code.djangoproject.com/ticket/7028
> It fails on django/contrib/admin/templatetags/admin_list.py because it
> is in DOS mode!!!
> Why on earth?

Gotcha!

Some of the files (but not all of them) have this property:
  Property svn:eol-style set to native

For example this one:
http://code.djangoproject.com/browser/django/branches/newforms-admin/django/contrib/admin/templatetags/admin_list.py

I'm working via putty on a Unix server but from a Windows pc. I
exported the branch using tortoisesvn and for the files with that
property tortoisesvn used eol style of my pc (dreaded \r\n).

BTW it would be much better to have that property consistent on every
files not just some.

Ciao.
Marco.
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Some of newforms-admin branch files have DOS mode line endings!!!

[Marcob]

I just exported newforms-admin branch e try to apply this patch
http://code.djangoproject.com/ticket/7028
It fails on django/contrib/admin/templatetags/admin_list.py because it
is in DOS mode!!!

Why on earth?

Ciao.
Marco.
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Better raw-id-fields user feedback (newforms-admin branch)

[Marcob]

On 16 Apr, 02:24, Marcob <[EMAIL PROTECTED]> wrote:
> http://code.djangoproject.com/ticket/7028

I just modifed this patch and added a new one for django test suite
(one liner!):
- improved-raw-id-admin-feedback-fixed-regression-test.diff (3.7 kB)
- tests-fix-for-improved-raw-id-admin-patch.patch (1.2 kB)

Now all django tests run fine:

*[django tests output starts here]*
[EMAIL PROTECTED]:~/test/lib/tests$ python runtests.py
--
Ran 252 tests in 87.861s

OK
[EMAIL PROTECTED]:~/test/lib/tests$
*[django tests output stops here]*

Ciao.
Marco.
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Better raw-id-fields user feedback (newforms-admin branch)

[Marcob]

http://code.djangoproject.com/ticket/7028

This little patch improves a lot the user feedback experience during
raw-id-fields selection.

When a big table hasn't a clear id (for example just a numeric id) and
an user chooses an item from the popup window,  the item description
appears only after saving the record (and this is wrong as user would
like to see it *before* saving not after).
This is a real pita for users (at least for mine) as they can't be
sure to have picked up the right record.

Hope you find this useful.
Ciao.
Marco.
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---