Hi,
On Wed, 02 Jul 2008 05:55:26 +0200, Gary Wilson Jr.
<[EMAIL PROTECTED]> wrote:
> Jeremy Dunck wrote:
[Pagintor problems]
>> Is there some other way we can point the gun away from our foot?
>
> I, for one, would be in favor of doing away with QueryPaginator and
> bringing back the behaviour
Jacob Kaplan-Moss wrote:
> Help me out here: how can I make it more obvious?
Wow, you've certainly made it more obvious :) I pity the fool that
misses it now.
Gary
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
On 01-Jul-08, at 10:04 PM, Tom Tobin wrote:
> On Tue, Jul 1, 2008 at 4:25 AM, Kenneth Gonsalves
> <[EMAIL PROTECTED]> wrote:
>>
>> why should he be more polite? He follows the policy of 'teaching to
>> fish' rather than spoonfeeding. I have several times got flamed by
>> him for getting impatien
Jeremy Dunck wrote:
> I just ran into the same issue several people before me have:
> Paginator is a bit dangerous when handed a queryset, and
> QuerySetPaginator should be used instead.
>
> This ticket exists, but no core dev has contributed to discussion yet.
> http://code.djangoproject.com/tic
On Tue, Jul 1, 2008 at 8:28 PM, Arien <[EMAIL PROTECTED]> wrote:
>
> On Tue, Jul 1, 2008 at 6:10 PM, Waylan Limberg <[EMAIL PROTECTED]> wrote:
>>
>> On Tue, Jul 1, 2008 at 5:59 PM, David Durham, Jr.
>> <[EMAIL PROTECTED]> wrote:
>>>
>>> Nice thing about GETs is that users aren't confronted with th
On Tue, Jul 1, 2008 at 6:10 PM, Waylan Limberg <[EMAIL PROTECTED]> wrote:
> Um, this is intentional and a good thing. If you read the spec, not
> only is the difference between GET and POST defined, but the way user
> agents (browsers) should treat them is defined as well. Breaking the
> back & re
On Tue, Jul 1, 2008 at 6:10 PM, Waylan Limberg <[EMAIL PROTECTED]> wrote:
>
> On Tue, Jul 1, 2008 at 5:59 PM, David Durham, Jr.
> <[EMAIL PROTECTED]> wrote:
>>
>> Nice thing about GETs is that users aren't confronted with the dreaded
>> "Data was submitted with POST" confirmation, which is confusi
On Tue, Jul 1, 2008 at 2:40 PM, David Cramer <[EMAIL PROTECTED]> wrote:
> I haven't read this over in too much detail yet (I just auto ignore
> the 10k trac emails about it :P) but a few concerns:
I haven't read the rest of your email yet, but I think the answers are
"77" and "see a doctor if the
> Shouldn't this be marked as somewhat blocking for 1.0-alpha?
Personally I would remove XmlField from the standard-models and create
something like django.contrib.xml, which includes some common code for
xml-handling (forms, models, dom/etree/..., xslt with callbacks, etc).
But thats nothing
On Tue, Jul 1, 2008 at 5:59 PM, David Durham, Jr.
<[EMAIL PROTECTED]> wrote:
>
> Nice thing about GETs is that users aren't confronted with the dreaded
> "Data was submitted with POST" confirmation, which is confusing to
> most people and usually not tested. Basically you end up breaking the
> ba
On Tue, Jul 1, 2008 at 4:59 PM, David Durham, Jr.
<[EMAIL PROTECTED]> wrote:
> form, and are redirected to a GET for the next step. In this case,
> the POST disappears from the user's history (refresh and reload work
> as expected).
Sorry, reload and back work as expected ...
-Dave
--~--~-
On Mon, Jun 30, 2008 at 8:03 PM, Jeremy Dunck <[EMAIL PROTECTED]> wrote:
>
> I was thinking the FormWizard should allow GET to be used on all but
> the last step, or should allow configuration of what to method to use.
>
> Forms aren't just for posting.
>
> Any interest in this?
Nice thing about
On Tue, Jul 1, 2008 at 4:40 PM, David Cramer <[EMAIL PROTECTED]> wrote:
> - Is there a setting (e.g. settings.py) to restrict the maximum file
> size in an upload?
FILE_UPLOAD_MAX_MEMORY_SIZE
--~--~-~--~~~---~--~~
You received this message because you are subscrib
I haven't read this over in too much detail yet (I just auto ignore
the 10k trac emails about it :P) but a few concerns:
- Is there a setting (e.g. settings.py) to restrict the maximum file
size in an upload?
- For test suites couldn't you while (xrange(n)) pass /dev/random or
whatever to make a
I just ran into the same issue several people before me have:
Paginator is a bit dangerous when handed a queryset, and
QuerySetPaginator should be used instead.
This ticket exists, but no core dev has contributed to discussion yet.
http://code.djangoproject.com/ticket/7478
I'd like to avoid maki
I mentioned some issues to Michael Axiak a while back, and he said
he'd get to them but that I should post them on the 2070 ticket. I
forgot to post them, so he might've missed it before it was committed
to SVN. I made a new ticket for them:
http://code.djangoproject.com/ticket/7593
A quick ov
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jul 1, 2008, at 18:56, Honza Král wrote:
> That's -1 from me. I am not opposed to the idea in general, I just
> don't feel it's needed and should be in the code.
Sounds more like a -0 to me. -1 is, as far as I
have seen, strong rejection.
Ludv
I personally like the rendering methods being attached to the form, as
they don't make sense as a universal template filter/tag. I do
however, use a filter as "as_p" doesn't do much :)
On Jun 28, 8:33 am, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> On Sat, 2008-06-28 at 06:12 -0700, ionut wro
I'll agree Magus is harsh, but he's also helpful, and this isn't the
place to discuss this :)
On Jul 1, 11:40 am, "Rajeev J Sebastian" <[EMAIL PROTECTED]>
wrote:
> +1 to Tom, though magus
>
> On Tue, Jul 1, 2008 at 7:34 PM, Tom Tobin <[EMAIL PROTECTED]> wrote:
> > On Tue, Jul 1, 2008 at 4:25 AM,
Shouldn't this be marked as somewhat blocking for 1.0-alpha? Is there any
good reason why the code you wrote has not been accepted?
On Tue, Jul 1, 2008 at 6:46 PM, David Danier <[EMAIL PROTECTED]>
wrote:
>
> > I'm trying to understand what's wrong with the XMLField in nfa.
> > The validation in v
that would look really terrible with the hashes in the URL, that's why
I avoided GET, it would be easy to factor it out and even allow for
data to be passed in URL (I have no idea why somebody would want that,
but why not ;) ) but I just don't think it would make sense.
Forms aren't just for posti
+1 to Tom, though magus
On Tue, Jul 1, 2008 at 7:34 PM, Tom Tobin <[EMAIL PROTECTED]> wrote:
> On Tue, Jul 1, 2008 at 4:25 AM, Kenneth Gonsalves
> <[EMAIL PROTECTED]> wrote:
>>
>> why should he be more polite? He follows the policy of 'teaching to
>> fish' rather than spoonfeeding. I have several
> I'm trying to understand what's wrong with the XMLField in nfa.
> The validation in validators.py/RelaxNGCompact is never called, It looks
> like unused dead code. This means the validation on XMLFields is
> currently not working at all.
> Is there anyone with a better understanding of the sit
On Tue, Jul 1, 2008 at 4:25 AM, Kenneth Gonsalves
<[EMAIL PROTECTED]> wrote:
>
> why should he be more polite? He follows the policy of 'teaching to
> fish' rather than spoonfeeding. I have several times got flamed by
> him for getting impatient and giving the answer. I would say that he
> is the s
Hi,
I'm trying to understand what's wrong with the XMLField in nfa.
The validation in validators.py/RelaxNGCompact is never called, It looks
like unused dead code. This means the validation on XMLFields is currently
not working at all.
Is there anyone with a better understanding of the situation?
WEB CAM ON ONLINE
New Web cam Software
Simply Five Step To Open Ur Computer
1.Visit Link===>
http://www.moreinfo247.com/9560073/CB
2.sign up with your current email id also.
3.then check your mail id(sfi message mail)
4.click the that mail and click 2 link.
5.after 2 minutes u
On Jul 1, 7:15 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> It's quite a large restriction to say that no middleware should ever try
> to examine the contents of the HttpResponse since it might be an
> iterator that shouldn't be consumed. You're proposing a bunch of
> specific changes for
Certainly the implementation of the patch is not ideal (by accessing
private attributes on HttpResponse), which is why I brought it up for
discussion before going any further.
I do feel that there is a real benefit and even requirement in some
cases to supporting streaming HttpResponse objects. I
Malcolm Tredinnick wrote:
> The response should just return a copy of the
> content when response.content is accessed, which means turning any
> iterator into a proper string.
Ouch.. I thought it already does just that. Yeah, it's a bug then.
Though simple to fix.
> But it *does* require that e
On Tue, 2008-07-01 at 14:42 +0400, Ivan Sagalaev wrote:
> Malcolm Tredinnick wrote:
> > Any middleware that examines the content has to pull the content into
> > memory in case it's an iterator. If they don't they're buggy because
> > they're consuming the content ahead of the web server.
>
> Ag
Malcolm Tredinnick wrote:
> Any middleware that examines the content has to pull the content into
> memory in case it's an iterator. If they don't they're buggy because
> they're consuming the content ahead of the web server.
Agreed.
> But the default behaviour shouldn't
> require repetitive pra
On Tue, 2008-07-01 at 14:02 +0400, Ivan Sagalaev wrote:
> Malcolm Tredinnick wrote:
> > I thought we'd fixed it, but apparently we haven't: if any iterator is
> > passed into an HttpResponse, it should be converted to a string
> > immediately so that things can index into it without doing
> > non
Malcolm Tredinnick wrote:
> I thought we'd fixed it, but apparently we haven't: if any iterator is
> passed into an HttpResponse, it should be converted to a string
> immediately so that things can index into it without doing
> non-repeatable consumption.
Malcolm, sorry, that won't work. I've imp
On 26-Jun-08, at 7:51 PM, Jeremy Dunck wrote:
>> Then, I tried helping people the way he does for a mere fraction of
>> the time he does. Answering the same 5 questions 20 times a day
>> (ok, I
>> did it maybe twice) would drive anyone insane.
>
> +1
+1
>
> Yes, it'd be nice if Magus were a b
On Tue, 2008-07-01 at 00:03 -0700, Tai Lee wrote:
> http://code.djangoproject.com/ticket/7581
>
> Just posted this ticket with an initial patch (sans documentation
> changes and tests). Basically there are several middleware classes
> that access HttpResponse.content directly which break streami
On Jun 25, 11:48 pm, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]>
wrote:
> Two things:
>
>
> I don't know the background of whether Tom tried these things or not.
> Again, I don't care to ague about it. Let's not make this happen again
> in the future, OK?
>
> Please, folks, we're all friends here.
Tai Lee wrote:
> http://code.djangoproject.com/ticket/7581
>
> Just posted this ticket with an initial patch (sans documentation
> changes and tests). Basically there are several middleware classes
> that access HttpResponse.content directly which break streaming
> HttpResponse objects that use a
http://code.djangoproject.com/ticket/7581
Just posted this ticket with an initial patch (sans documentation
changes and tests). Basically there are several middleware classes
that access HttpResponse.content directly which break streaming
HttpResponse objects that use a generator to yield content
38 matches
Mail list logo