Russell Keith-Magee wrote:
>
>
>
>
>
>
>
This is a bad thing. Requests are extremely expensive and this is
encouraging scenarios where you end up with 30, 40, maybe more little
CSS and JS files. I'd never deploy this; I try to never deploy with more
than one of each. I generally fail
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 yo
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 middle
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:
http://www.j
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. It's
Malcolm Tredinnick wrote:
For concreteness, I've added a ticket and there is a code-only patch at
http://code.djangoproject.com/attachment/ticket/3680/cache.control.on.syndication.code.only.diff
. The patch is exceedingly lightly tested (I've only smoke tested it on
a local dev box, and I hav
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 extra
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 slightly
James Bennett wrote:
> On 1/31/07, Joseph Perla <[EMAIL PROTECTED]> wrote:
>
>> Along the lines of get_or_create(), does it make sense to implement a
>> get_or_set() function for quick caches?
>>
>
> I'm not sure I see the use case here; it only works when the code to
> calculate the expen
[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 bugs
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 can
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 pat
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 n
16 matches
Mail list logo
