Re: A question related to URLConf, Reverse URL, etc...
I'd suggest doing it as middleware which appends to the request (sorta
like the user middleware). This way it's available in the view as well
as the template context (if you pass it explicitly or use the request
context processor).
Also, what about urls.py deeper than just parent->child? Maybe stem
should be a list of matches, one for each URLResolver?
On Jan 27, 7:12 am, "medhat" <[EMAIL PROTECTED]> wrote:
> Here is even a better idea...
>
> in your urls.py when you "from django.conf.urls.defaults import *" this
> will import 'stem' in addition to the usual things. In any url pattern,
> if you add {'param_name':stem} to the extra options, your view will get
> a keyword argumant called 'param_name' and will have the value of the
> part of the url that matched *before* going into that urls.py file.
>
> example:
>
> --- urls.py ---
>
> from django.conf.urls.defaults import *
>
> urlpatterns = patterns('',
> (r'^categories/', include('apps.tags.urls')),
> )
>
> --- apps/tags/urls.py ---
>
> from django.conf.urls.defaults import *
>
> urlpatterns = patterns('apps.tags.views',
> (r'^(?P[^/]*)/$','tag_list',{'stem':stem}),
> )
>
> ---
>
> In that case the urlhttp://www.example.com/tags/x/will call
> apps.tags.views.tag_list and pass it the request object and two keyword
> parameters: tag = 'x' and stem = /categories/
>
> I already have a patch that does this. I don't have unit tests or
> documentation yet. But if this looks like a patch that would be
> accepted, I can definitely work on the tests and documentation.
>
> --
> Thanks,
> Medhat
--~--~-~--~~~---~--~~
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: Is this group moderated, or is it a bug with google groups?
> I wish there were a way for Google Groups moderators to allow other > trusted users to OK the spam messages, because clearly this is a > bottleneck. If there is, please let me know. There is. Go to "Management Tasks", "Manage Members" Then find the members you trust, and promote them to "manager"s. If you're "owner" then there's minimal risk. --~--~-~--~~~---~--~~ 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: A question related to URLConf, Reverse URL, etc...
the url should be http://www.example.com/categories/x/
--
Medhat
On Jan 26, 12:12 pm, "medhat" <[EMAIL PROTECTED]> wrote:
> Here is even a better idea...
>
> in your urls.py when you "from django.conf.urls.defaults import *" this
> will import 'stem' in addition to the usual things. In any url pattern,
> if you add {'param_name':stem} to the extra options, your view will get
> a keyword argumant called 'param_name' and will have the value of the
> part of the url that matched *before* going into that urls.py file.
>
> example:
>
> --- urls.py ---
>
> from django.conf.urls.defaults import *
>
> urlpatterns = patterns('',
> (r'^categories/', include('apps.tags.urls')),
> )
>
> --- apps/tags/urls.py ---
>
> from django.conf.urls.defaults import *
>
> urlpatterns = patterns('apps.tags.views',
> (r'^(?P[^/]*)/$','tag_list',{'stem':stem}),
> )
>
> ---
>
> In that case the urlhttp://www.example.com/tags/x/will call
> apps.tags.views.tag_list and pass it the request object and two keyword
> parameters: tag = 'x' and stem = /categories/
>
> I already have a patch that does this. I don't have unit tests or
> documentation yet. But if this looks like a patch that would be
> accepted, I can definitely work on the tests and documentation.
>
> --
> Thanks,
> Medhat
--~--~-~--~~~---~--~~
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: A question related to URLConf, Reverse URL, etc...
Here is even a better idea...
in your urls.py when you "from django.conf.urls.defaults import *" this
will import 'stem' in addition to the usual things. In any url pattern,
if you add {'param_name':stem} to the extra options, your view will get
a keyword argumant called 'param_name' and will have the value of the
part of the url that matched *before* going into that urls.py file.
example:
--- urls.py ---
from django.conf.urls.defaults import *
urlpatterns = patterns('',
(r'^categories/', include('apps.tags.urls')),
)
--- apps/tags/urls.py ---
from django.conf.urls.defaults import *
urlpatterns = patterns('apps.tags.views',
(r'^(?P[^/]*)/$','tag_list',{'stem':stem}),
)
---
In that case the url http://www.example.com/tags/x/ will call
apps.tags.views.tag_list and pass it the request object and two keyword
parameters: tag = 'x' and stem = /categories/
I already have a patch that does this. I don't have unit tests or
documentation yet. But if this looks like a patch that would be
accepted, I can definitely work on the tests and documentation.
--
Thanks,
Medhat
--~--~-~--~~~---~--~~
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: Is this group moderated, or is it a bug with google groups?
This is funny. Now it seems to work. It didn't work for months. tom On Jan 26, 2007, at 6:30 PM, Thomas Steinacher wrote: > > Yeah, google groups sucks. Using my gmail.com account it sometimes > takes up to three days until a message appears. I also couldn't post > to the list using a non-gmail account. It says that I'm not > subscribed to the list, but I am. > > 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: Is this group moderated, or is it a bug with google groups?
Yeah, google groups sucks. Using my gmail.com account it sometimes takes up to three days until a message appears. I also couldn't post to the list using a non-gmail account. It says that I'm not subscribed to the list, but I am. tom On Jan 26, 2007, at 7:49 AM, medhat wrote: > > So many times I send messages to the group, but my message does not > appear at all, or it might appear a day or two after I actually send > it, which of course makes it appear down on the list, and nobody > really > sees it. > > -- > Thanks, > Medhat > > > > --~--~-~--~~~---~--~~ 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: form.clean conundrum
I've just got to write my first form.clean method. I need to to do some complex validation of different combinations of fields depending on the setting of one other field. This works great until one or more of the individual field validations fail. In my form.clean method I'm using the self.clean_data dict as already filled in by the individual field.clean methods. This seems like the way to go so as not to repeat the field validations. However, if a fild validation fails an entry for that field is not made in the clean_data dict, but an entry is added to the local var errors dict. Without testing for the presence of each value within clean_data, I see no way of telling whether any individual field has failed it own validation or not. As far as I am concerned, if any individual field fails validation then there is no point in doing any more validation for combinations of fields. There may be people who do want to do this though. I see two solutions: 1) don't call form.clean() if any individual field validation fails 2) pass in the local errors[] dict populated from the field.clean() calls into form.clean() so we can see if there were indeed any failed fields and decide if we want to carry on validation in form.clean() or not. Regards, Gary. --~--~-~--~~~---~--~~ 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 Jan 26, 2007, at 11:47 AM, Michael Radziej wrote: > # 1356 sets the charset attribute of the mysql backend connection to > 'utf8' for mysql version >= 4.1 And leaves everyone who wants to operate in 8 bits out in the cold. Where they actually ought to be anyway, but I tried to stay liberal in 952 - primarily because it's still unknown how Django authors want to approach this. -- Julian 'Julik' Tarkhanov please send all personal mail to me at julik.nl --~--~-~--~~~---~--~~ 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 Jan 26, 2007, at 2:25 PM, Gábor Farkas wrote: > > Julian 'Julik' Tarkhanov wrote: >> >> >> Python's unicode is actually UTF-16 > > on linux it's usually utf-32, and on windows it's usually (always?) > utf-16. sorry I forgot that - it's been a year at least since I last touched Python (actually it was for the Django test drive) > > but you should not care about it. you see, in python, > the unicode-strings are a separate data-type, and there's > just no way to take a bytestring, and tell python: "from now on, > you are an unicode-string, because i know that you are encoded in > utf-16." segregating ustrings and strings is BBD, been' telling it for years. The latest I heard is that the next major Py will abolish bytestrings for good. Getting back to the issue that we were on, I am still strongly advocating the "don't go there" approach for anything but Unicode. How it should be handled in relation to source code is unknown to me (AFAIK Python has a pre-amble sort of declaration that you can actually use to tell the interpreter which encoding your source is in). I just know you hit some major pain when you expect ustrings and get bytestrings instead (and in Python, just as in Perl, only about 30% of the libraries actually care about what they give you). > so while it might be, that the conversion from utf-16-bytestrings to > unicode is sometimes faster thatn converting from utf-8-bytestrings to > unicode, you can't be sure, because as i wrote above, the internal > unicode-encoding is not fixed. > >> whereas IO and the databases mostly >> speak UTF-8 - >> so no, you can't dump it over the wire. > >> We Rubyists are a tad happier >> because we now >> have all in UTF-8 > > you mean that regexes, and all the methods of the string-class now are > unicode-aware in ruby? :) Regexes are unicode-aware for some time already except the case- sensitivity and the class repertoire (which will be fixed when Oniguruma is there). As for the string methods, we mostly took care of them with AS::Multibyte (without silly subclassing) and that works wonders for me. The greatest advantage is that I never have to check what's coming down the pipe because there's only one String to rule them all. -- Julian 'Julik' Tarkhanov please send all personal mail to me at julik.nl --~--~-~--~~~---~--~~ 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: FastCGI vs. mod_python as "current preferred setup"
Apache and mod_python is most common on shared/other hosting with preinstalled servers. If someone has such account the he should use it and don't try to install other servers etc. But if someone has the possibility to choose the software then the docs should show alternatives like nginx + fastcgi or cherokee + scgi which are very easy to configure and rather stable from what I can say :) --~--~-~--~~~---~--~~ 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
Julian 'Julik' Tarkhanov wrote: > > > Python's unicode is actually UTF-16 sorry, but no. it's not utf-16. it's decided at compile-time, and i'ts either utf-32 or utf-16. on linux it's usually utf-32, and on windows it's usually (always?) utf-16. but you should not care about it. you see, in python, the unicode-strings are a separate data-type, and there's just no way to take a bytestring, and tell python: "from now on, you are an unicode-string, because i know that you are encoded in utf-16." the way it works is that you take a bytestring, and ask python to convert it into an unicode-string (and you also have to tell python the bytestring's charset). so while it might be, that the conversion from utf-16-bytestrings to unicode is sometimes faster thatn converting from utf-8-bytestrings to unicode, you can't be sure, because as i wrote above, the internal unicode-encoding is not fixed. > whereas IO and the databases mostly > speak UTF-8 - > so no, you can't dump it over the wire. > We Rubyists are a tad happier > because we now > have all in UTF-8 you mean that regexes, and all the methods of the string-class now are unicode-aware in ruby? :) gabor --~--~-~--~~~---~--~~ 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: FastCGI vs. mod_python as "current preferred setup"
On 1/25/07, Mihai Preda <[EMAIL PROTECTED]> wrote: > > Hi, > in the documentation (here: > http://www.djangoproject.com/documentation/fastcgi/ ) it is written > that the "current preferred setup" for running Django is mod_python > (rather than FastCGI). > > I'd like to know why is that. Does mod_python offer some advantages, > and which ones? > An explanation of why mod_python is preferred could also be welcome in > the documentation, next to that affirmation. > Take a look to the recently published draft of the " Chapter 21: Deploying Django" at http://www.djangobook.com/en/beta/chapter21/ Regards, -- Ramiro Morales --~--~-~--~~~---~--~~ 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
ak wrote: > Ticket http://code.djangoproject.com/ticket/952 contain a complete > solution of this problem and I don't know why it was not merged into > the code but at the moment it is not matter and here is the reason why: > Since newforms library was born and the decision about using unicode > for clean_data was made, all these patches became unnecessary Not at all. Anton, read my summary that I posted as a reply to Michael first post. Specifying database encoding and keeping internals in unicode are two separate issues. #952 is still necessary but not enough to fix your bug. > because > now developers must use only unicode everywhere (templates, db etc) Actually the shouldn't :-). Newforms is now the only part of Django that works with unicode. I/O with th web (requests and templates) are now hotfixed to work with it in a way. Databases aren't. > or > manually recode all forms based on newforms from unicode to native > encoding and back. Ofcourse this is stupid May be it is. But it's a temporary inconvenience of newforms. Later database backend should do this automatically by using either 'utf-8' or DATABASE_CHARSET as I described in that my message. BTW, there were ideas here about really really forcing users to migrate all data into unicode/utf-8 and be the first guy on the block that would lead the trend. This is noble but hard and if I remember correctly this was decided against... > So, for me the quesion sounds like this: either newforms don't use > unicode to store clean_data and we can keep using 'legacy' character > sets, or django needs to drop all charsets support except of unicode. > Or it should convert strings back and forth everywhere LOL Incidentally you last 'LOL' is the option that Django have chosen :-). I'll try to explain. 'Unicode' is not a charset, or, more specifically, it is not represented with bytes. Python's native unicode string represent unicode characters in some internal format that just can't be dumped over the wire, be it to database or to the web. Because of this if Django would work internally in unicode it must encode everything it writes and decode everything it reads from outside. Converting from unicode to utf-8 is also encoding, and it does not happen automatically. When you say that db backend supports 'unicode' it actually means that db library under Django backend does the encoding itself. But whether it's done in the library or in Django backend we still need a setting for charset. Two settings actually: for the web (that we already have) and for db (that is implemented in #952). --~--~-~--~~~---~--~~ 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
Hi, here's a summary what the different tickets are about: # 952 adds a database client encoding setting, DATABASE_CLIENT_CHARSET, for mysql and postgresql backends. For mysql, it uses the given charset in 'SET NAMES' to build the connection, except for mysql < 4.1. For postgresql, it does a 'SET CLIENT_ENCODING TO'. # 1356 sets the charset attribute of the mysql backend connection to 'utf8' for mysql version >= 4.1 # 3370 starts by explaining a traceback within newforms when you use utf8-encoded values with a form created by form_for_instance and has a patch that adds 'charset':'utf8' to the kwargs used in Database.connect() within DatabaseWrapper.cursor() Michael Radziej -- 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
Guys
The problem is simple but it was born a very long time ago.
For MySQL 4.1 and higher there is hardcoded in
django/db/backends/mysql/base.py:
cursor.execute("SET NAMES 'utf8'")
there were lots of tickets and messages in django-users complaining to
this but in fact they all were ignored.
Personally my company used to use patched django installation where
this line was replaced to:
cursor.execute("SET NAMES 'cp1251'")
because all our templates were (and still are in the production
environment) in windows-1251 encoding so we have had to use cp1251 to
deal with db.
Ticket http://code.djangoproject.com/ticket/952 contain a complete
solution of this problem and I don't know why it was not merged into
the code but at the moment it is not matter and here is the reason why:
Since newforms library was born and the decision about using unicode
for clean_data was made, all these patches became unnecessary because
now developers must use only unicode everywhere (templates, db etc) or
manually recode all forms based on newforms from unicode to native
encoding and back. Ofcourse this is stupid and noone will do it because
it's easier to migrate to utf-8 and forget about the problem.
So, for me the quesion sounds like this: either newforms don't use
unicode to store clean_data and we can keep using 'legacy' character
sets, or django needs to drop all charsets support except of unicode.
Or it should convert strings back and forth everywhere LOL
Any other opinions ?
--~--~-~--~~~---~--~~
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: > Hi, > > we have a bit of chaos here ... Tickets 3370, 1356 and probably 952 > all are about this problem, all are accepted, and #3370 and #1356 > have very similar patches. I ask everybody to continue discussion > here in django-developers, and I ask the authors of these three > tickets to work together to find out how to proceed. Right :-). I'll generalize my comment in #3370 here. There are, in fact, two separate issues. 1. First one (that #952 was intended to fix) is that we don't have a notion of a database internal encoding at all. This is bad because DB is as external to Django as the web and it can be in any encoding. Then there are two ways of dealing with it: - let Django encode data into a charset that a database expects - tell a database which encoding Django uses and let it to encode data into its internals #952 is implemented as a second variant and it looks like it works (in fact author of it is Julian Tarkhanov -- a well known unicode expert and advocate in russian blogosphere.. just giving credits :-) ) We really should have this thing regardless of Django's unicode or byte-string internals. 2. The second issue is an automatic conversion of unicode data for db backends that don't understand unicode. It's become relevant recently because people started to use newforms. If we accept #952 as it is then this should be resolved be encoding things into 'utf-8' inside backends. If we chose to reimplement database encoding support on django side then backend should encode into whatever encoding is stored in DATABASE_CHARSET setting. This is what things are like now. --~--~-~--~~~---~--~~ 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: Is this group moderated, or is it a bug with google groups?
Its the new google groups, I think. I saw the same thing the other day with the (then beta) new google groups, but had no issues with the old one. -rob On Jan 25, 10:59 pm, "James Bennett" <[EMAIL PROTECTED]> wrote: > On 1/26/07, medhat <[EMAIL PROTECTED]> wrote: > > > So many times I send messages to the group, but my message does not > > appear at all, or it might appear a day or two after I actually send > > it, which of course makes it appear down on the list, and nobody really > > sees it.The list isn't moderated; if a message you post takes a while to > > show > up, it's not because someone is intercepting it and intentionally > delaying it. > > -- > "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 -~--~~~~--~~--~--~---
