postgresql
On 14/09/06, Derek Anderson <[EMAIL PROTECTED]> wrote:
>
> which backend are you using?
>
> Matthew Flanagan wrote:
> > Derek,
> >
> > I have manually merged the trunk into my local working copy of the
> > schema-evolution branch and started playing with it. I wanted to
> > question th
which backend are you using?
Matthew Flanagan wrote:
> Derek,
>
> I have manually merged the trunk into my local working copy of the
> schema-evolution branch and started playing with it. I wanted to
> question the SQL "sqlevolve" is outputting. I have this model in an
> application called "asse
On Sep 13, 2006, at 7:09 PM, Gary Wilson wrote:
>
> Out of curiosity, any one know for what reason using empty strings for
> CharFields is the Django convention? Technically, isn't an empty
> string still data? Isn't it a bit confusing that some fields get
> default values and others do not? Ex
Occasionally, simply mousing over a link on the Trac search results
page causes Safari to crash.
Here is the ticket and the changeset that provides a javascript fix.
The fix looks fairly benign (I guess Safari doesn't like the splitText
() function).
http://trac.edgewall.org/ticket/3451
htt
Derek,
I have manually merged the trunk into my local working copy of the
schema-evolution branch and started playing with it. I wanted to
question the SQL "sqlevolve" is outputting. I have this model in an
application called "asset":
class Interface(models.Model):
name = models.CharField(ma
On Thu, 2006-09-14 at 02:09 +, Gary Wilson wrote:
> Out of curiosity, any one know for what reason using empty strings for
> CharFields is the Django convention? Technically, isn't an empty
> string still data? Isn't it a bit confusing that some fields get
> default values and others do not
On 9/14/06, Matthew Flanagan <[EMAIL PROTECTED]> wrote:
>
> On 14/09/06, Brantley Harris <[EMAIL PROTECTED]> wrote:
> > For instance, using the given example:
> >message = TextField(label='Your message',
> > attributes={'class':'vRichTextField'})
> >
>
> +1 on this for me. I'd love to be able
Brantley Harris wrote:
> > Another thing to note: In the current Manipulator framework, sometimes
> > it is convenient to be able to construct self.fields dynamically. We
> > should provide a way to do that with the new syntax.
>
> +1
+1
Being able to contruct fields dynamically would be great.
Don Arbow wrote:
> Yes, from the documentation:
>
> http://www.djangoproject.com/documentation/model_api/#null
>
> "Note that empty string values will always get stored as empty
> strings, not as NULL -- so use null=True for non-string fields such
> as integers, booleans and dates.
>
> Avoid using
On 9/13/06, Michael Radziej <[EMAIL PROTECTED]> wrote:
>
> Russell Keith-Magee wrote:
> > Submitting a patch without tests is almost _exactly_ the _worst_ thing
> > you can do if you want your patch to be committed.
>
> When I submit a patch, I'd really like to see some serious
> interest from the
Back on topic, check out my alternative that I thought may appease the
Django gods if they are so outraged by adding another tag type.
http://code.djangoproject.com/ticket/2721
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Googl
On 9/14/06, SmileyChris <[EMAIL PROTECTED]> wrote:
>
> Michael Radziej wrote:
> > I'd appreciate if we could find a
> > way to state what kind of patches are interesting for the
> > committers and what not *before* the patch is created fully. This
> > is of course more important for large patches
On 14/09/06, Brantley Harris <[EMAIL PROTECTED]> wrote:
>
> On 9/12/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> >
> > Hence, with this new API, the above view code would be written like this:
> >
> > form = ContactForm()
> > if request.method == 'POST' and form.is_valid(**request.POST
On 9/12/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> Hence, with this new API, the above view code would be written like this:
>
> form = ContactForm()
> if request.method == 'POST' and form.is_valid(**request.POST):
> send_email_and_redirect()
> return render_to_response
Hi, I'm working over the search-api branches, I'm trying to implement
the Xapian for the database API, this is near to finish, I would like
that someone see the ticket[1] (I haven't write access in svn), to
later merge it into then (svn).
I need that someone test the others backend (Lucene and Hy
Michael Radziej wrote:
> I'd appreciate if we could find a
> way to state what kind of patches are interesting for the
> committers and what not *before* the patch is created fully. This
> is of course more important for large patches.
I think this is the core of my underlying concerns of how t
Hello everyone.
I started using Django about a week ago. I have a particular app which
more or less accepts CSV files, Excel files, DBase files, and whatever
else, takes the uploaded file, converts it to a tab-delimited format,
and then does statistical work over it.
Originally this application
On Sep 11, 2006, at 11:25 AM, Gary Wilson wrote:
> The name field does not have blank=True or null=True set, but yet I am
> able to create a new Name object using no parameters (because
> CharFields and children are defaluting to empty string). Is this the
> intended behavior?
Yes, from the docu
On 9/13/06, Rob Hudson <[EMAIL PROTECTED]> wrote:
>
> (I'm not an official "dev" so I hope it's not considered inappropriate
> of me to provide my feedback.)
It's not inappropriate at all. :)
> Instead of the assumption that bind() validates, why not have an
> is_valid() method that assumes bind
On 9/13/06, Ivan Sagalaev <[EMAIL PROTECTED]> wrote:
>
> Joseph Kocherhans wrote:
> > Assumptions: form.bind(data) does *not* return a BoundForm. bind does
> > the validation and probably populates form.errors or .errors() or
> > whatever. bind returns True or False depending on whether validation
Joseph Kocherhans wrote:
> Assumptions: form.bind(data) does *not* return a BoundForm. bind does
> the validation and probably populates form.errors or .errors() or
> whatever. bind returns True or False depending on whether validation
> succeeded or not. bind does not short circuit on the first e
JP wrote:
> What if widgets could act as filters? I think using filter syntax for
> setting the widget for a field in the template would be pretty
> natural::
>
> {{ form.field }}
>
> draws the default widget for the field type, but if you want to use
> SomeOtherWidget, you can do::
>
> {{ fo
Joseph Kocherhans wrote:
>
> form = ContactForm()
> if request.method == POST and form.bind(request.POST):
> send_email_and_redirect()
> return render_to_response('email_form.html', {'form':form})
>
> Assumptions: form.bind(data) does *not* return a BoundForm. bind does
> the
gabor wrote:
> yes, (unfortunately) it is.
>
> the models do not validate their input.
>
> you will have to use a manipulator (Name.AddManipulator) to validate
> your input (and then save the object).
>
> making the models validation-aware is planned, but not done yet.
But I am not talking about
On 9/12/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> Hence, with this new API, the above view code would be written like this:
>
> form = ContactForm()
> if request.method == 'POST' and form.is_valid(**request.POST):
> send_email_and_redirect()
> return render_to_response
I noticed (after inferring it probably exists) the
RequiredIfOtherFieldsGiven validator, though it is currently
undocumented. The default error message is, "Please enter both fields
or leave them both empty." The actual test is:
def __call__(self, field_data, all_data):
for field in
Yeah, I'm a big +1 on this. I try to comment my code as much as
possible to make it possible for me to go back months later and pick
up where I left off in terms of understanding and this patch will
greatly beautify comments.
I know in the past a core dev or two resisted adding another tag
No problem, I did the easy part. Figuring out where the tests go was
a lot easier that actually adding the new syntax to the template
system, I'm sure.
I just hope this helps the new syntax get added. I really think it
would be an important addition to the template system.
Will.
On 9/13/06,
Awesome! Thanks Will :-)
Seeing the diff you made makes it a lot easier to learn how to make my
own tests.
Also, thanks for performing the diff from the root this time. My
mistake in issuing it from within the tree.
Thanks again,
--Ben
--~--~-~--~~~---~--~~
You
Hawkeye wrote:
> if someone else has time to
> write a few tests, I'd be appreciative.
I have the time! I added a new patch that includes tests:
http://code.djangoproject.com/ticket/648
--~--~-~--~~~---~--~~
You received this message because you are subscribed t
Russell Keith-Magee wrote:
> +1 to providing the ability to select a widget at the template level,
> but -1 to requiring .as_text for the default case.
What if widgets could act as filters? I think using filter syntax for
setting the widget for a field in the template would be pretty
natural::
On 9/13/06, Michael Radziej <[EMAIL PROTECTED]> wrote:
> I understood the critics completely different. It's not about the
> committers not keeping on top, it's that there are not enough
> committers. Which is not easy to solve, as discussed before, and
> probably multiple times. And, I really app
On 9/13/06, Hawkeye <[EMAIL PROTECTED]> wrote:
> It doesn't explain how the django-developers have constructed their
> test suites, and how one can build upon them.
Django's own tests use the same system (mostly they're doctests).
--
"May the forces of evil become confused on the way to your ho
I don't know how I missed that... still that's more a django-users
guide from what I can discern... write tests for your own applications.
It doesn't explain how the django-developers have constructed their
test suites, and how one can build upon them.
Nonetheless, having this doc helps and I'll
On 9/13/06, Hawkeye <[EMAIL PROTECTED]> wrote:
> There's a high barrier to entry when I have to deconstruct the test
> architecture before I can contribute a simple patch.
http://www.djangoproject.com/documentation/testing/
--
"May the forces of evil become confused on the way to your house."
> So - if you want your patches taken seriously, treat them seriously -
> don't just write them, test them too (and not just a token test either
> - REALLY test them). Especially when the testing framework is already
> in place for something like template tags.
I don't dispute the concept here, bu
> So - if you want your patches taken seriously, treat them seriously -
> don't just write them, test them too (and not just a token test either
> - REALLY test them). Especially when the testing framework is already
> in place for something like template tags.
I don't dispute the concept here, bu
Adrian Holovaty wrote:
> Similarly, how would is_valid() and errors() work? If is_valid() or
> errors() get passed kwargs, does the form instance automatically
> become a BoundForm? What if it's already been bound? Do the kwargs
> replace any existing bound data?
I think with just one Form class
Hi Adrian
On the whole, this looks like pretty good stuff to me. A few comments
along the way; some of these ideas need not be in the v1
implementation, but I mention them anyway so that we don't roll out a
system that can't accomodate them in the future:
On 9/13/06, Adrian Holovaty <[EMAIL PROT
39 matches
Mail list logo
