form action="."

Chapter 7 of The Django Book says this: The action="." means “Submit the form to the same URL as the current page.” I'm not sure this is standard or not, but it doesn't do what's expected at least on Firefox 3.0.6 (Iceweasel of Debian 5.0 stable): the form is simply submitted to an emtpy URL "

Re: form action="."

On Sun, 2009-03-08 at 03:37 -0700, rihad wrote: > Chapter 7 of The Django Book says this: When the updated version of Chapter 7 of the django boook is released online, if the same description persists, it would be worth making a comment over there. Although the book is written by two of the prima

Re: Declarative fixtures for django

Hey Ben, I don't have a lot (well, any) time to really give this the attention it deserves at the moment. But a couple of quick thoughts so that you don't think it's been entirely overlooked. I agree with the general thrust of what you're talking about and it's good to see questions about keepin

Request Signals

Hi, I've been looking at ways to add more dynamic logging to my applications and naturally looked to the django signals as a way to do it. I'm unsure of the logic behind the request handler class being returned in the request_finished and request_started signals, rather than the actual instance.

testclass

hi, I'm having a working django application. I want to see the values of my variables when I'm executing my code. something like JUnits containertest for java. I'm tried to test a method in my views.py code. The method is called generate_html( ). when i write a test class like: ---

RE: Request Signals

Hello Peter, I believe you can catch the instance in a middleware class. I'm sure a better developer or someone on the core team can explain better than me. Jamie Rumbelow -Original Message- From: django-developers@googlegroups.com [mailto:django-develop...@googlegroups.com] On Behalf

Re: testclass

On Mar 8, 2009, at 12:06, nenduvel wrote: > so i have two questions: > > - how can i let my test work > - perhaps somebody knows a better way to test my application This is a "how do I?" sort of question. The best place to ask those is the django-users mailing list. This list is for the int

Re: testclass

sorry about that. i will post it there. On 8 mrt, 15:23, Ludvig Ericson wrote: > On Mar 8, 2009, at 12:06, nenduvel wrote: > > > so i have two questions: > > > - how can i let my test work > > - perhaps somebody knows a better way to test my application > > This is a "how do I?" sort of ques

Re: 'week_day' starting with sunday as first day of a week need to be fixed

> Would it be possible to use cron's weekday numbering? Would that make > anyone happy? > > 0-7, with both 0 and 7 representing Sunday. That would at least avoid > the %7 part of the workaround (from the user's perspective, anyway). I think that would be a very good compromise. I'll happily work

sessions are not lazily created

Memcached-backed sessions seemed to be created, even when the session is not written to. This is what I'm finding when I look at my memcache after hitting a page that does not use sessions. Thus, if an app uses sessions (but not much), memcache will fill up with empty sessions. (the same thing mi

Re: Declarative fixtures for django

Hi Malcolm This is one of those cases where I have to ask why you're using a class > instead of a dictionary. You're mapping keys (initialisation parameters) > to values (the values to set the parameters to). Using a map object > seems like the way to go. It doesn't carry the necessary indentation

Re: form action="."

> When the updated version of Chapter 7 of the django boook is released > online, if the same description persists, it would be worth making a > comment over there. Well, I'd hate sounding mean, but the wording was already taken from v2.0: http://www.djangobook.com/en/2.0/chapter07/ > Although th

Re: sessions are not lazily created

Are you using the auth middleware? If so it will be hitting the session each query, even if your stuff doesn'tm Alex On 3/8/09, Dennis wrote: > > Memcached-backed sessions seemed to be created, even when the session > is not written to. > > This is what I'm finding when I look at my memcache a

Re: Declarative fixtures for django

On Mar 8, 2009, at 19:01, Ben Ford wrote: > class app__Model(DataSet): > class generic_instance: > field_one = ... > lots of other generic fields here > > class another_instance(generic_instance): > different_field = ... > other_overridden_field = ...

Milestones and roadmap cleanup - thanks!

Jacob, thanks for the great work on Trac cleanup! This makes the devs intentions and goals so much more transparent. I especially like that we have a somewhat official ticket-set-based roadmap now (http:// code.djangoproject.com/roadmap ) instead of the manual one (http:// code.djangoproject.com/

Re: Work on #9964

On Sunday 08 March 2009, Malcolm Tredinnick wrote: > On Sat, 2009-03-07 at 21:24 +0200, Shai Berger wrote: > > Hi list, Malcolm, > > > > If I start working on a patch for #9664 (Transaction middleware closes > > the transaction only when it's marked as dirty; marked for milestone > > 1.1), will I

1.1: Ticket #3569 (Enhanced Atom Support)

Hey all, I have talked to James Tauber about ticket #3569 which is about adding better support for Atom to the syndication feeds framework. He has suggested that if we want to include something along these lines in 1.1 that we should put it in Django along-side the current Atom support. He has a

Re: sessions are not lazily created

Nope, I did not enable the auth middleware. Here are my 3 middleware components: 'django.contrib.sessions.middleware.SessionMiddleware', 'django.middleware.common.CommonMiddleware', 'django.middleware.locale.LocaleMiddleware', On Mar 9, 3:07 am, Alex Gaynor wrote: > Are you usin