Re: make db form settings

Adrian Holovaty wrote: > On 7/4/07, Max Battcher <[EMAIL PROTECTED]> wrote: >> I'm not sure if there is a large enough need for your script, Carl K. >> Creating the databases themselves should be a rare activity. > > Agreed. One should only have to create a database once. It's dropping > and

Re: validator_list and newforms.models.form_for_model

On 7/4/07, Jeremy Dunck <[EMAIL PROTECTED]> wrote: > Is validator_list going away entirely, or is it desirable for > form_for_model to implement the needed clean method based on the > validator_list's of the form fields? I haven't given this a ton of thought, but my own opinion is that

Re: make db form settings

On 7/4/07, Max Battcher <[EMAIL PROTECTED]> wrote: > I'm not sure if there is a large enough need for your script, Carl K. > Creating the databases themselves should be a rare activity. Agreed. One should only have to create a database once. It's dropping and creating individual *tables* that

Re: validator_list and newforms.models.form_for_model

On 7/4/07, Jeremy Dunck <[EMAIL PROTECTED]> wrote: > Is validator_list going away entirely, or is it desirable for > form_for_model to implement the needed clean method based on the > validator_list's of the form fields? FWIW, I've read this thread, but it doesn't appear to have a definite

validator_list and newforms.models.form_for_model

I understand how newforms validation occurs (Field.clean, Form.clean_FIELD, Form.clean). However, people (myself included) are surprised that newforms form_for_model doesn't include validators from validator_list in the generated Form.clean method. Is validator_list going away entirely, or is

Re: newforms documentation

On Wed, 2007-07-04 at 14:19 -0400, Victor Ng wrote: > Hi, > > My earlier confusion with the newforms 'id' attributes was caused by > some poor wording in the documentation. > > Just above this link is some unnecessarily wordy text: > > http://www.djangoproject.com/documentation/newforms/#as-p

Re: runtests.py MySql failures=2

On Wed, 2007-07-04 at 11:32 -0500, Carl Karsten wrote: > DATABASE_ENGINE = 'sqlite3' > ./runtests.py - no errors. > > change to: > DATABASE_ENGINE = 'mysql' > (first time running the tests on MySql, so chance something is hozed on my > end.) > > > [EMAIL PROTECTED]:~/django/django-src/tests$

Re: auto_now_add overwrites a given date

If your using auto_now_add, then you should want the date auto-populated *every* time. If that is not the behavior you want, then writing you own save method can easily give you the behavior you want. Actually, in your case, you probably want auto_now_add's behavior all the time. That is with

auto_now_add overwrites a given date

Hello, I wrote a script to convert from an old database (turbogears) to django. It involved a few loops like this: for oldm in messages: newm = models.Message() newm.date = oldm.date newm.text = oldm.text newm.save() After running the script, I discovered

Re: make db form settings

I'm not sure if there is a large enough need for your script, Carl K. Creating the databases themselves should be a rare activity. Perhaps you'd be better off looking for a deployment engine that supports what you need, such as Capistrano. -- --Max Battcher-- http://www.worldmaker.net/

newforms documentation

Hi, My earlier confusion with the newforms 'id' attributes was caused by some poor wording in the documentation. Just above this link is some unnecessarily wordy text: http://www.djangoproject.com/documentation/newforms/#as-p "Each text label is surrounded in an HTML tag, which points to the

Re: newforms markup with id attributes

oops... i didn't read the documentation carefully to see that label uses a 'for' attribute. Sorry. vic On 7/4/07, Victor Ng <[EMAIL PROTECTED]> wrote: > I noticed that newforms generates the same id attribute for both the > label and the input field of a form. Can we get different attribute >

newforms markup with id attributes

I noticed that newforms generates the same id attribute for both the label and the input field of a form. Can we get different attribute values here? I couldn't find a reason for duplicated 'id' values in the mailing list archives and this looks like a bug to me - id's should be unique within a

make db form settings

I have the begging of something that may eventually get submitted, and looking for guidance as I build it. In the spirit of DRY, I have a nifty script that helps create the db defined in settings.py #!/usr/bin/env python # mkdbuser.py # prints the CREATE DATABASE and GRANT commands based on

Re: Unicode branch - last call for comments(?)

On 7/4/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > Oh, something I just remembered: newforms-admin will be a bear to merge > from trunk next time. There are some necessary Unicode changes in the > old admin that need to be ported across, etc. > > I am quite happy to do that work, as well

runtests.py MySql failures=2

DATABASE_ENGINE = 'sqlite3' ./runtests.py - no errors. change to: DATABASE_ENGINE = 'mysql' (first time running the tests on MySql, so chance something is hozed on my end.) [EMAIL PROTECTED]:~/django/django-src/tests$ ./runtests.py --settings settings

Re: unique email in User model

On Sunday 01 July 2007 19:59:13 Vladimir Pouzanov wrote: > Hi all, > > Is there any reason for having not-unique email field in User model? > I'm going to duplicate email in my 1-to-1 model to make it unique, > and it doesn't look like a clean solution. Actually, just a few days before this post

Re: Unicode branch - last call for comments(?)

Great work Malcolm! Another big milestone reached towards one point oh! I ran into a strange situation converting my code though. My models returned bytestrings instead of unicode in my code, but not in my shell. After some poking around I found that I had to remove all my *.pyc files from my

Re: Unicode branch - last call for comments(?)

> Well if I have understood what you say, it is exactly what is > explained here UnicodeBranch#PortingApplicationsTheQuickChecklist>.. Right, now I feel dump. ;-) I even read the docs some time ago Greetings, David Danier

ImageField upload_to problem

Hello everybody, I sent this to Django users but got no replies, I also think this has to do with some shortcommings of ImageField. I want to create a gallery app and I have a slight problem, my models.py code looks like this: ... class Gallery(models.Model): slug = models.SlugField(...)

Re: Unicode branch - last call for comments(?)

Hi David, Thanks for the feedback. A few comments below... On Wed, 2007-07-04 at 15:12 +0200, David Danier wrote: > > Merged in [5609]. > > Great! > > There is only one thing I ran into so far. And I would not bring this up > now, if the commit didn't say "This should be fully backwards

Re: Unicode branch - last call for comments(?)

Well if I have understood what you say, it is exactly what is explained here .. Anyway, that is a great news. But I have changed all my code and I have just read that you wasn't going to update newforms-admin

Re: Unicode branch - last call for comments(?)

Malcolm Tredinnick wrote: > Merged in [5609]. Thank you very much! --~--~-~--~~~---~--~~ 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

Re: Unicode branch - last call for comments(?)

On Tue, 2007-07-03 at 22:53 +1000, Malcolm Tredinnick wrote: > Unless anybody has strong objections, I'd like to merge the Unicode > branch into trunk very soon (within a few days, if nobody cares much). Merged in [5609]. Regards, Malcolm -- Quantum mechanics: the dreams stuff is made of.

Re: "@cache_page" bug...

On Wed, 2007-07-04 at 00:30 -0700, jedie wrote: > On 23 Jun., 12:40, Malcolm Tredinnick <[EMAIL PROTECTED]> > wrote: > > Fortunately,it'sallincrediblymoot, since the real fix (in #1015) is > > just about ready to go.Itwas being looked at again as a result of Gary > > closing the ticket with a