Wolfram Kriesing wrote:
> The main reason I need this is that I want to have a transparent model
> that switches the underlying language (the according DB table it
> should work on) on the fly, so i can keep hacking away without
> language switching before every access via my model.
>
Why do
Malcolm Tredinnick wrote:
> I really don't like this approach to spam prevention as a general
> measure.
I would suggest a better approach would be to make it easier to include
a single randomized/hashed hidden input in the form, and make it easy to
verify the return of that input through
Russell Keith-Magee wrote:
> Hi all,
>
> On the users list, Gijs <[EMAIL PROTECTED]> has raised the idea
> of dynamic fixtures.
Well, I hate to pitch my own project, but consider my NonMockObjects:
http://www.jerf.org/programming/nonMockObjects.html
API docs. explanation, tutorial:
sal wrote:
> Hello all.
> I've been using the built in django testing framework for my code. But
> as I add more and more tests, I'm finding the standard behavior of
> only looking for tests in models.py and tests.py to be a little
> unwieldy. I'd prefer to organize my tests in separate files.
At
Malcolm Tredinnick wrote:
> Cool. I'll have a look at it in detail. From a first read, though, it
> looks like a reasonable approach: building in cache management to the
> view. Why can't this be done using the normal CacheMiddleware, though?
>
I hadn't read the source on that; now I have.
Malcolm Tredinnick wrote:
> Since we already have middleware for attaching ETags (CommonMiddleware)
> and supporting conditional GETs (ConditionalGetMiddleware), it would be
> nice to work out why they aren't just doing the right thing here.
I found ConditionalGetMiddleware before I wrote my
Unless I'm missing something, the syndication framework does not have
the ability to return HTTP 304 in response to unchanged feeds. This is bad.
I've worked up a solution locally which I'd like to get feedback on, and
a couple questions.
Currently, I've got this:
* The feed class is
[EMAIL PROTECTED] wrote:
Evening all,
I've been digging through Trac and found that there's a number of
tickets related to adding new database Field types:
Is there any documentation on adding your own field type? This might
alleviate the need to centralize some of the smaller field types.
SmileyChris wrote:
> Rather than clog up the main "1.0" discussion, let's move this to a
> side discussion.
>
I can add some personal experience to this.
At work, we use Apache::ASP (perl-based), which uses <%= $value %> to
dump out a string directly into the HTML. After one too many XSS
Jacob Kaplan-Moss wrote:
> I'd like to appoint a "leader" for each "topic" (unstable API and must-have).
> This person will have checkin access to their area of interest so they'll
> need to be someone who's already got checkin or someone who's skilled enough
> to deserve it. This person
I got burned this weekend with authentication users, setting passwords
on them directly during construction. (I knew I had to call set_password
to change the password but I had gotten the idea I could pass 'password'
into the constructor and get it handled correctly.)
If my getters/setters
Adrian Holovaty wrote:
> Before checking in this new functionality, I'd be very interested in
> seeing whether it would be possible to allow for "normal" property
> usage on models, rather than inventing a new way of doing it.
>
> Seems like it would be tricky to figure it out, but that shouldn't
Jacob Kaplan-Moss wrote:
> The patch looks pretty good to me; it applies cleanly and all the unit tests
> pass (you get major props for including 'em on the first pass :).
>
> However, I do have one quibble: the addition of ``self._django_initializing``
> inside ``Model.__init__`` has a pretty
13 matches
Mail list logo
