On Sun, Nov 23, 2008 at 4:42 PM, Julien Phalip <[EMAIL PROTECTED]> wrote:
> I could not find any mention of this in the Version 1.1 features or
> roadmap. I guess it'll have to wait till next release. Could you
> please confirm?
It's a pretty small change with no real backwards-incompatibility
im
On Nov 9, 7:56 am, "James Bennett" <[EMAIL PROTECTED]> wrote:
> The Djangotestclient exposes theContextused to render the returned
> response, so that unit tests can inspect thatContextand verify that
> it contained what it was expected to contain. This is all well and
> good, except that there is
On Sun, Nov 9, 2008 at 2:25 PM, Gábor Farkas <[EMAIL PROTECTED]> wrote:
> does this mechanism work with contexts with integer-keys?
A context variable can't really be an integer, so far as I can tell...
--
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."
--~--~---
On Sun, Nov 9, 2008 at 3:48 AM, James Bennett <[EMAIL PROTECTED]> wrote:
>
> On Sat, Nov 8, 2008 at 5:34 PM, Russell Keith-Magee
> <[EMAIL PROTECTED]> wrote:
>> However, to clarify - are you talking about a backwards incompatible
>> change, or are you talking about putting a backwards compatible l
> I'd prefer backwards compatibility. The way I'm envisioning it would
> complicate the code a bit, but I think preserving compatibility is
> worth it:
It would be nice to keep backwards compat, for the sole reason that
the quickest way to test your code against a django upgrade is to run
tests -
On Sat, Nov 8, 2008 at 5:34 PM, Russell Keith-Magee
<[EMAIL PROTECTED]> wrote:
> However, to clarify - are you talking about a backwards incompatible
> change, or are you talking about putting a backwards compatible layer
> in place that tries to tell the difference between the two modes of
> acce
On Sun, Nov 9, 2008 at 6:40 AM, Eric Holscher <[EMAIL PROTECTED]> wrote:
> For my pony request, it would be really nice to have a way to get "user
> defined" context. This being things that were passed from views, set in
> template tags, (and maybe other places?). That is what the above code is
>
On Sun, Nov 9, 2008 at 5:56 AM, James Bennett <[EMAIL PROTECTED]> wrote:
>
> For 1.1, could we look into unifying the interface to
> ``response.context`` to avoid this sort of problem? Unless I'm
> thinking about this the wrong way, it shouldn't be too hard to
> differentiate dictionary-style acce
Note also, that sometimes the context that you are looking for isn't always
in [0]. I ran into this when I was writing testmaker, and had to hack around
it. Luckily all of my templates used inheritance, so I didn't get bitten by
the dictionary or list of dictionary part.
I did something like this:
The Django test client exposes the Context used to render the returned
response, so that unit tests can inspect that Context and verify that
it contained what it was expected to contain. This is all well and
good, except that there is no consistent way to write tests which do
this.
When an inheri
10 matches
Mail list logo
