Habit 4 & 5 posted: & Habits of Highly Successful People by Stephen Covey
I have posted above links in the Audio Book section given below. Those who do not wish to receive these mails, can create a filter in thier email box for directly deleting without entering such mails in their email. -- With warm regardsP K Kothari http://audiobook-share.blogspot.comhttp://career-ebook.blogspot.com http://collection-share.blogspot.comhttp://ebook-share.blogspot.comhttp://management-article.blogspot.com http://finance-personal.blogspot.comhttp://powerpoint-presentation.blogspot.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 -~--~~~~--~~--~--~---
Re: Modification in the django.db.backends.postgresql.base
Rafael SDM Sierra wrote: > Hi, Trying to make Django to use really only ONE connection to ONE process > (like 1000 Threads using 1 connection) I've altered postgresql backend at > base.py. The beta (aka bugged) version is here: > > http://pastebin.com/808647 > > My question is if this alteration (turn the connection variable to be a > Class-attribute instead of Instance-attribute) would generate some problem > in the future. > I recall from postgress documentation that you can't share database connection handles across threads... Does http://www.postgresql.org/docs/8.1/static/libpq-threading.html apply? But then again, as your class variable is in a class subclassed from theading.local it appears to me that each thread would see its own private connection. Anyone to confirm or comment on this? I ran into problems myself on win32/mod_python/postgress where the limit of 100 connection was hit... but mine is a more complicated case as i connect to django in a PythonTranslateHandler for certain urls. I had to manually call connection.close() when/after the database is accessed. As forking on windows is quite expensive and postgres uses a child process for each connection, avoiding the fork overhead would make a big difference. --~--~-~--~~~---~--~~ 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: Data for globalization
Thanks Russ for your message. I became angry because I have been working very hard during 2 or 3 months. I hoped that somebody said some idea for its possible implementation Using those data we could have fields as USStateField and PhoneNumberField for all countries (and validators). But I don't see a solution very clean. Any idea? For the others tables (countries, languages, time zones), I believe that it would be cool if it were used from an AJAX widget. What do you think? I only want ideas to begin to look for the best solution and to begin with the implementation. And better if it's a solution that can be used for any project in general. --~--~-~--~~~---~--~~ 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: Data for globalization
On 10/15/06, GinTon <[EMAIL PROTECTED]> wrote: > And here you have the files for add/integrate them to any Django > project: > http://satchmo.python-hosting.com/file/trunk/satchmo/G11n/ > http://satchmo.python-hosting.com/file/trunk/satchmo/load_G11n.py It may be too much work, or you may not be interested, but consider adding these to your language table: MARC http://www.loc.gov/marc/languages/langascii.html IANA http://www.iana.org/assignments/language-subtag-registry MARC is a standard for bibliographic records, and that IANA registry is the internet code. (I think 630-2 and 3066 may have a strong overlap. --~--~-~--~~~---~--~~ 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: Data for globalization
I've actually been thinking about this, recently. How would people feel about a Field type that took a regex to validate input against. Or, to be even more wacky, how about providing callables that would validate the input and normalize it? Something like def __init__(self, validator=lambda x: true, normalizer=lambda x: x): So, by default, it doesn't validate or normalize, but you can provide a function for each. Or am I being overly complicated? Todd On Wed, 2006-10-18 at 09:19 +, GinTon wrote: > Thanks Russ for your message. I became angry because I have been > working very hard during 2 or 3 months. > > I hoped that somebody said some idea for its possible implementation > > Using those data we could have fields as USStateField and > PhoneNumberField for all countries (and validators). But I don't see a > solution very clean. Any idea? > > For the others tables (countries, languages, time zones), I believe > that it would be cool if it were used from an AJAX widget. What do you > think? > > I only want ideas to begin to look for the best solution and to begin > with the implementation. And better if it's a solution that can be used > for any project in general. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
drag-n-drop order_with_respect_to
Hi, I'm currently writing an application which would benefit greatly from an already-existing drag-n-drop interface for something like the order_with_respect_to option. Digging around the code, I see that order_with_respect_to seems unmaintained -- there are portions of the code which are marked as "TODO". In fact, as far as I can see, order_with_respect_to won't do what it says on the label at all. Am I missing the point here? Is there somebody working on this? Would a resurrection of a drag-n-drop UI for order_with_respect_to be welcomed? Regards, Russell -- echo http://russell.rucus.net/spam/ | sed 's,t/.*,t,;P;s,.*//,,;s,\.,@,;' --~--~-~--~~~---~--~~ 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: Data for globalization
Jeremy Dunck wrote: > On 10/15/06, GinTon <[EMAIL PROTECTED]> wrote: > > And here you have the files for add/integrate them to any Django > > project: > > http://satchmo.python-hosting.com/file/trunk/satchmo/G11n/ > > http://satchmo.python-hosting.com/file/trunk/satchmo/load_G11n.py > > It may be too much work, or you may not be interested, but consider > adding these to your language table: > > MARC > http://www.loc.gov/marc/languages/langascii.html > > IANA > http://www.iana.org/assignments/language-subtag-registry > > MARC is a standard for bibliographic records, and that IANA registry > is the internet code. (I think 630-2 and 3066 may have a strong > overlap. Those data are included in http://satchmo.python-hosting.com/file/trunk/satchmo/G11n/data/language.csv and I used http://www.loc.gov/standards/iso639-2/ I added only the official languages of countries although I've to add some more that have only the 2 letter iso code. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Functional Benchmark : Django, Rails, CakePHP
Hello, I'm currently writing a functional benchmark for french press (IT news, programming magazine) about Django, Ruby on Rails and CakePHP. I started to fill one Excel sheet with Django's assets but then I thought that Django's community would be interested and much more skilled than me to do that intself. So I'm asking you if you could add some more stuff to this spreadsheet. Feel free to send it to other Django users, so that I could have more information. The only problem, is that I'm kinda in a rush right now since I have to finish this benchmark next week so it would be perfect if you can send me this back on ASAP to [EMAIL PROTECTED] Youc can find the sheet at http://www.jchatard.info/django.xls Best regards, Jérémy -- View this message in context: http://www.nabble.com/Functional-Benchmark-%3A-Django%2C-Rails%2C-CakePHP-tf2466473.html#a6875806 Sent from the django-developers mailing list archive at Nabble.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 -~--~~~~--~~--~--~---
Re: Modification in the django.db.backends.postgresql.base
On 10/18/06, Niels <[EMAIL PROTECTED]> wrote: Rafael SDM Sierra wrote:> Hi, Trying to make Django to use really only ONE connection to ONE process> (like 1000 Threads using 1 connection) I've altered postgresql backend at> base.py. The beta (aka bugged) version is here: >> http://pastebin.com/808647>> My question is if this alteration (turn the connection variable to be a> Class-attribute instead of Instance-attribute) would generate some problem > in the future.>I recall from postgress documentation that you can't share databaseconnection handles across threads... Does http://www.postgresql.org/docs/8.1/static/libpq-threading.html apply? I don't know how much it is applied to my application, because Django uses cursor and (teorically) one connection could have more than one cursor But then again, as your class variable is in a class subclassed fromtheading.local it appears to me that each thread would see its ownprivate connection. Anyone to confirm or comment on this? In my application with 1000+ threads I got only one connection with 1000+ cursors, and it seems to be working (maybe??) I ran into problems myself on win32/mod_python/postgress where thelimit of 100 connection was hit... but mine is a more complicated case as i connect to django in a PythonTranslateHandler for certain urls. Ihad to manually call connection.close() when/after the database isaccessed. As forking on windows is quite expensive and postgres uses a child process for each connection, avoiding the fork overhead wouldmake a big difference. I don't will run my app in windows, so it can not be a problem to me..:P -- SDM UnderlinuxGarimpar.com--PEP-8Só existem 3 tipos de pessoas no mundo, as que sabem contar, e as que não sabem.CPFL - Compania Piratininga de FALTA de Luz (6 vezes em 5 dias!!) --~--~-~--~~~---~--~~ 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: drag-n-drop order_with_respect_to
Hi Russell, On 18 Oct 2006, at 14:49, Russell Cloran wrote: > I'm currently writing an application which would benefit greatly > from an already-existing drag-n-drop interface for something like > the order_with_respect_to option. > > Is there somebody working on this? Last I heard on this issue is this ticket: http://code.djangoproject.com/ticket/13 But that hasn’t gotten much of love, last “action” is from around January. The mockups from Wilson look nice anyway, maybe they’re helpful for your needs. > Would a resurrection of a drag-n-drop UI for order_with_respect_to > be welcomed? Yeah. I, for one, would very much welcome something like it. BTW: is this code working at the moment? http://code.djangoproject.com/browser/django/trunk/django/contrib/ admin/media/js/admin/ordering.js Cheers. -- Antonio --~--~-~--~~~---~--~~ 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: Call for testing: New setup.py
sbain wrote: > How would one now recommend that a new Windows developer install Django > in a such a way as to facilitate keeping his Django updated to the > trunk? I only dabble with Django from time to time, but here is how I have it set up (the following assumes C:\Python24\ as the root): 1. svn checkout into Lib/site-packages/django-src 2. Create Lib/site-packages/django.pth file with the following line as its only content: django-src 3. Create Scripts/django-admin.bat file with the following line as its only content: @python C:\Python24\Lib\site-packages\django-src\django\bin\django-admin.py %* 4. Make sure C:\Python24\Scripts is on your PATH, and django-admin works just like it does in the documentation. 5. Stay up to date with svn up Lib/site-packages/django-src A slight pain to set it up this way, but once everything is in place it is smooth sailing. I did all this specifically because I didn't want to use setuptools/ez_install. Hope this helps, Will. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
"Pool" of "one" connection in Apache
Following suggests, I'm forwarding my mail, from the Django-users to Django-dev list.-- Forwarded message --From: Rafael SDM Sierra < [EMAIL PROTECTED]>Date: Oct 18, 2006 2:52 PMSubject: "Pool" of "one" connection in ApacheTo: django-users@googlegroups.comLooking the django.db.backends.postgresql source code, I saw that Django connection needs only one connection for all processes, because it uses cursors to execute sql queries. So, I develop a system that run 1000+ threads using only one connection by changing the base.py [1]. But, this solution generate a problem, apache handles each request with separeted fork processes, and so it starts one connection at database that is not more closed (remember, if I reimplement the DatabaseWrapper.close, one thread close the connection of everybody when it's done) and leave the connection opened So I have 2 ways to solve it: 1 - Rewrite the DatabaseWrapper.close to check if the app is been called from an apache instance or from shell 2 - Implement some function that when the request is created by apache, it gets the connection from a miracle mod_python/apache/somewhere variable and doesn't close it when it's done [1] - http://pastebin.com/808647-- SDM UnderlinuxGarimpar.com --PEP-8Só existem 3 tipos de pessoas no mundo, as que sabem contar, e as que não sabem.CPFL - Compania Piratininga de FALTA de Luz (6 vezes em 5 dias!!) --~--~-~--~~~---~--~~ 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: "Pool" of "one" connection in Apache
On 10/18/06, Rafael SDM Sierra <[EMAIL PROTECTED]> wrote: Following suggests, I'm forwarding my mail, from the Django-users to Django-dev list.-- Forwarded message --From: Rafael SDM Sierra < [EMAIL PROTECTED]>Date: Oct 18, 2006 2:52 PMSubject: "Pool" of "one" connection in Apache To: django-users@googlegroups.comLooking the django.db.backends.postgresql source code, I saw that Django connection needs only one connection for all processes, because it uses cursors to execute sql queries. So, I develop a system that run 1000+ threads using only one connection by changing the base.py [1]. But, this solution generate a problem, apache handles each request with separeted fork processes, and so it starts one connection at database that is not more closed (remember, if I reimplement the DatabaseWrapper.close, one thread close the connection of everybody when it's done) and leave the connection opened So I have 2 ways to solve it: 1 - Rewrite the DatabaseWrapper.close to check if the app is been called from an apache instance or from shell 2 - Implement some function that when the request is created by apache, it gets the connection from a miracle mod_python/apache/somewhere variable and doesn't close it when it's done [1] - http://pastebin.com/808647 I'm switching to the postgresql_psycopg2 backend because of it[1]: ''' Its main advantages are that it supports the full Python DBAPI 2.0 and it is thread safe at level 2. It was designed for heavily multi-threaded applications that create and destroy lots of cursors and make a conspicuous number of concurrent INSERTs or UPDATEs. ''' [1] - From http://initd.org/tracker/psycopg/wiki/PsycopgTwo -- SDM UnderlinuxGarimpar.com--PEP-8Só existem 3 tipos de pessoas no mundo, as que sabem contar, e as que não sabem.CPFL - Compania Piratininga de FALTA de Luz (6 vezes em 5 dias!!) --~--~-~--~~~---~--~~ 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: drag-n-drop order_with_respect_to
Hi, On 10/18/06, Antonio Cavedoni <[EMAIL PROTECTED]> wrote: > Last I heard on this issue is this ticket: > > http://code.djangoproject.com/ticket/13 > > But that hasn't gotten much of love, last "action" is from around > January. The mockups from Wilson look nice anyway, maybe they're > helpful for your needs. Thanks for the pointer, I didn't pick that ticket up. I do like those mockups. Wilson -- are you still working on that stuff? Do you have any abandoned code to share with me? > Yeah. I, for one, would very much welcome something like it. Great, I'll continue working on it then :) > BTW: is this code working at the moment? > > http://code.djangoproject.com/browser/django/trunk/django/contrib/ > admin/media/js/admin/ordering.js Yes, for some values of yes :) So far, I've dropped in dom-drag.js, hacked the change_form.html template a little and applied the patch I posted to ticket #2137 and have something which suggests that a large portion of the code (still) works. It's still a bit broken in that it sets all the li's to be absolute position, which means that everything collapses under them... But now that I've seen Wilson's mockups, it makes a lot more sense :) Russell -- echo http://russell.rucus.net/spam/ | sed 's,t/.*,t,;P;s,.*//,,;s,\.,@,;' --~--~-~--~~~---~--~~ 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: feature request: Bonjour support
That is cool. Especially if there is no extra library dependency. It is these little "nice to haves" that can add that extra bit of polish to Django. On Oct 17, 10:24 am, Cheng Zhang <[EMAIL PROTECTED]> wrote: > On Oct 17, 2006, at 11:50 PM, Michael Twomey wrote: > > > Turbogears just uses the command line tools if they are available, no > > need to drag in any library dependencies. Another advantage of this > > approach is that it works on any platform with the bonjour command > > line tools, not just the mac. > > > You can see it in action here: > >http://www.turbogears.org/svn/turbogears/trunk/turbogears/startup.py > > > Look for 'def start_bonjour():"That's one neat idea we could learn from TG. > > With the TG's code as an > example, it shouldn't be hard to put up a patch. > > -Cheng Zhanghttp://www.ifaxian.com > 1st Django powered site in Chinese ;-)http://www.aiyo.cn > Our 2nd Django powered site in Chinese --~--~-~--~~~---~--~~ 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: feature request: Bonjour support
Clint-You sound skeptical of the utility of adding Bonjour. I'll try to reason why I think it's important for Django to have this. Is Django competing for mindshare among web developers? Every little bit of polish matters. TurboGears already has this, and you can bet that as Apple integrates Rails into Leopard, they're thinking about "fit and finish" stuff like this. It's always a really nice feeling when you get a little surprise like finding the website you're developing in your Bonjour bar. "Wow: someone thought of that." It gives you (well, me anyway) a nice tingle and makes a positive emotional connection-much like the feeling I got when I realized how much work Django's free Admin app saves me. This kind of stuff evangelizes itself. If you're developing more than one Django site at the same time, they'll show up by name in Bonjour, instead of localhost:port. While I can keep it straight that MisterWidget is running on localhost:8000, CrazyBlog is running on localhost:8020, and MyWebStore is running on localhost:8080, why should I have to? It's much nicer to hit the Bonjour bar and pull them down by name. While this is a contrived example, I think it illustrates the point nicely. I don't actually use Firefox at all, other than to make sure my websites look and behave normally in it. I simply dislike the browser. I use Opera and Safari. Camino (the Mac-native browser with a creamy Gecko core) also uses Bonjour, so it would be useful to non-Safari Mac devs as well. If no one has added this by the time I'm more proficient in Django's innards (I've only got about 8 hours' total experience in Django and I haven't even finished my first tutorial yet), I'll submit a patch myself and hope it gets accepted. It's worth doing and worth having. And it's easy! The TurboGears code to do this, in their setup.py, is not very many lines of code. --~--~-~--~~~---~--~~ 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: Call for testing: New setup.py
Works fine for me on OS X 10.4.8, Python 2.4, Intel platform. --~--~-~--~~~---~--~~ 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: Data for globalization
Todd O'Bryan wrote: > I've actually been thinking about this, recently. How would people feel > about a Field type that took a regex to validate input against. > > Or, to be even more wacky, how about providing callables that would > validate the input and normalize it? Something like > > def __init__(self, validator=lambda x: true, normalizer=lambda x: x): > > So, by default, it doesn't validate or normalize, but you can provide a > function for each. > > Or am I being overly complicated? Thanks Todd. I believe that is a good starting point. I've been busy with the configuration of the web and SVN to put the project in an independent site. I hope that tomorrow or the friday is ready. --~--~-~--~~~---~--~~ 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: Data for globalization
USStatefield. This field is used to validating the U.S. states (areas). http://code.djangoproject.com/browser/django/trunk/django/db/models/fields/__init__.py#L778 http://code.djangoproject.com/browser/django/trunk/django/forms/__init__.py#L941 http://code.djangoproject.com/browser/django/trunk/django/core/validators.py#L238 It would be better if the user could choose it from a drop list. In addition there would not necessary the validating. And we couldshow a drop list for all countries where it is necessary for the potstal address _all countries that are in area.csv_. --~--~-~--~~~---~--~~ 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: Data for globalization
I've moved all files about globalization to http://svn.webda.python-hosting.com/trunk/ --~--~-~--~~~---~--~~ 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: Data for globalization
I've created a new group for integrating G11n data in Django and Turbogears: http://groups.google.com/group/webda Please I need ideas to get the best possible integration. --~--~-~--~~~---~--~~ 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: Data for globalization
I must say, I **hate** drop-downs for the state postal abbreviation. The vast majority of the time, when people are filling in a form where they need a postal abbreviation, they are either: a. putting their own address and know the abbreviation b. filling in an address they've been given, which has the code c. working at a job where they have to fill out many such forms so that they get to know the codes or can be expected to look up the ones they don't know Get rid of the evil state abbreviation drop-down menu. And kill the guy who thought it was a good idea. And make his next of kin choose the manner of his burial from a drop-down list. Todd On Wed, 2006-10-18 at 20:57 +, GinTon wrote: > USStatefield. This field is used to validating the U.S. states (areas). > > http://code.djangoproject.com/browser/django/trunk/django/db/models/fields/__init__.py#L778 > http://code.djangoproject.com/browser/django/trunk/django/forms/__init__.py#L941 > http://code.djangoproject.com/browser/django/trunk/django/core/validators.py#L238 > > It would be better if the user could choose it from a drop list. In > addition there would not necessary the validating. > > And we couldshow a drop list for all countries where it is necessary > for the potstal address _all countries that are in area.csv_. --~--~-~--~~~---~--~~ 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: Functional Benchmark : Django, Rails, CakePHP
Hi Jeremy, On Wed, 2006-10-18 at 06:07 -0700, jchatard wrote: > > Hello, > > I'm currently writing a functional benchmark for french press (IT > news, programming magazine) about Django, Ruby on Rails and CakePHP. > > I started to fill one Excel sheet with Django's assets but then I > thought that Django's community would be interested and much more > skilled than me to do that intself. I'm always inherently suspicious of benchmarks like this, since my natural question is "how much has the author actually *used* the thing he is evaluating? Has he done real work with it?" > So I'm asking you if you could add some more stuff to this spreadsheet. > Feel free to send it to other Django users, so that I could have more > information. Most of what you have in the spreadsheet seems reasonable, although there a few items that are close to IT buzzwords there that don't really convey a lot of specific information (for example, what does "internationalization really *mean* if an app gets a "yes"). You've left out email support and the standard Python exception handling abilities in the error handling section. The Operating Systems row isn't complete (also GNU is an acronym and is all capitals and Django even runs on Linux systems that aren't GNU-based :-) ). Django runs on any system that supports a database and Python -- so pretty much any Unix-based system will suffice as well: *BSD, Solaris, AIX, You've written "no" for documentation generation, which is incorrect. Have a look under the documentation tab in the admin interface. All of the developer's models, filters, views and URL configs are documented there using the information extracted via introspection. The distinction between "built-in" and extensions seems a little arbitrary. Syndication, site maps, multiple sites are all part shipped with core, just like admin, for example. Yet the latter is considered built-in and the former three are marked as extensions in your table. The difference seems a bit arbitrary there. Completely customisable URLs is an evaluation point (presumably the other two platforms you are comparing do this as well, but it's clearly not a truism in the industry). I think most of your points under Documentation/Community are low when compared genuinely to the other two products you are evaluating. You should probably add mailing lists as a line-item there, too, since both RoR and Django have extremely high-volume, very helpful mailing lists (no idea about CakePHP). Some Ruby-on-Rails bias shows through in the "scaffolding" line, since that's not really an industry-standard term and Django has similar helpful support to a lot of the RoR things in that area (not identical, but not a subset, either). Things like support for existing database tables and so on. You could just as easily have put in "automatic support for populating models via web interface" (i.e. admin interface) and have a Django bias and then Ruby gets a "no (but has scaffolding)". Both approaches are not really comparing apples and oranges. Your annotation for "language" in the "development" section just says "Django templating language", which isn't even half the story. That is one portion of on piece of the framework. The bulk of the coding is done in Python -- the views, the models and the template tags. Django has a separate language for the templates themselves in order to provide a lower barrier to entry for page developers, but that is just one corner of the Django world. I would dispute your technology risk assessment (assuming three stars means high risk), since Django is built on extremely well-established technology (Python had public releases before PHP or Ruby -- or even Java for that matter -- and the databases it is built on have been around "forever" in Internet years). Experience suggests that, despite the hype around Ruby, experienced Python developers are easy enough to find (As easy as any other good quality experienced software developer). It often seems like there are truckloads of PHP developers around, but the pool empties out a lot when you attach "high quality" to the requirements list. It is very easy for an experienced Python dweveloper to understand how Django works, because working out even the tricky bits from the source just isn't that hard if things get really hard (Python source code has a real advantage in that it's naturally very readable). Still, a judgement call like that is always going to be debatable, regardless of what you put there. But the *technology* risk with Python + PostgreSQL/MySQL + Apache stacks is very, very low these days. Difficult to judge some of the other assessments you've given, since I don't know the calibration scale and it always depends upon prior experience. > The only problem, is that I'm kinda in a rush right now since I have > to finish this benchmark next week so it would be perfect if you can > send me this back on ASAP to [EMAIL PROTECTED] If you would like us to help you with yo
Re: Functional Benchmark : Django, Rails, CakePHP
On 19-Oct-06, at 7:29 AM, Malcolm Tredinnick wrote: > should probably add mailing lists as a line-item there, too, since > both > RoR and Django have extremely high-volume, very helpful mailing lists and i hope he has mentioned our #django IRC channel - with a reputation for never RTFM'ing anyone ;-) -- regards kg http://lawgon.livejournal.com http://nrcfosshelpline.in/web/ --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
