James Bennett wrote:
> The more I think about it, the more I like the idea of using imports
> in __init__.py to specify an application's dependencies; the thing
> that'd make it especially nice would be some method -- either
> conventional or built straight in to Django -- of checking for
>
James Bennett wrote:
> On 8/13/06, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> > The Lawrence guys have mentioned on this list previously that they have
> > many different applications they pull together in various projects.
>
> :)
>
> If we couldn't modularize, we wouldn't be able to sell
I think you meant "I used property() so you can use
request.session.expires = 213123. "
I wouldn't worry about the smart times -- just having seconds is good
enough.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
On Aug 16, 2006, at 2:31 PM, Adrian Holovaty wrote:
>
> The Django team discovered and fixed a small security hole in the
> django/bin/compile-messages.py helper script, which is the script that
> compiles message files (.po files) into binary format (.mo files).
Informative. I am certain that
On 8/16/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> I have the same. I've tried to clean up the main wiki page and it
> rejects the changes.
Core-dev-types: would it be okay to whitelist these guys?
--~--~-~--~~~---~--~~
You received this message because
In China GB18030 is required to be used by law, any most sites just
assume the browser uses that as the default, so they don't even specify
a character encoding.
Your likely setup for international web sites is to have Unicode in the
database (since databases have special support for it and it
gabor wrote:
>
> currently my plan is to have the following behaviour:
>
> 1. i assume that every GET/POST param comes in encoded as
> settings.DEFAULT_CHARSET, and will decode it accordingly. if it fails,
> then it fails.
Assuming "you got served" with settings.DEFAULT_CHARSET, then sure.
On 8/16/06, gabor <[EMAIL PROTECTED]> wrote:
> 3. will assume the database is in DEFAULT_CHARSET
> - maybe can we somehow ask the db for it's charset?
I think you really have to allow for different charset in the DB--
legacy integration, remember.
I created a patch to implement a common feature.
http://code.djangoproject.com/ticket/2548
The patch implements setting the expire per session.
Are there any standards for django how APIs should be created? I like
using request.session.expires = 213123. However is this okay API wise
for Django?
Having to remember to escape every variable node in an html template when it's the normal behaviour seems so un-DRY.What I wanted was a way of adding the escape filter to every variable node (eg {{
object.name }}) without changing the core django code.So I made a block tag which can add filters
Jeremy Dunck wrote:
> On 8/16/06, Bill de hÓra <[EMAIL PROTECTED]> wrote:
>> Now. Most (all?) browser UAs sniff the content to second guess the media
>> type. They don't much pay attention to Content-Type (I think maybe IE
>> ignores it altogether). The problem for this example is they might be
On 8/9/06, gabor <[EMAIL PROTECTED]> wrote:
> hmmm.. are you sure that the situation with unicode-aware editors is so bad?
>
> could you name some non-unicode-aware editors?
> for me it seems that from notepad through vim to eclipse everything does
> unicode fine...
On Windows, I used UltraEdit,
On 8/16/06, Bill de hÓra <[EMAIL PROTECTED]> wrote:
> Now. Most (all?) browser UAs sniff the content to second guess the media
> type. They don't much pay attention to Content-Type (I think maybe IE
> ignores it altogether). The problem for this example is they might be
> doing something similar
Gábor Farkas wrote:
> for example, using this html file:
>
> http://localhost:7000;>
>
>
>
> (+ additional xhtml-headers, http-equiv-content-type=utf-8 etc)
>
> firefox submits this:
>
>
> POST / HTTP/1.1
> Host: localhost:7000
> User-Agent: Mozilla/5.0 (X11; U; Linux i686;
Error detected
New patch
http://code.djangoproject.com/attachment/ticket/2070/3581-streaming_uploads_and_uploadprogress_middleware_wsgi_fix.diff
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers"
Considering this patch done unless anyone can find fatal bugs or have
some comments about it.
Ticket
http://code.djangoproject.com/ticket/2070
Patch
http://code.djangoproject.com/attachment/ticket/2070/3581-streaming_uploads_and_uploadprogress_middleware_fixes_and_pretty_bar.diff
To use
"Gary Wilson" <[EMAIL PROTECTED]> writes:
> Scott Paul Robertson wrote:
>> I'll start on this tomorrow. Out of curiosity how common is this sort of
>> setup? I've only seen a handful of LDAP implementations, and this is new
>> to me.
> Not sure how common it is, as this is the only ldap setup I
Bill de hÓra wrote:
> gabor wrote:
>
>> so what do you think about the following approach:
>>
>> try ascii-decoding
>> if fails, try utf8-decoding
>> if fails do iso-8859-1-decoding (this cannot fail).
>>
>> ?
>
> Dumb question maybe. How do you know this encoding ladder will work?
it depends
The Django team discovered and fixed a small security hole in the
django/bin/compile-messages.py helper script, which is the script that
compiles message files (.po files) into binary format (.mo files).
The compile-messages.py script uses the name of the .po file to build
arguments to a system
19 matches
Mail list logo
