Re: Newforms styling suggestion
On Thu, 15 Feb 2007 20:58:27 -0500, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > > On 2/15/07, Brian Morton <[EMAIL PROTECTED]> wrote: >> I don't know if this has been suggested yet, but has anyone considered >> an >> enhancement to newforms to optionally allow a field to have a different >> class if it has an error? It would be helpful for things like making >> error >> fields highlighted red, etc. Just a thought. > > Hey Brian, > > I think we might have discussed this before, but the discussion > fizzled out. What would you want to style -- the form HTML tag itself? > The ? The table row (in case of as_table())? > > Adrian > I'd realy like to see this as well. I suppose either way would work, but which is used needs to be consistent across all as_methods. Either isn't always the containing block element or its always the label or it's always the form element. The more I think about it, different people will want to apply the style to one of any of those three possibilities. The only way to be able to do so consistently is with the containing block. Oh, and rather than "a different class" it should add an **additional** class. We don't want to remove any classes that already exist. -- Waylan Limberg [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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: Enhancing MergeDict
Thanks Michael. I created a ticket (#3508) and submitted a patch. Based on the triage policy, it seems "ready for checkin"... but it doesn't seem kosher for me to decide that on my own :) -jc On 2/14/2007, "Michael Radziej" <[EMAIL PROTECTED]> wrote: > >Hi, > >John Calixto: >> I have an almost trivial (although it was helpful to me) enhancement for >> django.utils.datastructures.MergeDict. It basically adds __str__ and >> __repr__ methods so that you can see more meaningful output than just >> the standard "" string. >> >> Here's my diff: >> >> === django/utils/datastructures.py >> == >> --- django/utils/datastructures.py (revision 15931) >> +++ django/utils/datastructures.py (local) >> @@ -43,6 +43,13 @@ >> return True >> return False >> >> +def __str__(self): >> +return str(dict(self.items())) >> + >> +def __repr__(self): >> +dictreprs = ', '.join(repr(d) for d in self.dicts) >> +return '%s(%s)' % (self.__class__.__name__, dictreprs) >> + > >Nice! > > >> On another note, I'm using svk to mirror django svn. Is it possible to >> submit patches made with svk diff rather than svn diff? > >Should be no problem. > >Michael > > >> --~--~-~--~~~---~--~~ 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: Newforms styling suggestion
On 2/15/07, Brian Morton <[EMAIL PROTECTED]> wrote: > I don't know if this has been suggested yet, but has anyone considered an > enhancement to newforms to optionally allow a field to have a different > class if it has an error? It would be helpful for things like making error > fields highlighted red, etc. Just a thought. Hey Brian, I think we might have discussed this before, but the discussion fizzled out. What would you want to style -- the form HTML tag itself? The ? The table row (in case of as_table())? Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Newforms styling suggestion
I don't know if this has been suggested yet, but has anyone considered an enhancement to newforms to optionally allow a field to have a different class if it has an error? It would be helpful for things like making error fields highlighted red, etc. Just a thought. --~--~-~--~~~---~--~~ 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: Bug introduced at changeset 4500
On Thu, 2007-02-15 at 06:02 -0800, Rudolph wrote: > Hi, > > I think I found a bug introduced in changeset 4500 (http:// > code.djangoproject.com/changeset/4500). When a min_num_in_admin is > specified without a num_in_admin, the "add" view in the admin > interface gives an exception (and possibly the change view as wel, I > didn't test that). Does anyone else experience this since changeset > 4500? I did some testing before committing that change, but I may have missed this case. I'll have a look at it when I get a chance this morning and fix it if I can track down the problem. Thanks for the heads-up and apologies for costing you some time. Regards, Malcolm --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
newforms: Dynamic forms using JavaScript
Hello, I created a small library called "dynamicforms" (based on newforms) that allows you to edit multiple instances of an object simultaneously. It also provides a JavaScript link that allows you to add another instance of the object without having to reload the page. Take a look at it: http://eggdrop.ch/blog/2007/02/15/django-dynamicforms/ Maybe this could be improved and integrated into Django (see also ticket #3433)? Comments are appreciated. tom --~--~-~--~~~---~--~~ 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: unicode issues in multiple tickets (#952, #1356, #3370) and thread about Euro sign in django-users
Adrian Holovaty wrote: > Hi Ivan, > > Could you explain again why you think newforms should output > clean_data as bytestrings rather than Unicode strings? I don't think so :-). Quite the opposite. I think it's good that you made newforms in unicode since it effectively gives a start to unicodification and lets us test it early. But there is one issue that is very annoying: when newform saves data to a model instance it fills it with unicode. This creates some issues: - part of the time an object stores bytes (when loaded from db), part of the time -- unicode (when updated from newforms) - __str__s return unicode instead of str - some backends versions can't handle unicode and try to implicitly str() in ascii it with UnicodeEncodeError's The patch that I'm advocating for here does one little thing: when a newform saves an instance it converts unicode into DEFAULT_CHARSET. In other words it makes newforms do decode/encode on both their boundaries: not only on the side facing the web (POSTs, templates) but also on db side. > Are you suggesting that we would convert newforms > clean_data *back* to being Unicode *after* we convert the rest of the > framework to be Unicode-aware? No, clean_data will remain in unicode (and for good). Encoding happens only when clean_data is actually applied to a model instance. > I apologize in advance if you've already brought this up and explained > it. Just trying to understand your thinking here. Yeah, I understand that this thread is rather long :-) --~--~-~--~~~---~--~~ 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: unicode issues in multiple tickets (#952, #1356, #3370) and thread about Euro sign in django-users
Adrian Holovaty: > On 2/15/07, Ivan Sagalaev <[EMAIL PROTECTED]> wrote: >> I tried to show that it leaves out only two things: >> >> - if DEFAULT_CHARSET is different than DB charset it won't work (but >> it's a weird situation, most legacy systems have one legacy encoding for >> both) >> >> - it doesn't help if unicode is actually put into models or in raw SQL >> manually but this bug was never about it anyway and won't break anything >> since it fixes newforms, not backends > > Hi Ivan, > > Could you explain again why you think newforms should output > clean_data as bytestrings rather than Unicode strings? The current situation is this: * newforms puts unicode into objects that used to receive only UTF-8 encoded bytestrings * the models (and other parts) only work with bytestrings (or as long as the unicode contains only characters from ASCII) * it is hard to convert all the rest of Django to be able to deal with unicode and bytestring at the same time, and it seems that this has been postponed until after 1.0. Ivan proposes a fix that tries to convert unicode to bytestrings at the boundary of newforms by encoding unicode to bytestrings in clean_data. (I have not checked whether this resolves all or at least a big part of the problem, and I don't have a position about this, yet.) It looks like a step backwards, but as long is we don't try to make everything unicode compatible at the same time, we need to encode the unicode strings at some boundary or the other. Is clean_data the right point for this? Michael -- noris network AG - Deutschherrnstraße 15-19 - D-90429 Nürnberg - Tel +49-911-9352-0 - Fax +49-911-9352-100 http://www.noris.de - The IT-Outsourcing Company --~--~-~--~~~---~--~~ 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: unicode issues in multiple tickets (#952, #1356, #3370) and thread about Euro sign in django-users
On 2/15/07, Ivan Sagalaev <[EMAIL PROTECTED]> wrote: > I tried to show that it leaves out only two things: > > - if DEFAULT_CHARSET is different than DB charset it won't work (but > it's a weird situation, most legacy systems have one legacy encoding for > both) > > - it doesn't help if unicode is actually put into models or in raw SQL > manually but this bug was never about it anyway and won't break anything > since it fixes newforms, not backends Hi Ivan, Could you explain again why you think newforms should output clean_data as bytestrings rather than Unicode strings? If I understand your argument correctly, you're saying newforms should be rolled back to bytestrings because the rest of the framework isn't Unicode-aware yet. Are you suggesting that we would convert newforms clean_data *back* to being Unicode *after* we convert the rest of the framework to be Unicode-aware? I apologize in advance if you've already brought this up and explained it. Just trying to understand your thinking here. Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ 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: unicode issues in multiple tickets (#952, #1356, #3370) and thread about Euro sign in django-users
Michael Radziej wrote: > (meeting postponed ...) Nice :-) > You're right, sorry. I was in a different ticket and somehow thought > it was the same. > > Yes, #3370 looks interesting and is a different solution. I'm not > sure whether it deals with all the issues of this thread. I tried to show that it leaves out only two things: - if DEFAULT_CHARSET is different than DB charset it won't work (but it's a weird situation, most legacy systems have one legacy encoding for both) - it doesn't help if unicode is actually put into models or in raw SQL manually but this bug was never about it anyway and won't break anything since it fixes newforms, not backends --~--~-~--~~~---~--~~ 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: unicode issues in multiple tickets (#952, #1356, #3370) and thread about Euro sign in django-users
Ivan Sagalaev: > Michael Radziej wrote: >> Ivan Sagalaev: >> >>> Michael, the ticket http://code.djangoproject.com/ticket/3370 just got a >>> patch that does a) and it's really small. It's not as full as having b) >>> and d) but I think they are really a corner cases: b) for different >>> encodings in DB and in web, d) for handling unicode input to DB backend >>> *without* newforms. >>> >>> In other words I think that patch is just right for current situation >>> because it fixes the bug for people trying to use newforms now. I'm +1 >>> on just committing it as is. >> I'm not sure if the fix is on the right level. StrAndUnicode is used >> in a lot of places. Is it sure that it won't put xmlcharref-encoded >> data into the database? I only had a very quick look on it (and I >> need to go to a meeting now). > > Uhm... Are we talking about the same patch? This is it: > http://code.djangoproject.com/attachment/ticket/3370/models.py.diff > > It doesn't mention StrAndUnicode at all. (meeting postponed ...) You're right, sorry. I was in a different ticket and somehow thought it was the same. Yes, #3370 looks interesting and is a different solution. I'm not sure whether it deals with all the issues of this thread. Michael -- noris network AG - Deutschherrnstraße 15-19 - D-90429 Nürnberg - Tel +49-911-9352-0 - Fax +49-911-9352-100 http://www.noris.de - The IT-Outsourcing Company --~--~-~--~~~---~--~~ 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: unicode issues in multiple tickets (#952, #1356, #3370) and thread about Euro sign in django-users
Michael Radziej wrote: > Ivan Sagalaev: > >> Michael, the ticket http://code.djangoproject.com/ticket/3370 just got a >> patch that does a) and it's really small. It's not as full as having b) >> and d) but I think they are really a corner cases: b) for different >> encodings in DB and in web, d) for handling unicode input to DB backend >> *without* newforms. >> >> In other words I think that patch is just right for current situation >> because it fixes the bug for people trying to use newforms now. I'm +1 >> on just committing it as is. > > I'm not sure if the fix is on the right level. StrAndUnicode is used > in a lot of places. Is it sure that it won't put xmlcharref-encoded > data into the database? I only had a very quick look on it (and I > need to go to a meeting now). Uhm... Are we talking about the same patch? This is it: http://code.djangoproject.com/attachment/ticket/3370/models.py.diff It doesn't mention StrAndUnicode at all. --~--~-~--~~~---~--~~ 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: unicode issues in multiple tickets (#952, #1356, #3370) and thread about Euro sign in django-users
Ivan Sagalaev: > Michael, the ticket http://code.djangoproject.com/ticket/3370 just got a > patch that does a) and it's really small. It's not as full as having b) > and d) but I think they are really a corner cases: b) for different > encodings in DB and in web, d) for handling unicode input to DB backend > *without* newforms. > > In other words I think that patch is just right for current situation > because it fixes the bug for people trying to use newforms now. I'm +1 > on just committing it as is. I'm not sure if the fix is on the right level. StrAndUnicode is used in a lot of places. Is it sure that it won't put xmlcharref-encoded data into the database? I only had a very quick look on it (and I need to go to a meeting now). Michael -- noris network AG - Deutschherrnstraße 15-19 - D-90429 Nürnberg - Tel +49-911-9352-0 - Fax +49-911-9352-100 http://www.noris.de - The IT-Outsourcing Company --~--~-~--~~~---~--~~ 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: unicode issues in multiple tickets (#952, #1356, #3370) and thread about Euro sign in django-users
Michael Radziej wrote: > A few days ago, I wrote: >> I see three ways to fix the problem in #3370: >> >> a) newforms stops passing unicode strings to the Database API and uses >> bytestrings. >> >> b) the database wrapper in Django sets connection.charset (but needs to >> translate the charset name since the databases don't understand all >> charset name variants, see ticket #952 here). This is the approach of >> the patches in tickets #1356 and #3370. >> >> c) the database wrapper in Djago must check whether it gets unicode. In >> this case, it needs to encode it into a bytestring. > > I now see a fourth way that would resolve #952 at the same time: > > d) make the database wrapper accept both unicode and bytestrings in > the models, but always pass unicode strings to the database backend. Michael, the ticket http://code.djangoproject.com/ticket/3370 just got a patch that does a) and it's really small. It's not as full as having b) and d) but I think they are really a corner cases: b) for different encodings in DB and in web, d) for handling unicode input to DB backend *without* newforms. In other words I think that patch is just right for current situation because it fixes the bug for people trying to use newforms now. I'm +1 on just committing it as is. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Bug introduced at changeset 4500
Hi, I think I found a bug introduced in changeset 4500 (http:// code.djangoproject.com/changeset/4500). When a min_num_in_admin is specified without a num_in_admin, the "add" view in the admin interface gives an exception (and possibly the change view as wel, I didn't test that). Does anyone else experience this since changeset 4500? Rudolph --~--~-~--~~~---~--~~ 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: Possible improvement to model API
On Feb 10, 7:38 am, David Abrahams <[EMAIL PROTECTED]> wrote: > Trying to take the temperature here: is there any sympathy here for > the idea of adding it to contrib/, or is the whole idea simply > anathema to this group? For me, the idea looks great. I will not hold my breath waiting it to be implemented in 0.97 or even 1.5, but your way is definitely more expressive (and I suspect it will be cheaper for the CPU as it gives more work to the compiler leaving less for the runtime). Do you plan to develop an extension yourself? --~--~-~--~~~---~--~~ 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: Possible improvement to model API
On Feb 10, 5:38 am, David Abrahams <[EMAIL PROTECTED]> wrote: > "James Bennett" <[EMAIL PROTECTED]> > writes: > Can't argue with your subjective opinion. But I suggest you ask some > newbies what they think. Also, "prettiness" is not really one of my > goals, though I believe that generally comes along with > expressiveness. I can't really claim to be a complete newbie, as I've spent a couple of days playing with Django, but I didn't find any problems at all with the __gte syntax. It might not be the most intuitive system, but after you've learned it, it makes sense. It''s also very easy to learn with the current documentation, so I fail to see the problem. Just my 0.02. -- Alf --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
