Re: Newforms: colon after label
On Mar 27, 11:39 pm, "SmileyChris" <[EMAIL PROTECTED]> wrote: > On Mar 28, 9:03 am, "vfoley" <[EMAIL PROTECTED]> wrote: > > > Hello, > > > I rewrote the forms portion of an application by using newforms. It's > > pretty nice, however there is something extremely annoying: newforms > > automatically adds a colon after labels (hopefully, my formatting is > > correct): > > This is the way that it has been decided to handle the labels in the > "lazy" methods. You aren't forced to use these methods. > > > P.S: This code is from 0.96, I haven't checked the Subversion tree. > > You won't see any difference, except that I have a ticket which will > only add the colon if there is no other punctuation to be added soon. > Hrm... I guess a ' ' could be added to my check for punctuation, in > which case it would leave the colon off if you ended in a space. Meh, > maybe that's a bit to "magic". I think that this is a very bad solution. If the framework does something small magically, like adding a colon, there has to be a way to remove it without a *big* change like, for example, writing a custom template, referencing every form-field by itself, just to remove a colon. Also, there simply are languages where this punctuation doesn't make sense. Adding it automatically then telling international users that they have to write a lot more code, because english developers wanted to save one character is bad, I think. Imho, adding even more magic to make it go away, makes even less sense. Not to mention that there are a lot of layout choices that would make this colon superfluous. What's wrong with name = forms.CharField(label='Your name:')? I'd definitely go for removing this altogether before it's to late. Best regards from Germany, Jonas --~--~-~--~~~---~--~~ 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: colon after label
On Mar 29, 1:38 pm, "Jonas Maurus" <[EMAIL PROTECTED]> wrote: > Also, there simply are languages where this punctuation doesn't make > sense. Adding it automatically then telling international users that > they have to write a lot more code, because english developers wanted > to save one character is bad, I think. Imho, adding even more magic to > make it go away, makes even less sense. > > Not to mention that there are a lot of layout choices that would make > this colon superfluous. > > What's wrong with > name = forms.CharField(label='Your name:')? > > I'd definitely go for removing this altogether before it's to late. I think there are lots of situations where you need to normalize the labels with some string. Why not just make it an optional parameter to the Form class with a default value.. maybe ":"? Rune --~--~-~--~~~---~--~~ 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: colon after label
On Mar 29, 2:07 pm, "bromer" <[EMAIL PROTECTED]> wrote: > On Mar 29, 1:38 pm, "Jonas Maurus" <[EMAIL PROTECTED]> wrote: > > > Also, there simply are languages where this punctuation doesn't make > > sense. Adding it automatically then telling international users that > > they have to write a lot more code, because english developers wanted > > to save one character is bad, I think. Imho, adding even more magic to > > make it go away, makes even less sense. > > > Not to mention that there are a lot of layout choices that would make > > this colon superfluous. > > > What's wrong with > > name = forms.CharField(label='Your name:')? > > > I'd definitely go for removing this altogether before it's to late. > > I think there are lots of situations where you need to normalize the > labels with some string. Why not just make it an optional parameter to > the Form class with a default value.. maybe ":"? > > Rune so that would make name = forms.CharField(label='What role do you want to play?') into name = forms.CharField(label='What role do you want to play', punctuation='?') for *sometimes* saving you from typing one character? I still think it makes no sense to append anything at all. Not to mention the pending unicodization... the Japanese, Chinese, Korean and Cyrillic alphabets don't use western punctuation... Unless there's a better argument than sometimes saving one character or being backwards-compatible to 0.96, I'm still against this. However, I don't carry much weight around here ;-) cheers, Jonas --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Trac Timeline RSS feeds
Hi all, I just noticed that my RSS reader has stopped providing notifications of new and closed tickets. The problem appears to be caused by Django's RSS feed. For example, if you follow the RSS link at the bottom of the the default timeline page http://code.djangoproject.com/timeline you get an error complaining that: Ticket changes, Ticket details event provider (TicketModule) failed: AttributeError: 'NoneType' object has no attribute 'lower' RSS feeds that don't enable Ticket or TicketDetails appear to be fine. Looking back, I haven't actually had any Trac RSS updates since late January - which as I recall was about when the new Trac version was rolled out. Am I the only one seeing this problem? Yours, Russ Magee --~--~-~--~~~---~--~~ 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: colon after label
On Thu, 2007-03-29 at 13:02 +, Jonas Maurus wrote: > > I think there are lots of situations where you need to normalize the > > labels with some string. Why not just make it an optional parameter to > > the Form class with a default value.. maybe ":"? > > > > Rune > > so that would make > >name = forms.CharField(label='What role do you want to play?') > > into > > name = forms.CharField(label='What role do you want to play', > punctuation='?') > > for *sometimes* saving you from typing one character? I still think it > makes no sense to append anything at all. Not to mention the pending > unicodization... the Japanese, Chinese, Korean and Cyrillic alphabets > don't use western punctuation... > > Unless there's a better argument than sometimes saving one character > or being backwards-compatible to 0.96, I'm still against this. > However, I don't carry much weight around here ;-) I think he was suggesting in the form, not each field: form = forms.Form(punct='') would let you create a form with no colons. You could also do something like form = forms.Form(punct='-->') or whatever. This would also allow you to override the punctuation based on locale. Seems like a not bad solution. People who hate the colons could create their own subclass of Form and use it instead of the default form and then they wouldn't have to set the punct value each time. Todd --~--~-~--~~~---~--~~ 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: colon after label
On Mar 29, 3:10 pm, "Todd O'Bryan" <[EMAIL PROTECTED]> wrote: > On Thu, 2007-03-29 at 13:02 +, Jonas Maurus wrote: > > > I think there are lots of situations where you need to normalize the > > > labels with some string. Why not just make it an optional parameter to > > > the Form class with a default value.. maybe ":"? > > > > Rune > > > so that would make > > >name = forms.CharField(label='What role do you want to play?') > > > into > > > name = forms.CharField(label='What role do you want to play', > > punctuation='?') > > > for *sometimes* saving you from typing one character? I still think it > > makes no sense to append anything at all. Not to mention the pending > > unicodization... the Japanese, Chinese, Korean and Cyrillic alphabets > > don't use western punctuation... > > > Unless there's a better argument than sometimes saving one character > > or being backwards-compatible to 0.96, I'm still against this. > > However, I don't carry much weight around here ;-) > > I think he was suggesting in the form, not each field: > > form = forms.Form(punct='') > > would let you create a form with no colons. You could also do something > like > > form = forms.Form(punct='-->') > > or whatever. This would also allow you to override the punctuation based > on locale. Seems like a not bad solution. People who hate the colons > could create their own subclass of Form and use it instead of the > default form and then they wouldn't have to set the punct value each > time. > > Todd You're of course right. I see that this would allow Django to be backwards-compatible by introducing this new parameter, so I could go for that because I think backwards-compatibility is very important. I still disagree with the concept anyway because I think that: * it's a newbie-trap ("where does this colon come from it's neither in the template nor in my string???"and * it doesn't really save any significant amount of time or space (12 characters saved on a form with 12 fields) and * it splits your label string between two classes so it's a concern for l10n and * it's not very friendly to languages that don't use english/western punctuation So I guess it comes down between backwards-compatibility and "doing the right thing as currently defined by Jonas Maurus". I think that it's clear that requiring to write a full template for all form-fields just to remove the colon would be really bad, at least. Btw, how does the Django-community usually decide such a thing? by a vote like in Apache projects? or do we wait for one of the core developers to show up? :-) cheers Jonas --~--~-~--~~~---~--~~ 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: colon after label
I think the OP is correct, if you want the label to end with a colon ... then add the colon to the label. It doesn't get any simpler than that. Any other solution just gets in the way. i. --~--~-~--~~~---~--~~ 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: Status of SQLAlchemy branch
On Thu, 2007-03-29 at 07:07 +, Mir Nazim wrote: > Hello all, > > First let me thanks all developer for a great thing like Django. > > Now can anybody tell me about the status of Django's SQLAlchemy > branch. I could not find any place describing the status on > code.djangoproject.com. At the moment, nobody seems to be working on it. 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 -~--~~~~--~~--~--~---
Re: Trac Timeline RSS feeds
On Thu, 2007-03-29 at 21:05 +0800, Russell Keith-Magee wrote: > Hi all, > > I just noticed that my RSS reader has stopped providing notifications > of new and closed tickets. > > The problem appears to be caused by Django's RSS feed. For example, if > you follow the RSS link at the bottom of the the default timeline page > > http://code.djangoproject.com/timeline > > you get an error complaining that: > > Ticket changes, Ticket details event provider (TicketModule) failed: > > AttributeError: 'NoneType' object has no attribute 'lower' > > RSS feeds that don't enable Ticket or TicketDetails appear to be fine. > > Looking back, I haven't actually had any Trac RSS updates since late > January - which as I recall was about when the new Trac version was > rolled out. > > Am I the only one seeing this problem? I thought there was a ticket open about this, but I can't seem to find it now. The None used to be the priority (enhancement, "it's more important than those other losers", normal, etc). So your timing observations are consistent, although your attention to detail is suspect (it's almost April already, dude!). :-) Sorry .. I hadn't realised this was a problem, since I use the updates list these days. 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 -~--~~~~--~~--~--~---
Re: Newforms: colon after label
Were I work we have had to do this very thing to support I18N in our forms. Something as simple as a ":" is not a given. Maybe I want a " :" instead? This could be a form parameter or even a locale setting. My 2 cents, Ted On Mar 29, 9:10 am, "Todd O'Bryan" <[EMAIL PROTECTED]> wrote: > On Thu, 2007-03-29 at 13:02 +, Jonas Maurus wrote: > > > I think there are lots of situations where you need to normalize the > > > labels with some string. Why not just make it an optional parameter to > > > the Form class with a default value.. maybe ":"? > > > > Rune > > > so that would make > > >name = forms.CharField(label='What role do you want to play?') > > > into > > > name = forms.CharField(label='What role do you want to play', > > punctuation='?') > > > for *sometimes* saving you from typing one character? I still think it > > makes no sense to append anything at all. Not to mention the pending > > unicodization... the Japanese, Chinese, Korean and Cyrillic alphabets > > don't use western punctuation... > > > Unless there's a better argument than sometimes saving one character > > or being backwards-compatible to 0.96, I'm still against this. > > However, I don't carry much weight around here ;-) > > I think he was suggesting in the form, not each field: > > form = forms.Form(punct='') > > would let you create a form with no colons. You could also do something > like > > form = forms.Form(punct='-->') > > or whatever. This would also allow you to override the punctuation based > on locale. Seems like a not bad solution. People who hate the colons > could create their own subclass of Form and use it instead of the > default form and then they wouldn't have to set the punct value each > time. > > Todd --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Newlines in tags.
We have the following tag. It's well over 80 characters long (103), and for our own sanity we'd prefer to use a newline within the tag. We went looking for this bug report and I was told to discuss this on django-dev (thanks Jacob): http://code.djangoproject.com/ticket/1147 Is this a reasonable use case for asking that tags include newlines? Or is there a way we can shorten this tag that doesn't include shortening our variable names? Lakin --~--~-~--~~~---~--~~ 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: colon after label
On 3/29/07, Ted <[EMAIL PROTECTED]> wrote: > Were I work we have had to do this very thing to support I18N in our > forms. Something as simple as a ":" is not a given. Maybe I want a > " :" instead? This could be a form parameter or even a locale setting. FWIW I think the ideal would be for the default string representation of the form to not add any punctuation at all -- adding options to configure this just feel too ugly, so the proper solution should be for the form to not do it, and trust to application developers to present the form in whatever way they want (if that means no colon/other punctuation, then the default will still be fine; if not, the templating isn't all that complicated and provides absolute control of the output). -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ 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: colon after label
Jonas Maurus wrote: >> I think he was suggesting in the form, not each field: I did :) > I see that this would allow Django to be backwards-compatible by > introducing this new parameter, so I could go for that because I think > backwards-compatibility is very important. I still disagree with the > concept anyway because I think that: > > * it's a newbie-trap ("where does this colon come from it's neither > in the template nor in my string???"and > * it doesn't really save any significant amount of time or space (12 > characters saved on a form with 12 fields) and > * it splits your label string between two classes so it's a concern > for l10n and > * it's not very friendly to languages that don't use english/western > punctuation > > So I guess it comes down between backwards-compatibility and "doing > the right thing as currently defined by Jonas Maurus". I think that > it's clear that requiring to write a full template for all form-fields > just to remove the colon would be really bad, at least. Btw, how does > the Django-community usually decide such a thing? by a vote like in > Apache projects? or do we wait for one of the core developers to show > up? :-) I would agree that the punctuation should not be there at all, as it's easy to add it to the label yourself. If - on the other hand - we want the parameter on the form I would be happy to write a patch.. should be quickly done.. Rune --~--~-~--~~~---~--~~ 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: Trac Timeline RSS feeds
Maybe you can't find it because it's "wontfix" :)) http://code.djangoproject.com/ticket/3326 On 3/29/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > > > On Thu, 2007-03-29 at 21:05 +0800, Russell Keith-Magee wrote: > > Hi all, > > > > I just noticed that my RSS reader has stopped providing notifications > > of new and closed tickets. > > > > The problem appears to be caused by Django's RSS feed. For example, if > > you follow the RSS link at the bottom of the the default timeline page > > > > http://code.djangoproject.com/timeline > > > > you get an error complaining that: > > > > Ticket changes, Ticket details event provider (TicketModule) failed: > > > > AttributeError: 'NoneType' object has no attribute 'lower' > > > > RSS feeds that don't enable Ticket or TicketDetails appear to be fine. > > > > Looking back, I haven't actually had any Trac RSS updates since late > > January - which as I recall was about when the new Trac version was > > rolled out. > > > > Am I the only one seeing this problem? > > I thought there was a ticket open about this, but I can't seem to find > it now. The None used to be the priority (enhancement, "it's more > important than those other losers", normal, etc). So your timing > observations are consistent, although your attention to detail is > suspect (it's almost April already, dude!). :-) > > Sorry .. I hadn't realised this was a problem, since I use the updates > list these days. > > 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 -~--~~~~--~~--~--~---
Tags cannot contain newlines
Hello, Please see "Tags cannot contain newlines": http://code.djangoproject.com/ticket/1147 I have been instructed by mtredinnick to bring the discussion here. Can someone please justify why this wont be fixed? Thanks, Noah --~--~-~--~~~---~--~~ 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: Tags cannot contain newlines
On 3/29/07, Noah Slater <[EMAIL PROTECTED]> wrote: > Please see "Tags cannot contain newlines": > > http://code.djangoproject.com/ticket/1147 > > I have been instructed by mtredinnick to bring the discussion here. > > Can someone please justify why this wont be fixed? I don't like newlines within tags purely for aesthetic reasons. A tag is a bite-sized, atomic unit. If it's spread over multiple lines, it turns into some strange mushy, ugly thing. Yes, this is highly subjective. I realize that, and I shudder at the thought of a 30-message mailing-list discussion of the aesthetics of newlines vs. no newlines. Please accept the fact that tags cannot contain newlines. 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: Tags cannot contain newlines
On 3/29/07, Noah Slater <[EMAIL PROTECTED]> wrote: > I have been instructed by mtredinnick to bring the discussion here. > > Can someone please justify why this wont be fixed? See also this thread from earlier today which covers some technical/performance reasons: http://groups.google.com/group/django-users/browse_frm/thread/ac646d3ec7482bec/429120bc428ba187#429120bc428ba187 -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ 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: Tags cannot contain newlines
> I don't like newlines within tags purely for aesthetic reasons. A tag > is a bite-sized, atomic unit. If it's spread over multiple lines, it > turns into some strange mushy, ugly thing. > > Yes, this is highly subjective. I realize that, and I shudder at the > thought of a 30-message mailing-list discussion of the aesthetics of > newlines vs. no newlines. Please accept the fact that tags cannot > contain newlines. No, the bikeshed should be yellow! Jacob --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
{% lorem %} only half checked in
Can a core developer please check in the missing file from the ticket (it's in the patch, it just wasn't committed it seems): http://code.djangoproject.com/ticket/3799 --~--~-~--~~~---~--~~ 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: {% lorem %} only half checked in
On 3/29/07, SmileyChris <[EMAIL PROTECTED]> wrote: > Can a core developer please check in the missing file from the ticket > (it's in the patch, it just wasn't committed it seems): > http://code.djangoproject.com/ticket/3799 I'll take care of it. FYI, while I'm at it, I'm going to move it into a new django.contrib package; the tag is nice, but it's not fundamentally necessary to the template system. -- 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: Status of SQLAlchemy branch
On 3/29/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > > On Thu, 2007-03-29 at 07:07 +, Mir Nazim wrote: > > Hello all, > > > > First let me thanks all developer for a great thing like Django. > > > > Now can anybody tell me about the status of Django's SQLAlchemy > > branch. I could not find any place describing the status on > > code.djangoproject.com. > > At the moment, nobody seems to be working on it. I filed a Google SOC application for SQLAlchemy branch. Whether or not the soc goes through I'll think I'll dig in to the SQLAlchemy branch anyway. I'd like to see it too in action. -- Jyrki // [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 -~--~~~~--~~--~--~---
Criteria for localflavour
Hi all, We're starting to see some localflavour patches drift in, which is great (e.g. it: #3866, fi: #3847, ja: #3715 ). However, we should be briefly documenting these - it could simply just be a list of what's in there so far. I'll work up a patch for this sometime, but just wondered where to put it. Currently django.contrib.localflavor is listed in the "add_ons" docs, but should the details be in the internationalisation docs (either way the i18n docs should mention localflavour), or could this have its own doc file? --Simon --~--~-~--~~~---~--~~ 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: {% lorem %} only half checked in
On 3/30/07, SmileyChris <[EMAIL PROTECTED]> wrote: > > Can a core developer please check in the missing file from the ticket > (it's in the patch, it just wasn't committed it seems): > http://code.djangoproject.com/ticket/3799 That was me - I forgot to svn add the new file. Apologies to all for the stuff up. Yours, Russ Magee %-) --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Should $HOME be an absolute path?
Hi, I've just (maybe stupidly on my behalf) spent an hour digging through Django code to find out why Django thought the template at $HOME/web/ my_site/templates/home_page.html doesn't exist. The answer is that I in the TEMPLATE_DIRS tuple need to to use the 'full' full path, /users/ topper/web/my_site/templates rather than $HOME/web/my_site/templates. Now, the comment clearly states that you have to use absolute paths, but in my mind $HOME *is* an absolute path, but maybe that's wrong? I'm no unix expert and maybe there is a security issue involved in allowing the use of environment variables, but if not, do you think it could be a good idea to allow the use of $HOME? in settings.py? It would make code somewhat more portable and help users not make 'stupid' mistakes like the one I did. I'll open a ticket and perhaps write a patch too if you think this is a good idea. Alternatively, a small warning in Template-loader postmortem when users use $HOME would be a great idea, IMO. regards Topper --~--~-~--~~~---~--~~ 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: Should $HOME be an absolute path?
On 3/30/07, topper <[EMAIL PROTECTED]> wrote: > > Hi, > > I've just (maybe stupidly on my behalf) spent an hour digging through > Django code to find out why Django thought the template at $HOME/web/ > my_site/templates/home_page.html doesn't exist. The answer is that I > in the TEMPLATE_DIRS tuple need to to use the 'full' full path, /users/ > topper/web/my_site/templates rather than $HOME/web/my_site/templates. > > Now, the comment clearly states that you have to use absolute paths, > but in my mind $HOME *is* an absolute path, but maybe that's wrong? you are wrong, HOME is an environment variable that exists on unix environments, it can be altered by the user and is not secure. > I'm no unix expert and maybe there is a security issue involved in > allowing the use of environment variables, but if not, do you think it > could be a good idea to allow the use of $HOME? in settings.py? It > would make code somewhat more portable and help users not make > 'stupid' mistakes like the one I did. More portable? What about windows users? > > I'll open a ticket and perhaps write a patch too if you think this is > a good idea. Alternatively, a small warning in Template-loader > postmortem when users use $HOME would be a great idea, IMO. if someone uses a shell expression in a python file, he cannot expect a warning, that's just wrong. Would you expect a warning if you would use something like nl2br( "string with ".$var ) in your code? If you want to construct the path dynamically, use python. After all, that's one of the reasons settings.py is just a python file. I am personally using something like this import os os.path.dirname( __file__ ) + '/templates' in my settings, that way I can move everything around and not worry about a thing. > > regards Topper > > > > > -- Honza Kr�l E-Mail: [EMAIL PROTECTED] ICQ#: 107471613 Phone: +420 606 678585 --~--~-~--~~~---~--~~ 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: Should $HOME be an absolute path?
On Mar 30, 1:28 am, "Honza Král" <[EMAIL PROTECTED]> wrote: > On 3/30/07, topper <[EMAIL PROTECTED]> wrote: > > > > > Hi, > > > I've just (maybe stupidly on my behalf) spent an hour digging through > > Django code to find out why Django thought the template at $HOME/web/ > > my_site/templates/home_page.html doesn't exist. The answer is that I > > in the TEMPLATE_DIRS tuple need to to use the 'full' full path, /users/ > > topper/web/my_site/templates rather than $HOME/web/my_site/templates. > > > Now, the comment clearly states that you have to use absolute paths, > > but in my mind $HOME *is* an absolute path, but maybe that's wrong? > > you are wrong, HOME is an environment variable that exists on unix > environments, it can be altered by the user and is not secure. > Fair enough. I'll retract the idea of allowing environment variables. > > I'm no unix expert and maybe there is a security issue involved in > > allowing the use of environment variables, but if not, do you think it > > could be a good idea to allow the use of $HOME? in settings.py? It > > would make code somewhat more portable and help users not make > > 'stupid' mistakes like the one I did. > > More portable? What about windows users? > > > > I'll open a ticket and perhaps write a patch too if you think this is > > a good idea. Alternatively, a small warning in Template-loader > > postmortem when users use $HOME would be a great idea, IMO. > > if someone uses a shell expression in a python file, he cannot expect > a warning, that's just wrong. Would you expect a warning if you would > use something like nl2br( "string with ".$var ) in your code? > Still, $HOME is a normal UNIX environmental variable, and because Django does use those in other places (i.e django_settings), a user could think that environment variables are accessible from Django. And when the user is told in Template loader postmortem that '$HOME/ some_file' does not exist, the information is in a way wrong or at least confusing. > If you want to construct the path dynamically, use python. After all, > that's one of the reasons settings.py is just a python file. > > I am personally using something like this > import os > os.path.dirname( __file__ ) + '/templates' > > in my settings, that way I can move everything around and not worry > about a thing. > That is a very, very cool approach. I'll definitely use this in my code. > > > > regards Topper > > -- > Honza Kr?l > E-Mail: [EMAIL PROTECTED] > ICQ#: 107471613 > Phone: +420 606 678585 --~--~-~--~~~---~--~~ 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: Should $HOME be an absolute path?
On 3/29/07, topper <[EMAIL PROTECTED]> wrote: > Still, $HOME is a normal UNIX environmental variable, and because > Django does use those in other places (i.e django_settings), a user > could think that environment variables are accessible from Django. And > when the user is told in Template loader postmortem that '$HOME/ > some_file' does not exist, the information is in a way wrong or at > least confusing. Python can access environment variables -- you just need to do it through the standard Python method of reading out of 'os.environ', e.g.: import os TEMPLATE_DIRS = ( os.environ['HOME'] + '/web/my_site/templates', ) -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ 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: {% url %} for generic views (proposal)
On Mar 27, 4:57 pm, "Adrian Holovaty" <[EMAIL PROTECTED]> wrote: > I've done some thinking on this, too, and I think the cleanest way to > solve it would be to introduce optional names for URL patterns. > Something like this: > > url(r'^objects/$', some_view, name='object_view'), > url(r'^objects2/$', some_view, name='object_view2'), > > This way, you could give an arbitrary name to a particular pattern, so > that you could target it via a reverse lookup. The Routes package does > something similar ("named routes"). Note that it would require URL > patterns to be function calls -- url() -- but that's probably a good > long-term switch, anyway, because it lets us do more interesting > things. We could likely keep it backwards compatible by changing the > patterns() function to convert any plain tuple into an object of the > type url() returns. This could be really hot. Pretend for a moment that this url is a class which has has a regex() method that is called when we, you know, want to know what the regex should be. This would allow people to write new url classes that took routes style patterns, or better yet (IMHO) URI templates [1]. The class would just have to know how to turn it's configuration arguments into the proper regex. Under the covers, dispatch still happens via regex, but there are kinder, gentler, and extensible ways of setting up those regexes without have to actually write them. Joseph [1] http://bitworking.org/projects/URI-Templates/draft-gregorio-uritemplate-00.html --~--~-~--~~~---~--~~ 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: {% url %} for generic views (proposal)
On Mar 28, 9:57 am, "Adrian Holovaty" <[EMAIL PROTECTED]> wrote: > I've done some thinking on this, too, and I think the cleanest way to > solve it would be to introduce optional names for URL patterns. > Something like this: > > url(r'^objects/$', some_view, name='object_view'), > url(r'^objects2/$', some_view, name='object_view2'), > How would the reverse end work? (I worry that this could easily lead to view name collision between applications) --~--~-~--~~~---~--~~ 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: {% lorem %} only half checked in
On 3/29/07, SmileyChris <[EMAIL PROTECTED]> wrote: > Can a core developer please check in the missing file from the ticket > (it's in the patch, it just wasn't committed it seems): > http://code.djangoproject.com/ticket/3799 It's in, as of [4857]. There's a new django.contrib.webdesign package: http://www.djangoproject.com/documentation/webdesign/ This django.contrib package is for anything and everything that has a "Web design" focus. If you have ideas for other designer-friendly functionality in Django, please suggest them! 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: {% url %} for generic views (proposal)
On Fri, 2007-03-30 at 01:57 +, SmileyChris wrote: > On Mar 28, 9:57 am, "Adrian Holovaty" <[EMAIL PROTECTED]> wrote: > > I've done some thinking on this, too, and I think the cleanest way to > > solve it would be to introduce optional names for URL patterns. > > Something like this: > > > > url(r'^objects/$', some_view, name='object_view'), > > url(r'^objects2/$', some_view, name='object_view2'), > > > > How would the reverse end work? (I worry that this could easily lead > to view name collision between applications) Have a look at the patch I posted to this list the other day. Reverse works by just specifying the name -- it's even in the test in that patch. The string you specify can be either the "name" name or the function name, since they are unlikely to clash unless you have a twisted way of naming things. You can't completely avoid name collisions for patterns (or apps or command line tools or anything) and somebody using very common words as a name for a URL pattern in a reusable app is asking for trouble. They probably drive around without wearing a seatbelt, too, though. There's just no accounting for taste. If you expect your URL patterns to be reusable, make the name something that is likely to be unique (e.g. add the app name as a prefix, so myapp-url, for example). That reduces the likelihood of name collisions to the same as that for app name collisions, which have to be handled in the same way -- by using uncommon names. I thought about allowing the "name" parameter on the include() directive as a way of controlling the prefix for the included patterns. However, that would break all templates that already used the name prior to the prefix being added. 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 -~--~~~~--~~--~--~---
Stack trace in DB comments
In the book "Building Scalable Web Sites", Cal Henderson suggests putting (possibly abbreviated) app call stacks in SQL comments to enable logging and performance on the DB backend to be more easily tied to application paths. This sounds like a great idea to me. MySQL, PGSQL and SQLite all support the same in-query comment syntax. I can see two ways to implement this. One would be an augmentation to utils.CursorDebugWrapper. The other would be a new wrapper. Doing it in CursorDebugWrapper seems a fairly natural place, but using that (easily) requires settings.DEBUG to be true. You probably wouldn't want to do that in production. Doing it in a new wrapper, we could introduce settings.DB_DEBUG which would -only- to the trace comments in the SQL, and would therefore be safe to do in production. (We could still make it such that if DEBUG=True, DB_DEBUG=True.) Either way, I think this would be a simple and useful change. Thoughts? --~--~-~--~~~---~--~~ 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: {% url %} for generic views (proposal)
Other than using uncommon names for the url one could just use the most obvious name and let the url tag have a disambiguation function so if the name is: "name" you could write both: {% url 'name' %} and {% url 'myapp.name' %} (or "myapp/name" or "myapp-name") With this you could keep the url management simple for most cases and allow users to differentiate colliding names (it would be terrible that if a name is taken by, lets say, comments or another contrib app users had problems for setting up url names) On Mar 29, 10:13 pm, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > On Fri, 2007-03-30 at 01:57 +, SmileyChris wrote: > > On Mar 28, 9:57 am, "Adrian Holovaty" <[EMAIL PROTECTED]> wrote: > > > I've done some thinking on this, too, and I think the cleanest way to > > > solve it would be to introduce optional names for URL patterns. > > > Something like this: > > > > url(r'^objects/$', some_view, name='object_view'), > > > url(r'^objects2/$', some_view, name='object_view2'), > > > How would the reverse end work? (I worry that this could easily lead > > to view name collision between applications) > > Have a look at the patch I posted to this list the other day. Reverse > works by just specifying the name -- it's even in the test in that > patch. The string you specify can be either the "name" name or the > function name, since they are unlikely to clash unless you have a > twisted way of naming things. > > You can't completely avoid name collisions for patterns (or apps or > command line tools or anything) and somebody using very common words as > a name for a URL pattern in a reusable app is asking for trouble. They > probably drive around without wearing a seatbelt, too, though. There's > just no accounting for taste. If you expect your URL patterns to be > reusable, make the name something that is likely to be unique (e.g. add > the app name as a prefix, so myapp-url, for example). That reduces the > likelihood of name collisions to the same as that for app name > collisions, which have to be handled in the same way -- by using > uncommon names. > > I thought about allowing the "name" parameter on the include() directive > as a way of controlling the prefix for the included patterns. However, > that would break all templates that already used the name prior to the > prefix being added. > > 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 -~--~~~~--~~--~--~---
Re: {% url %} for generic views (proposal)
On Fri, 2007-03-30 at 04:15 +, Nicolas E. Lara G. wrote: > Other than using uncommon names for the url one could just use the > most obvious name and let the url tag have a disambiguation function > so if the name is: "name" you could write both: > {% url 'name' %} and {% url 'myapp.name' %} (or "myapp/name" or > "myapp-name") The problem is predicting what we be called if you use the unprefixed argument. It's going be non-deterministic from an application's point of view, so they will *always* have to use a name that is unlikely to collide. Remember that templates have no point of reference -- they don't know that they were called from a particular app, so they'll always be scanning the URL configuration from the top level. > With this you could keep the url management simple for most cases and > allow users to differentiate colliding names (it would be terrible > that if a name is taken by, lets say, comments or another contrib app > users had problems for setting up url names) Which is the argument for using uncommon names for your urls. The exact same problem exists for application names. You can't create an app called django and expect it to work. Fortunately, django is one of many uncommon names you can use for an app, so it's easy to pick non-colliding names. If you choose "comments" for you redistributable app and somebody else does, too, you're both screwed. Name collision potential exists all the time (try writing an executable called "ls" and seeing how wide a distribution you get) and society hasn't ground to a halt just for asking people to be a little creative. 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 -~--~~~~--~~--~--~---
Localflavors: request for developers and triagers
With all the new found interest in localflavor/ contributions, I've started to see a pattern that could cause us trouble: Many locales have the native names using characters outside of the ASCII range. So people put "# -*- coding: utf-8 -*-" at the top of their file and then include the proper names. Okay, sounds reasonable. But it has a problem. When Python parses a file containing the encoding marker, it produces a str object containing the resulting string encoded as UTF-8. However, this object carries no information that it is UTF-8 encoded. This makes it hard to know what they are when you see them in a context far removed from their original import. You also can't call encode() or decode() on the string if it contains bytes greater than 127, which are always present in non-ASCII UTF-8 strings. To make our life easier (read "slightly more bullet-resistant"), these character strings should be unicode objects, not str objects. That way, we have the information we need to convert to other character encodings as needed. So could triagers please mark tickets with such strings as needing an improved patch and could original developers of these files please include any strings containing non-ASCII characters in as u"..." strings, not traditional strings. Nobody ever said Python unicode handling was perfect -- well, one guy did once, but he was drunk at the time and we sent him out on a one-way trip to the ice floes to go fishing -- and sometimes we have to just work around the sharp bits. The about semi-problem wouldn't be an issue except that we do need to be able to encode the strings into different encodings for input and database storage. The alternative would be to *always* use UTF-8 internally and that isn't an insane idea -- I know a few C libraries that work that way and it may turn out to be slightly faster in Python -- but it doesn't seem to be the traditional Python way, as far as I can tell. We best play as the other boys do to encourage other developers. 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 -~--~~~~--~~--~--~---