Re: django unicode-conversion, beginning
On 17-aug-2006, at 1:08, Bill de hÓra wrote: > like wanting to serve utf8 rss feeds, but have latin1 come > in and out of mysql. Might seem very extreme, but I would love to chime in. Maybe it would be wise to go even further, whereby: 1. Hardcode Django to output and input UTF-8 as the most useful for interop 1a. Any case where the developer might expect different input (for instance almost all OPML files are still exported as ISO due to idyosyncrastic way Radio worked back in the day) has to be known to him and handled explicittly 1b. Honor the charset headers sent in the request for transcoding 1c. Allow everyone who wants to output other charsets to cry and perish. 2. Stick the utf-8 output charset anywhere where it's possible (headers, page head...). 2. Allow the DB to be in another encoding for databases that support it. For instance, MySQL and Postgress will transcode the strings for the client on the fly, so you can do interop with them in UTF-8 even when they are in a different encoding. 3. Assume all templates are in UTF-8 as well because text editors have much more success dealing with it them that way. Transcode templates on read into unicode strings. 4. As a consequence of 1, let DEFAULT_CHARSET go. Too many choices really hurt here. 5. As a consequence of 1, deprecate the DATABASE_CHARSET I sent in as a patch and make it the default, so that all drivers switch their database clients to the most suitable Unicode form. SQLite has to be compiled with Unicode support, this has to be mentioned in the docs. 5. Internally, work with unicode strings exclusively (after transcoding the request and the template). Response should be python unicode as well up until the moment it gets sent out. Important to note is that every database driver has to be scrutinized for whether it returns unicode strings proper. I know, it seems so nice to be liberal and allow people to choose their encoding but just too many situations prove that to be the Wrong Choice. -- 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 -~--~~~~--~~--~--~---
Wiki and trac rejecting edits/ticket creation as spam
When I try to make some big changes on the wiki they get rejected - Akismet rejects them as spam :/ I wanted to make a ticked about it - rejected also. Here: http://www.wklej.org/id/e7bb1758b9 is the edited main wiki page (more links, better organization etc.) --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Re: JavaScript and Changeset 3541
On 8/19/06, simonbun <[EMAIL PROTECTED]> wrote: > I'm well aware that its no problem to use ajax right now by using any > JS toolkit. My point was that it seems somewhat wasteful to have custom > JS scripts for the admin generator, and then using a JS toolkit that > does the same thing. I submitted a partial porting of the admin JS to the Dojo toolkit a while back, but honestly I don't mind one way or the other if it ever goes in. If we decide to do real AJAX stuff in the admin app, then we'll probably have to pick a toolkit for it and bundle that with the admin app. For now, "waste" strikes me as a non-issue -- it's like saying that because the admin app uses XHTML 1.0 Strict, it'd be "wasteful" for someone to have their public-facing templates be HTML 4.01 Transitional. What the admin app does or doesn't do shouldn't have any bearing on the techniques you choose for the public part of an application. > Thats not the issue. Everyone can make their own choise perfectly well, > but if a "blessed" toolkit is chosen, more people are swimming in the > same direction. Wich would make it easier to bounce off of each others' > ideas & code, and maybe to help others that are stuck on something. To > me thats a benefit, to others maybe a limitation. The problem here is that, well, there's no such thing as "swimming in the same direction" -- to get that to work, there would have to be a one-size-fits-all JS toolkit out there, and there just isn't and never will be such a thing. But if somebody wants a "blessing", then here's a blessing that carries whatever weight people attach to my rambling opinions: The official JavaScript toolkit of the Django web framework is the one that best suits what you want to do with it. The BDFL bless you and keep you, etc. > How is that a self-fulfilling prophecy? I was just saying that choosing > a particular toolkit will not get in the way of django developers that > choose not to use it. Much like the current JS doesn't get in the way. Time and time and time again we've seen people who -- literally -- would take a "bundled" toolkit as a blanket statement of "use this, and nothing else". That's not how we roll. And the opposite statement could be made in response to your argument -- *not* choosing a particular toolkit doesn't get in anyone's way, either. -- "May the forces of evil become confused on the way to your house." -- George Carlin --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: JavaScript and Changeset 3541
Malcolm Tredinnick wrote: > On Sat, 2006-08-19 at 07:57 +, simonbun wrote: > > I'm not so sure its such a bad idea to bundle a JS toolkit with the > > framework. > > It's only been a month since the last time we had this thread. Do we > have to do this again? :-( > > Really, you bring up nothing that hasn't been covered in the Lord knows > how many threads on this we've had over the last eight to 12 months. > > Lack of a "blessed" or include Javascript toolkit does not prevent > anybody from writing Ajax applications. It does not prevent anybody from > doing anything they could do if we had a library included, outside of > the maybe four people who work on the Admin interface. > > You claim that including a toolkit will "make Ajax a possibility", but > since it's already a possibility (people are already building > Ajax-enabled Django-backed websites), it's not clear what you mean. > Maybe it was better to dig up an old thread. I just read some arguments against using a toolkit in this thread that i didn't agree with. I'm well aware that its no problem to use ajax right now by using any JS toolkit. My point was that it seems somewhat wasteful to have custom JS scripts for the admin generator, and then using a JS toolkit that does the same thing. > The "if we don't have one people won't know what to choose" argument > seems weak. It's "please help save me from having to think for myself." > Django is NOT a Javascript-based framework, so us suggesting a > Javascript toolkit is just another voice in the crowd with no more > credibility than the next guy. Thats not the issue. Everyone can make their own choise perfectly well, but if a "blessed" toolkit is chosen, more people are swimming in the same direction. Wich would make it easier to bounce off of each others' ideas & code, and maybe to help others that are stuck on something. To me thats a benefit, to others maybe a limitation. > > There are probably some advantages to doing some Admin stuff with Ajax. > But that's just the admin interface. Somebody wanting to prove their > point should feel free to write an application that shows all this > wonder. Remember, there is nothing to prevent having an external admin > app. It's just an application, after all; you don't need to ship a patch > that changes the core distribution. I more than suspect that will happen > one day. > > [...] > > - I suggest a thread is started where the pros & cons of all JS > > toolkits are weighed in, > > Please, no! > > This has been done on the Django lists before. Just search the archives. > More importantly, it's been done in Javascript forums before as well. > Consensus is that all the popular ones are sufficiently good and fit for > purpose. Opinions vary about absolute best, but that's life in the > software industry, since it's unlikely there is any way to measure > "absolute" best in an objective fashion. > > > and a choise is made as a community on wich > > one to pick. > > We seem to have already made a choice. You would like a different > choice. At which point will this argument stop going around and around? > > Feel free to recommend your favourite toolkit at every possibility. > Point people towards articles showing how to integrate it. You will get > lots of thanks from the people asking the questions and no complaints > from anybody else (other than those still working on the support > materials for their own favourite toolkit). You can even host these on > the Django website. It's why we have the Wiki. Guys like Dave Coulix > have already posted some Ajax + Django articles. > > > Frankly, i don't think many will get religeous about their > > toolkit. I believe most (including me) just want A toolkit. > > > - I think the chosen JS toolkit should be as loosly coupled with the > > framework as possible. i.e. no javascript helpers (à la RoR) that > > sprout blocks of javascript code everywhere. > > No helpers seems to imply there's no particular way to use the toolkit > we include beyond standard "write your own" accessors. The benefit to > including it would then be ? I don't think its right to bloat the core with javascript helpers. I never liked the whole idea of helpers and i believe every developer should know how to write the necessary javascript "manually". The benefit, like i said earlier, is to avoid JS code redundancy. And to offer a lot more possibilities than there are at the moment. > > > - If implemented correctly, i don't see how choosing a JS toolkit would > > get in the way of anyone, even people that don't want to use JS or ajax > > or whatever at all. > > This kind of lack of specificity doesn't help your arguments at all. > It's a self-fulfilling statement: if the toolkit integration does get in > the way, then it's not implemented correctly. > How is that a self-fulfilling prophecy? I was just saying that choosing a particular toolkit will not get in the way of django developers that choose not to use it. Much like the
Re: JavaScript and Changeset 3541
On 8/19/06, simonbun <[EMAIL PROTECTED]> wrote: > - Ajax would be a possibility. I know many of you don't like ajax, but > i believe that if its used with consideration and restraint (i.e. no > color-changing div layers flying about), it can be a big plus. This > does not mean that the admin generator should use ajax per default > though. The above point is inaccurate, assuming you based your opinion on the fact that core developers don't support bundling a JS toolkit with Django. Adrian's own chicagocrime.org is AJAX/JavaScript heavy, using Google Maps. James has written articles on his site about developing AJAX apps with Django. These are just a couple examples. The wiki is full of more. We use JavaScript quite heavily at Naples News and the other sites we manage for NDN. I know other Scripps sites use a fair amount of JavaScript, whether its really AJAX or not I can't say. There are others here who could speak to their own use and appreciation of JavaScript and AJAX. So I don't think its fair to say "many of you don't like ajax" just because Django doesn't ship with a JS toolkit. Cheers, deryck -- Deryck Hodge http://www.devurandom.org/ Web Developer, Naples News http://www.naplesnews.com/ Samba Team http://www.samba.org/ --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: JavaScript and Changeset 3541
On Sat, 2006-08-19 at 07:57 +, simonbun wrote: > I'm not so sure its such a bad idea to bundle a JS toolkit with the > framework. It's only been a month since the last time we had this thread. Do we have to do this again? :-( Really, you bring up nothing that hasn't been covered in the Lord knows how many threads on this we've had over the last eight to 12 months. Lack of a "blessed" or include Javascript toolkit does not prevent anybody from writing Ajax applications. It does not prevent anybody from doing anything they could do if we had a library included, outside of the maybe four people who work on the Admin interface. You claim that including a toolkit will "make Ajax a possibility", but since it's already a possibility (people are already building Ajax-enabled Django-backed websites), it's not clear what you mean. The "if we don't have one people won't know what to choose" argument seems weak. It's "please help save me from having to think for myself." Django is NOT a Javascript-based framework, so us suggesting a Javascript toolkit is just another voice in the crowd with no more credibility than the next guy. There are probably some advantages to doing some Admin stuff with Ajax. But that's just the admin interface. Somebody wanting to prove their point should feel free to write an application that shows all this wonder. Remember, there is nothing to prevent having an external admin app. It's just an application, after all; you don't need to ship a patch that changes the core distribution. I more than suspect that will happen one day. [...] > - I suggest a thread is started where the pros & cons of all JS > toolkits are weighed in, Please, no! This has been done on the Django lists before. Just search the archives. More importantly, it's been done in Javascript forums before as well. Consensus is that all the popular ones are sufficiently good and fit for purpose. Opinions vary about absolute best, but that's life in the software industry, since it's unlikely there is any way to measure "absolute" best in an objective fashion. > and a choise is made as a community on wich > one to pick. We seem to have already made a choice. You would like a different choice. At which point will this argument stop going around and around? Feel free to recommend your favourite toolkit at every possibility. Point people towards articles showing how to integrate it. You will get lots of thanks from the people asking the questions and no complaints from anybody else (other than those still working on the support materials for their own favourite toolkit). You can even host these on the Django website. It's why we have the Wiki. Guys like Dave Coulix have already posted some Ajax + Django articles. > Frankly, i don't think many will get religeous about their > toolkit. I believe most (including me) just want A toolkit. > - I think the chosen JS toolkit should be as loosly coupled with the > framework as possible. i.e. no javascript helpers (à la RoR) that > sprout blocks of javascript code everywhere. No helpers seems to imply there's no particular way to use the toolkit we include beyond standard "write your own" accessors. The benefit to including it would then be ? > - If implemented correctly, i don't see how choosing a JS toolkit would > get in the way of anyone, even people that don't want to use JS or ajax > or whatever at all. This kind of lack of specificity doesn't help your arguments at all. It's a self-fulfilling statement: if the toolkit integration does get in the way, then it's not implemented correctly. > Feel free to disagree with me, but voice your opinion please. This list is busy enough without having the same threads over and over again. This one has long passed the point where abstract discussion is useful. If somebody is convinced that their idea is absolutely vital, it's time to show us the code. Your email does not describe any benefits outside of a possible, unmeasured decrease in the Admin javascript size (and less code does not mean easier maintainability, by the way) that are not already present. It seems premised on the "people don't know what to choose" point a lot. Those people should choose Dojo. No reason other than it means they no longer have to live in uncertainty. It's certain that one day we will have Admin-next-gen, but it will equally certainly live as a parallel application for a while first and nobody's written it yet (well, James B wrote one patch, but it doesn't seem to have set the world on fire). And nowhere else is Javascript used in Django's main distribution. 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
Re: Safe settings context processor
SmileyChris wrote: > On a side note, most people just want access to media_url, so I > actually would be happy with just > http://code.djangoproject.com/ticket/2532. Every web site wanting to > use static CSS will need to access this variable somehow, won't they? No, I asked my two sites and they don't want this :-). Because I use MEDIA_URL to store user files but my js and css have absolutely nothing to do there. They live under their subversioned dirs and have thier own STYLE_URL and JS_URL settings. I tend to agree with Adrian that putting some settings into some default context processor won't really help in many custom cases but will introduce a problem of polluting template's namespace. This will lead to people trying to have all the data in their templates and trying to do logic there omitting views. And then we'll get another PHP written in Django's template language (not to hit PHP but Django just have different style). --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: JavaScript and Changeset 3541
I'm not so sure its such a bad idea to bundle a JS toolkit with the framework. Last time i checked, there's about 65Kb of custom JS in django already. >From a first glance this is all functionality that can be found in most JS toolkits. Right now, if i want to use a toolkit, i have to accept its footprint plus that of django's custom JS. If a modular js toolkit is chosen, or a toolkit that is willing to have a custom branch for django developers, i bet we could go below that 65Kb and have more functionality to boot. The positive side to bundling a JS toolkit: - No need to maintain/extend the JS code yourselves - There'd be clarity for the developer that wants to use A toolkit. Some people are not in a specific JS toolkit camp, and don't mind learning one, but right now are unsure as to wich one to pick. - Ajax would be a possibility. I know many of you don't like ajax, but i believe that if its used with consideration and restraint (i.e. no color-changing div layers flying about), it can be a big plus. This does not mean that the admin generator should use ajax per default though. The negative side: - Some people will rather use another JS toolkit than the one that will be chosen (and will rant about it). On that note, i don't think it would be too hard for someone to write a wiki entry on how to replace default toolkit X with their toolkit Y (and explain its superiority). Some notes on implementation: - I suggest a thread is started where the pros & cons of all JS toolkits are weighed in, and a choise is made as a community on wich one to pick. Frankly, i don't think many will get religeous about their toolkit. I believe most (including me) just want A toolkit. - I think the chosen JS toolkit should be as loosly coupled with the framework as possible. i.e. no javascript helpers (à la RoR) that sprout blocks of javascript code everywhere. - If implemented correctly, i don't see how choosing a JS toolkit would get in the way of anyone, even people that don't want to use JS or ajax or whatever at all. Feel free to disagree with me, but voice your opinion please. 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 -~--~~~~--~~--~--~---
